Fail-Safe Interop for Your Enterprise
Discover strategies for invoking distributed services to achieve interoperability and integration among J2EE and .NET components
by Daniel F. Savarese

Application interoperability is a constant requirement in enterprise computing. With Java 2 Platform, Enterprise Edition (J2EE) and .NET taking over enterprise development, interoperability and integration will remain as important as ever. Despite the support both development platforms provide for open Web services standards, making the two work together is not as simple as plug and play.

Both interoperability and integration are fuzzy terms. Ask an IT manager and a programmer for a definition and you'll likely get two very different answers. An IT manager may be more concerned with whether or not a set of applications is supported on all of the operating systems that are used in a department. A programmer may be more concerned that departmental applications support the same programming interfaces.

One way to look at interoperability is as a property of software. Two applications are interoperable if they can interact in a useful manner without modification. This interaction may involve sharing data in a common format or communicating using a common network protocol. Integration can be viewed as the act of making disparate applications interact with each other in a useful manner. Therefore, the difficulty of integration is a function of the level of interoperability between the software elements being integrated.

As the level of interoperability increases, the difficulty—and hence the cost—of integration decreases. According to some studies, roughly 50 percent of IT software development and maintenance costs are directly related to integration concerns. It is no wonder why interoperability is so important to IT managers and programmers alike (although perhaps not consultants). High levels of interoperability mean less money and less time must be spent implementing and maintaining the software systems that make a business run.

In theory, one key to interoperability is open standards. Compliance with open standards guarantees that any vendor's product will work with any other vendor's. The Internet and the Web support many types of hardware, operating systems, and applications because their foundations are rooted in open standards. It is open standards that allow you to mix and match e-mail clients and Simple Mail Transfer Protocol (SMTP) servers, yet remain assured that you will be able to send and receive e-mail to and from anyone on the Internet. Still, as those familiar with HTML-induced Web browser woes that persist to this day know, open standards get you only so far.

Standards must be implemented, but standards are not always precise about how they should be implemented. Sometimes a standard may be incomplete and overlook a particular situation that must be handled. A standard may include optional features or use wording that is open to multiple interpretations. A standard may also evolve to a new version faster than applications supporting the standard can incorporate all of the features of an earlier version of the standard. All of these circumstances can lead to the development of applications that on the surface appear to be fully interoperable, but in reality require special treatment to work correctly.

J2EE and .NET
The implementation of Web services standards in J2EE and .NET suffers from such a case of quasi-interoperability. Before examining the caveats of J2EE and .NET Web services interaction, it helps to consider what we want from J2EE and .NET interoperability.

J2EE has now been around for at least half a decade. It's not a new kid on the block anymore. It was developed when many developers were bullish that Java could wipe out the need for enterprise application integration. Java offered a single language, virtual machine, and standard class framework that could be deployed on any operating system. Surely, all you needed to do was to migrate all of your internal application development to Java to achieve 100 percent application interoperability. As we now know, the situation was not that simple. Java can't do everything, and the best tool for a job doesn't always work well with the best tools you bought for all of those other jobs.

J2EE was designed without the prescience that XML would become the standard basis for interapplication communication. It provides its own distributed component development framework and communication system in the form of Enterprise JavaBeans (EJBs) and Remote Method Invocation (RMI), respectively (see Figure 1). J2EE was designed with interoperability in mind, supporting communication with Common Object Request Broker Architecture (CORBA) systems using Internet Inter-ORB Protocol (IIOP) and a variety of message queue systems through Java Message Service (JMS). When Web services began to emerge as the preferred means for building interoperable distributed components, J2EE incorporated a host of XML APIs to support Web services development. The most important of these APIs is probably Java for XML-Based Remote Procedure Call (JAX-RPC), which is a required API for J2EE 1.4.

Figure 1. Analyze the J2EE Web Services Architecture
Web services are incorporated typically into the J2EE environment as a kind of mid- or presentation-tier technology with a connection on one side to the Internet and a connection on the other to a JavaBean or class running in an application server container. This architecture derives from the fact that application servers are designed primarily to multiplex client connections from the Web to a shared database. (Source: Eric Newcomer, .NET Magazine, October 2002)

The .NET platform bears a similarity to J2EE in that its formative underpinnings, specifically COM+, were not designed with XML messaging in mind. Still, .NET fully anticipated the need to tie together components written in different programming languages and distributed across the Internet. Despite its incorporation of backward-compatibility features, .NET was really designed with XML messaging as the basic mechanism for interprocess communication. In fact, .NET was one of the main drivers for the development of Simple Object Access Protocol (SOAP). .NET also was designed with the explicit requirement to support different programming languages: among them, Visual Basic, C++, and the new C#. Like J2EE, .NET sports a platform-independent instruction set, a virtual machine—the Common Language Runtime (CLR)—and a rich class framework (see Figure 2). Unlike J2EE, .Net is implemented and supported by a single vendor on a single operating system family. The jury is still out on the success of initiatives to implement a subset of .NET for operating systems outside of the Windows family.

Figure 2. Assess How the .NET Architecture Measures Up
The .NET environment supports multiple development languages for producing Web services, and a common deployment environment in which to host Web services and other objects developed using those languages. The CLR is a consistent mechanism within .NET to host Web services and other objects. It's mapped to two communication protocols, HTTP and TCP, for exchanging SOAP messages. The TCP-based protocol is also called .Net remoting, and provides a more efficient and powerful protocol within the .NET environment (that is, when the objects are all developed and deployed using .NET). The HTTP protocol is useful for accessing objects developed externally, such as within a J2EE-compliant application server. J2EE doesn't have an equivalent for this consistent architecture. (Source: Eric Newcomer, .NET Magazine, October 2002)

Given the similarities between J2EE and .NET, one would think that they could work together at many levels. On close inspection, there are few workable integration points, and perhaps only one level at which interoperability can be reasonably achieved. J2EE and .NET cannot interact at the class library level because their virtual machines are incompatible. Therefore any integration between J2EE and .NET presupposes a Java Virtual Machine (JVM) and the CLR running in separate processes.

It is possible to use the Java Native Interface (JNI) to write native code that uses .NET facilities, but that, in effect, would be a custom bridging solution and limit an application to deployment on the restricted set of platforms supported by .NET. Once you restrict yourself to interprocess communication, the granularity of interaction between J2EE and .NET cannot be fine grained, such as would be the case if you could dynamically link CLR classes to classes in a JVM (see Figure 3).

Figure 3. Compare .NET and J2EE
The differences between the .NET and J2EE platforms present significant obstacles to interoperability, because .NET is tightly integrated with the Windows operating system and J2EE is operating-system independent. One primary difficulty to overcome is data-type and structure compatibility across different programming languages. Each language has different data types and structures; however, once you understand the differences, you can begin to understand the work that needs to be done to provide integrated applications. (Source: Richard Bonneau and Eric Newcomer, .NET Magazine, February 2003)

Interoperability Protocols
The J2EE 1.4 specification defines some interoperability requirements that you can use as a guide for integrating J2EE with other systems. The requirements specify a set of interoperability protocols all J2EE implementations must support. These protocols break down into four categories: Internet and Web protocols, Object Management Group (OMG) protocols, Java technology protocols, and data formats. Data formats are self-explanatory and include XML. The list of Java technology protocols is limited to RMI, which is no help in communicating with .NET. OMG protocols encompass CORBA, which is an option for integrating with .NET.

IIOP is a required part of all J2EE implementations. To use IIOP to access .NET components, you would need a CORBA ORB on the .NET system because .NET does not implement IIOP. Adding this additional layer of middleware raises the cost of integration and commits you to a specific vendor's CORBA-to-.NET bridging system; although, you could forgot a bridging system and write CORBA Interface Definition Language (IDL) wrappers for each of your .NET components. Internet and Web protocols include TCP/IP, HTTP, and SOAP. Using sockets or HTTP to communicate between components amounts to inventing your own RPC protocol. That leaves SOAP as the logical mechanism for coupling J2EE and .NET applications.

Through a set of APIs and tools, both J2EE and .NET support the exporting of objects as Web services components that communicate using SOAP. .NET goes a little further than J2EE in its use of SOAP because SOAP forms the basis for .NET remoting, the equivalent of Java RMI. SOAP provides the highest level of interoperability and lowest cost of integration between J2EE and .NET, but that doesn't mean there aren't problems with SOAP-based component communication.

One of the problems that crops up with the remote procedure call communication model is that not all languages support the same data types. Java does not include unsigned numerical types, and the JAX-RPC specification overlooks unsigned numerical types. Therefore, you cannot rely on J2EE clients to work with .NET services that use unsigned numerical types. The XML Schema specification does not define a char type, and the JAX-RPC specification does not define how char types should be mapped to XML. Therefore, you cannot be certain if J2EE services that return char values or accept char arguments will work with .NET clients or work at all for that matter. Some JAX-RPC implementations may map char values to xsd:anyType, but the JAX-RPC specification does not define any standard mapping of xsd:anyType to a Java type. Therefore, you cannot even be certain that a J2EE service that uses char types will work with a J2EE client!

Other data types that cause interoperability problems are enumerations and complex types. JAX-RPC defines how enumerations are mapped to Java. Enumerations are mapped to a Java class with the same name as the enumeration and containing static final members corresponding to the enumerated range of values. JAX-RPC is silent about how to map a Java type to an enumeration. Complex types are problematic because not all languages support the same complex types. J2EE-to-J2EE interoperability is maintained because JAX-RPC specifies how to convert Java classes into XML and back. However, J2EE-to-.NET interoperability is not maintained. Even though both Java and C# have hashtable classes, there is no guarantee a .NET client will unmarshal the XML produced by a java.util.HashMap return value from a J2EE service into a System.Collections.Hashtable.

Additional complications arise with exceptions. JAX-RPC maps some exceptions to SOAP fault codes so that remote exceptions can be handled consistently within J2EE Web services. This seems all right on the surface, but there is no guarantee that a fault code produced by a .NET service will have the same intended meaning as a Java exception.

The encoding of binary data presents yet another problem. JAX-RPC supports the "SOAP with Attachments" specification, but .NET does not (at least not yet). Therefore, you cannot exchange binary data using attachments if you want to retain any hope of having J2EE and .NET Web services components work together. Without attachments, you are left with the option of using xsd:base64Binary and xsd:hexBinary types as service parameters. JAX-RPC implementations will convert between these types and byte arrays automatically, but it can be inefficient to send large amounts of binary data in this manner.

Interoperability Guidelines
Even with all of the current SOAP communication pitfalls, if you are careful you can ensure your J2EE and .NET components will be able to invoke each other's methods without problems. The most important rule of thumb applies to any software development endeavor: test your code in as many different scenarios as possible. Test your J2EE services against .NET clients and your .NET services against J2EE clients.

If you've never used .NET, you don't need Visual Studio to write a test client. If you download the Microsoft .NET Framework SDK, you'll have all the documentation and tools you need. The easiest way to write a .NET client is to use the wsdl.exe tool to generate a C# or Visual Basic class for accessing your Web service. The wsdl.exe tool is analogous to a JAX-RPC stub generator. It accepts a Web Services Description Language (WSDL) file as input and generates client or server stubs depending on the options you give it. Be warned, though, that the version of wsdl.exe in the .NET Framework SDK release dated 03/05/2002 has a major bug in it. It ignores the port number in service URLs, causing the source code that is generated to omit the port number in URLs used to invoke a service. Therefore, if your development environment depends on a service container that uses a port number other than 80 to service HTTP connections, either you will have to edit the generated code or postprocess it with a shell script to add the missing port number to the URLs.

Most SOAP interoperability problems result from using it as vehicle for making remote procedure calls. The use of RPC necessitates the specification of type mappings and serialization strategies for complex types. You can sidestep these issues by using SOAP as a medium for document-based messaging. The problem with this approach is that it requires more effort to develop service clients. A client must now understand the schema definitions used by a service rather than rely on WSDL-derived code generators to assemble requests and disassemble results.

Another factor that complicates SOAP interoperability is that development tools have turned Web services programming into a process where you write a class in a programming language and generate WSDL based on the class. This process makes it more likely that a Web service will require parameters or generate return values that are not supported by all languages. Therefore, to maximize the chances a client will be able to communicate with your service, you should create your WSDL first and generate class skeletons from the WSDL. By creating the WSDL yourself, you can ensure you avoid using data types that are not supported universally, such as unsigned integers.

Data typing incompatibilities mandate that you avoid complex types when possible and always use arrays instead of collection classes. Arrays are supported universally by SOAP implementations, but complex types will be handled unpredictably. Also avoid writing services that throw exceptions or clients that depend on catching a specific type of exception. Rely on SOAP fault codes instead. Exceptions can be interpreted reliably only when JAX-RPC is working both ends of the communication. On the other hand, SOAP fault codes and their meaning are defined by the SOAP specification, enabling you to interpret them reliably. Finally, avoid using attachments if you want to interoperate with .NET.

Other Solutions
If you are willing to commit yourself to proprietary systems, J2EE and .NET interoperability solutions other than SOAP do exist. You can buy Java-to-.NET bridging products that allow Java programs to use .NET classes and vice versa. These products work by creating proxy classes that forward method calls to the real classes. You still have to host the .NET classes in a CLR environment and your Java classes in a JVM. Communication between the two environments can be optimized by using the .NET remoting binary protocol (basically COM+). But if the bridging product uses SOAP, there is little benefit to using the product because you can already use SOAP without a bridge.

The use of message queues should not be discounted for integrating J2EE and .NET systems. If your applications do not rely on an RPC view of interprocess communication, message-oriented middleware offers reliable asynchronous message delivery. With the right adapter, you can use JMS to interface with Microsoft Message Queuing (MSMQ). This approach requires more work because your .NET applications must be written to expect their communication to come through MSMQ rather than .NET remoting or SOAP. If you want to remain interoperable with arbitrary third-party .NET services, this solution is not viable.

Microsoft and IBM launched the Web Services Interoperability Organization (WS-I) last year. Part of its stated purpose is to "promote consistent and reliable interoperability among Web services across platforms, applications, and programming languages," which sounds like it should do a lot to improve SOAP interoperability. Sun Microsystems was not involved with WS-I from the start, but has since joined. This move should help keep attention focused on J2EE interoperability. However, one year into its existence, WS-I has not produced any implementation or testing tools. Nonetheless, it takes time for industry groups to organize themselves and start producing results. In time, WS-I should provide valuable interoperability guidelines.

The SOAPBuilders group (see Resources) has to this point done more than WS-I with regard to interoperability. SOAPBuilders is a group of developers who implement SOAP for a range of companies, products, and open source projects. The group has engaged in three major rounds of interoperability testing and posted test results and test clients on the Web. You can compare results for J2EE implementations and .NET to get an idea of what problems remain.

As Web services become more common, it is inevitable that J2EE and .NET will need to work side by side in the enterprise. The whole point to Web services is to provide interoperability. If you don't need to share service components between different programming languages and platforms, you don't need Web services. More efficient distributed computing systems have preceded Web services, but none of them enabled the high level of component reuse made possible by the open standards-based Web services protocol stack.

The J2EE and .NET development tools and frameworks are making it much easier to create distributed services. So easy, in fact, that they encourage programmers to export even the most fine-grained objects as services. The RPC programming model is responsible for ease of programming but also for creating a host of interoperability headaches. Most interoperability problems vanish when applications work strictly with XML documents instead of remote procedure calls. But document-based messaging requires more programming effort, increasing the cost of development.

All the indications are that RPC-style component access will dominate. Most interoperability problems will likely be resolved by concerted industry efforts such as WS-I, but the interoperability achieved by Web services will come at a price. That price will be a gamut of applications that make inefficient use of network resources, treating remote objects and their methods as though they were local. Once interoperability is conquered, perhaps there will be interest in addressing performance.

Resources

About the Author
Daniel F. Savarese is an independent software developer and technology advisor. He has been the founder of ORO Inc., a senior scientist at Caltech's Center for Advanced Computing Research, and vice president of software development at WebOS. Daniel is the original author of the Jakarta-ORO text processing packages and the NetComponents network protocol library. He is also a coauthor of How to Build a Beowulf and is working on several book projects.