The Challenge of .NET/Java Interop -- sans SOA
An increasing number of F1000 firms are looking for ways to easily get their Java/J2EE and .NET assets to better cooperate. It is a world rich with new standards and emerging technologies for web services, SOA and other "sharing" options for data and business rules. Henrich Gantenbein, a Solutions Architect with Avanade, a leading web services and integration firm, offers some valuable advice.
For companies using Java applications, the need to integrate with applications built on the .NET development platform presents a dilemma. Any IT manager understands the value of integration that's simple but flexible. That's the benefit of service oriented architecture (SOA), a powerful and promising approach to application and systems integration.
But SOA is not a silver bullet:
Many companies' existing, Java-based applications are not developed with service orientation, making SOA impractical or impossible. This is the first article in a two-part series on the challenge that's brewing for interoperability.
Part I will review the challenges facing developers. The good news is that it's definitely possible to use a Java investment with a rich .NET user interface. Part II will address possible solutions.
between Java and /NET?
Interoperability most often becomes a requirement because it's impractical not to reuse existing server applications in new application development. If an application still serves its purpose, then reusing code is cost-effective and helps maintain a smooth-running operation.
Interoperability is also essential when it's desirable to add a smart client user interface to a traditional, Java-based Web application, or where two groups or divisions must interact but each is running software on a different platform. For organizations that are migrating from one platform to another in order to standardize their IT environment, interoperability is crucial to maintain operations during the changeover.
The next step, then, is to consider what the options are for creating interoperability.
Assumptions about SOA with Web Services
Lately, SOA and Web services have featured at the center of ongoing industry debate over approaches to system integration. It's tempting to think interoperability might be as simple as putting a Web services wrapper around an application, since Web services work by exposing an aspect of software function to other applications, using XML.
But Web services and SOA are not the same thing. Where Web services provide a tactical approach to point-to-point integration, SOA introduces a strategy for integration across multiple applications. Therefore, SOA becomes the leading candidate for multi-system interaction. Web services offer one (the prevalent) technique for implementing SOA.
There isn't universal agreement on SOAs' technical definition, but four principles are widely accepted: service boundaries are explicit; shared schema and contract-style interaction; policy-based compatibility; and design for autonomy. SOA also assumes certain other application characteristics. Some of these may be present but "hidden" by disparities in execution that can make more work for developers.
For example, Web Services presumes support for compatible security policies, implying use of the same security protocol. But a given Microsoft server and preferred Java application server vendor may not support the same draft version of Web services standards for security, as protocols continue to evolve. This specific discrepancy would require developers to use SSL-or IPSEC-protected connections and another authentication method such as custom SOAP headers.
Web services endpoints also may differ in the "flavor" of SOAP each uses. One endpoint may use the Remote Procedure Call (RPC) protocol and the other, Document-Literal encoding. Server vendors don't adhere to a single standard; for example, Microsoft and BEA application servers use Document-Literal SOAP by default, while most other Java application server vendors support RPC. To bridge the difference, the default behavior of one application has to be changed to suit the other.
Finally, event callbacks and asynchronous communications may not interoperate without special proxy handlers or mark-up. Some development platform vendors take a proprietary approach to communication management that isn't supported by the other application environment. Messaging protocols that pre-date Web services, such as Java Messaging Service (JMS) and Microsoft Message Queue (MSMQ), do not interoperate directly - nor will applications that use them. A proposed WS-Eventing notification protocol is not yet standard, so it's not a viable alternative.
Not a Silver Bullet: Problems with SOA
in the Real World of Enterprise IT Architectures
None of these differences in application architecture are huge barriers to SOA - and there's no doubt that SOA is a great for new systems. But certain application characteristics indicate SOA is not always an option. Developers should recognize these signs and prepare to consider alternatives.
SOA-Incompatible J2EE Applications
J2EE-based applications' Business Entity Objects are not simple Entity Beans or simple Data Transfer Objects. They contain complex validation and even work-flow type business logic which are needed by both the client and the server.
This architecture delivers a sizable payload using coarse-grained interaction to access functionality and requires tighter coupling of front- and back-end, out of keeping with SOA - although in most cases, these objects are retrieved by Stateless Session Beans, a function that's partially service-oriented and preferable to data-intensive pure remote object architecture. This will prove important to determining an interoperability solution.
The use of Stateful Session Beans or Java Remote Method Invocation (RMI) also can contribute to "chatty" interfaces to update the business object, another challenge to service orientation. Whether or not interoperability is the objective, good application design rejects complex interfaces for n-tier architecture.
SOA-Incompatible .NET Applications
Applications built in the .NET development environment can be equally poor candidates for SOA-based interaction. Again, complexity plays a deciding role, whether in the payload or in the interface. As in the Java example, .NET-based applications with a sizable payload do not lend themselves to service orientation, although they may use Web services - or single call semantics or Enterprise Services Just-In-Time-activated objects - which are partially service-oriented modes of transfer.
As for Java, there are plenty of examples where the .NET application payload is simple but the interface is complex. Applications that use client-activated or singleton remote objects with "chatty" interfaces can require excessive data exchanges to update the business object. This architecture is neither service-oriented nor desirable for high-performance application function.
What to Do?
Poor application design, regardless of platform, is not the only reason to forego service-oriented architecture. There are times when business needs require business logic to be executed on both the client and the server. As noted, there are architecture scenarios in which this logic is exchanged using Stateless Session Beans or .NET-platform-specific options that happen to provide a limited degree of service orientation.
This approach is quite legitimate in circumstances such as tight coupling between a smart client and another back-end application - which simply would have been written as a single application, in the past. In situations where extensive document editing - such as sophisticated mathematical calculations - must be done on the client side, security requirements may mandate that these calculations must be recreated on the server side.
These characteristics should sound familiar. They're common in many multi-tier applications where interoperability is required among tiers, not just services between applications. These conditions create a tighter coupling between front- and back-end than is suitable for SOA, and they make interoperability tricky, as well. From a development standpoint, transmitting the business logic - a heavy payload - is nevertheless more efficient and cost-effective than writing the same logic twice or developing it in two environments.
Certainly, wholesale migration from one platform to the other is another path to interoperability. There are tools that semi-automate this process, such as, Microsoft's Java Language Conversion Assistant (JLCA). Nevertheless, a good deal of manual revision is still required, and few companies are willing to or capable of undertaking the task - not to mention the risks associated with sizable migrations.
In conclusion, when "pure" SOA or complete migration are not ideal options for achieving interoperability, developers need to consider some sort of bridge.
Part II of this series will explore ways to tackle interoperability without SOA or web services and with minimal risk, including project requirements to make the solution development process and repeated integration as reliable and automatic as possible. Part II also will address the advantages and disadvantages of commercial and open source alternatives to achieve these requirements.
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.