Practical .NET-to-Java Interop Solutions, Part II

When it comes to integrating Java-based apps with .NET, SOA may not be the best choice -- for today, at least. Take a look at a useful real-world, step-by-step approach that is helping leading IT architects and devs draft their own "interoperability requirements" matrix. This work forms the basis for some of the interop Best Practices at Avanade, a leading .NET/Java integration firm.

Tags: Java, Smart Client, Architecture, BEOs, Business, Web Services, Integrating,

When it comes to integrating Java-based applications with software built on the .NET development platform, IT managers may be faced with a dilemma. Increasingly popular and powerful integration methods such as service oriented architecture (SOA) may be impractical or impossible.

In the first part of this article, we explored the reasons why service oriented architecture (SOA) and more specifically, Web services may not always be suitable for integrating J2EE and .NET applications. Issues range from systems design that pre-dates SOA, to poorly architected systems, to business requirements that necessitate tighter coupling in a heterogeneous environment.

IT managers should take heart - it is possible to use a Java investment with a rich .NET user interface. This article will address possible solutions.

Writing an "Application Requirements Statement"
Two steps are crucial to resolving this Java-.NET interoperability puzzle: (1) creation of an application requirements statement, and (2)performance of a requirements analysis. For the purpose of illustration, this article will use a fictional modification of an application that's based on a composite of experience with real applications.

Let's assume the task at hand is to replace the existing JSP Web application with a new .NET Smart Client. Let's list some of the key application requirements:

  • First, the new client must use the existing application that's been written in Java 1.4 and that uses stateless session beans. The system exposes complex business entity objects (BEOs) that include extensive business and validation logic, and that are serializable - that is, the BEOs can be transferred and reassembled, rather than require request-and-response interaction to function. Additionally, the server functions to provide subscriptions to a Java Message Service (JMS) topic.

  • On the client side, Java-based code directs interaction with the server, including handling subscription to the JMS topic and translating it into Java events. The goal is to use this same logic in the new client with minimal development effort. Meanwhile, the server code and the BEOs are continually being enhanced.

  • Another key assumption is that wholesale migration the entire application to .NET has been ruled out as wasteful and risky due to fact that most business rules are written into the actual BEO code. If that's the case, it's impractical to rewrite the logic continually as business rules can be superseded by new ones.

    An Enterprise IT Guide To Conducting an
    "Interoperability Requirements Analysis"

    A formal requirements analysis will uncover a number of business needs in this hypothetical scenario. Any interoperability project you develop should have similar requirements.
    1. The Java application must be able to be used with a .NET Smart Client user interface.

    a. Project must implement a .NET Smart client that calls J2EE Stateless Session Bean and retrieves rich Java BEOs
    b. Smart client must call the rich BEOs' functionality without a round-trip to the server. This condition will preempt creation of a "chatty" interface that requires a number of requests and responses to complete a task.

    c. Solution must support Java 1.4.

    2. Smart client must be capable of receiving JMS topic messages.

    a. Smart client must subscribe to JMS Topic with an event listener
    b. Smart client must be able to receive the message and use its content

    When multiple applications are open, all of them must receive this message

    3. The project must develop a repeatable build process.

    a. Development should be automated as much as possible, using .NET solutions.

    b. The system should be robust enough to handle changes made to the Java code. (i) It should not require manual changes to proxies; automatic regeneration is acceptable.(ii) The build script should accommodate new services.

    Development should support automated unit testing with NUnit or an equivalent test harness.

    4. The project should use only commercially viable products. For most large and medium-size businesses this means software supported by a viable commercial entity. This does not necessarily exclude open source software.

    5. Smart client responsiveness must be better than the current Web application.

    Approaches to Consider
    The next step, now that you have assessed functional needs and created the interoperability requirements analysis, is to evaluate your list of possible approaches to integration and determine which deliver the best result.

    Here are some techniques and assessment we use to cull this list, again using our hypothetical project:

  • 1. Use the Java Language Conversion Assistant (JLCA) to convert the BEOs from Java to .NET. JCLA helps with the migration of Java code to C#. However, it requires substantial manual work - and this violates requirement 3b for automated Java code generation.

  • 2. Create a Web services front end to the Java client code. This approach requires a Web service to be written by hand, which fails the automation requirement. In addition, this technique transfers data only, failing requirement 1b for preservation of BEOs' logic. In addition, the Web service front end cannot "listen" to JMS messages, which violates requirement 2.

  • 3. Use J#, a .NET language. J# was developed to facilitate migration of Java-based code developed before the introduction of the .NET application platform, without translating the software using JCLA. But J# is based on Java 1.1, an obsolete specification, and fails requirement 1c for the use of Java 1.4.

  • 4. Use a Java-to-.NET bridge product. Bridge products work in one of two ways.
    a. A bridge product architecture that places the bridge function on the client side preserves the existing Java proxy and Java BEOs that reside in the client code. Depending on the implementation, bridge architecture A fulfills all of the interoperability requirements.
    b. Bridge architecture that places function on the server side puts all of the processing on the server side, creating "chatty" application function and failing requirements 1b and most likely, requirement 5 for same-or-better client responsiveness.

    Java-to-.NET Bridge Product Selection
    In our hypothetical project, , a bridge product with Architecture A is the best solution. Selection of the bridge product is best done through a process of evaluation and elimination, based on the applicability of the products available.

    Here's a sample assessment of three products - IT pros should check what's on the market, perform an independent evaluation and adjust evaluation criteria - their interoperability requirements - based on their current business needs.

    J-Integra for .NET is based on a complete implementation of the .NET Remoting wire-level protocol. It's a hybrid of architectures A and B: It requires a remote interface to a separate process as in architecture B, with remote processing on the client side. While it is comparatively faster than server-side processing, this product does not fulfill requirements 1b or 5. Additional remote interfaces would have to be programmed to allow access to BEO functionality, (violating requirement 3b above.

    iKVM is a Java virtual machine (JVM) hosted by a .NET application - so it allows Java-based code to run within the smart client.

    The JVM uses GNU Classpath to implement the Java library functions used by the Java code. GNU Classpath is currently at version 0.15 and iKVM is at 0.14, so it does not meet requirement 4 for commercially viable technology. Should I choose to relax that requirement, I would need to determine whether GNU Classpath supports all the Java class libraries used in my application.

    JNBridge hosts a user-selected JVM within a .NET-based process. This could be the same process as the smart client, or a separate process machine. However, to streamline function and ensure application responsiveness, the JVM and therefore the BEOs must be hosted in the same process as the .NET run-time.

    JNBridge has an automated build process for Java code proxies that can be called by .NET. It also includes a special attribute for the event-handling class within the smart client, so that the user can specify which Java event-handler interface will be implemented by the .NET class designed to handle the event.

    This capability amounts to dynamic generation of a Java proxy, and speedy support the request-and-response action required to bridge the two operating environments. For my hypothetical interoperability project, it looks like JNBridge would fulfill all requirements.

    To Bridge, or Not to Bridge
    When Web services are not an option for integrating Java- and .NET-based applications, a bridge product can offer a good alternative. But the best approach is to carefully evaluate your needs. Options to investigate, in order of desirability, include:

  • 1. Standardizing on the .NET (or Java) application platform and migrating all code to one accordingly;
  • 2.Using SOA if the systems to be integrated are loosely coupled; and
  • 3. Using a bridge product.

  • There are business and technical reasons for standardizing an application environment, but those must be weighed against the value and utility of existing systems. And service oriented architecture is a strategy that should be part of every IT manager's best practices playbook - but one that may be impractical.

    Sometimes, a bridge application is simply the best solution.

    About the author: Heinrich Gantenbein is solutions architect at Avanade, a leading technology integrator for Microsoft enterprise technology. Gantenbein has focused on Java to .NET migration and ADO.NET for three years, and participates in Microsoft's Preview Labs to give feedback on future .NET technologies. With more than 20 years' software engineering and engineering management experience, he has held senior positions at Silicon Valley Group, KLA-Tencor, startup companies, and Excite@Home.