.NET/Java Interoperability: Apply the Proper Tool for the Job, Page 3
When all you have is a hammer, all the world looks like a nail. And given the popularity of XML Web services, as well as how simple it is to generate and consume one, it's easy to overuse the technology. The truth is, though, that XML Web services are but one tool you can use. They have a well-defined place in enterprise computing.
One place where they won't necessarily fit is where you have large amounts of data to transmit or have hard timing requirements for data processing. Data typically undergoes a significant size increase when moving from a binary representation into XML. A 32-bit integer, for example, consumes 4 bytes in your computer's memory but could consume anywhere from one to many bytes when converted into XML. For example,"-219857209" would require 10 bytes if encoded in single-byte text (UTF-8) and a whopping 20 bytes if encoded in multibyte form (UTF-16). This doesn't even count the XML tags!
The bottom line is that data sent via an XML Web service can grow very quickly, which may be detrimental to your enterprise application's processing capability. It just depends upon the given situation.
Where the situation calls for large datasets to be issued to and from the Web service, or where speed is a concern, .NET remoting might be helpful. Why use .NET remoting when joining .NET and Java? Because the specification that governs .NET remoting was released to ECMA as part of the CLI specification, resulting in several Java remoting bridge products, including JNBridgePro and Ja.NET. On the surface, a figure representing this situation might not appear that different from the Web service case (as shown in Figure 3).
Figure 3. Business Logic Using .NET Remoting Integration
However, the mechanics of the communication process differ significantly. For one thing, you don't have to process information through a Web server (although you can if you want). Instead, you can establish a direct socket connection using a binary formatting option for speed and efficiency. You won't be converting information into and out of XML, conserving processing time and memory, and you have a direct socket connection to and from the server into which to shove data very quickly.
The database integration technique isn't really new, but it is effective for many applications. Simply put, .NET and Java can interoperate at the database level where they process shared data. To the user, the application appears seamless, but in reality, the user is redirected between pages generated by either JSP/Struts or ASP.NET, depending upon the processing required (see Figure 4).
Figure 4. Shared Database Connection
This architecture is commonly used when integrating existing applications where new business logic can be rolled into an existing application structure. Note also that the database in Figure 4 could also be replaced with message-queuing technology, such as MQ Series or MSMQ.
Today, there are a greater number of options available for integrating Java/J2EE and .NET into a single enterprise application/environment. While the goal should be to share information between these platforms, a greater goal should be to analyze the business need and apply the proper tool to the situation, whether Java/J2EE or .NET. The good news is that current technologies offer options, and the possibilities for interesting and effective systems are endless.
Some other material you may find interesting can be found at these locations:
About the Author
Kenn Scribner is with Wintellect.
Page 3 of 3