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.
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:
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:
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:
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.