July 24, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

.NET/Java Interoperability: Apply the Proper Tool for the Job

  • May 10, 2004
  • By Kenn Scribner
  • Send Email »
  • More Articles »

Remoting

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!

If you combine this five-fold increase in size with another (roughly) 30-percent increase in size for Base64 MIME encoding, necessary when transmitting binary data using XML, you can see that sending SOAP XML responses of any complexity can result in very large XML files, which the remote server must process. If the server processes the SOAP XML using the XML Document Object Model (DOM), the size of the data in the server's memory commonly increases by an additional five-fold to allow for quick tree-based data access as well as XPath queries. (XPath is a query language for retrieving XML data from a DOM-based XML infoset.)

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.

Database

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.

Final Thoughts

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:

  • Keith Organ's article, "Java/.NET Interoperability with the Microsoft.com Web Service"
  • Simon Guest's book Microsoft .NET and J2EE Interoperability Toolkit, ISBN 0735619220
  • Microsoft's "Application Interoperability, Microsoft .NET and Java J2EE" (.pdf form)
  • DevX.com's Special Report: "Java/.NET Interop: Bridging Muddled Waters"
  • About the Author

    Kenn Scribner is with Wintellect.





    Page 3 of 3



    Comment and Contribute

     


    (Maximum characters: 1200). You have characters left.

     

     


    Sitemap | Contact Us

    Rocket Fuel