Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Java/.NET Interoperability via Shared Databases and Enterprise Messaging : Page 3

Using technologies such as shared databases and messaging to provide Java/.NET interoperability may not be as sexy as Web services or binary interoperability, but offers the least risk and the greatest flexibility.


advertisement
Messaging Interoperability
Integrating technologies via messaging is not nearly as simple and straight-forward as using a shared database can be. Messaging applications typically rely upon some type of Message-Oriented Middleware (MOM) to facilitate reliable message exchange via topics and queues. In homogenous, non-interop environments (all .NET or all J2EE), the use of a MOM server that supports that single environment is sufficient. However, to facilitate interoperable messaging (i.e. a heterogeneous environment), you need additional software adapters or bridges, so that both platforms can read and write to the same message queues. The specific solution that you implement necessarily depends upon the platform your enterprise uses for messaging. If you select Microsoft as your enterprise messaging platform, you can use BizTalk or Microsoft Host Integration Server to provide messaging interoperability. Both these products let you host your messaging using the Microsoft platform, while still integrating with J2EE messaging such as IBM's WebSphere MQ.

If, on the other hand you're using J2EE as your enterprise messaging platform, then you need to identify a J2EE product, such as FioranoMQ, that supports integration with Microsoft MSMQ. Pros: Messaging Interop
Unlike interoperability via a database, directly integrating the messages into the same MOM server lets you connect business processes on heterogeneous platforms. For example, you could create a message on a .NET client, send it to a queue on BizTalk, and then have the message consumed by a J2EE client running on a WebSphere MQ, Sonic MQ, or similar platform.

Cons: Messaging Interop
Introducing an enterprise messaging platform always increases the complexity of a system. Installing, configuring, and maintaining messaging software requires specialized skills and often a dedicated resource. Therefore, if your sole purpose for introducing an enterprise messaging system is to facilitate interoperability, it's probably not the most efficient solution. Consider Web services or a shared database as an alternative. If, however, you already have an enterprise messaging system in place, it may very well make sense to use the system to facilitate cross-platform interoperability.

Author's Note: Due to the sheer number of different messaging systems and the complexities of installing and configuring a messaging server, this article merely discusses interoperability via messaging subject in theory, and doesn't attempt to provide source code or setup instructions.

If you were to incorporate messaging capabilities into the Meeting Scheduler application, the most logical place would be to create publish/subscribe capabilities. Client applications would be able to register themselves with the application, indicating that they would like to receive updates regarding the meeting schedule. Then, the application would broadcast updates to the list of registered clients at some regular interval (every 12 hours, each day, each week, etc.). Such a scenario provides interoperability when both .NET and J2EE messaging clients can connect to the messaging server to send and receive messages.


Interoperability through messaging supports applications of this type better than standard Web services, because the process of submitting and approving meeting requests is inherently asynchronous. First, clients submit a request; then, at some unknown future time, a manager reviews and either approves or denies the request. It's easy to envision applications where the submitting client would prefer to receive a message indicating the result—in other words, having submitted a meeting, it would be nice to know as soon as possible whether the meeting request had been approved; however, the options available for doing that via Web services or binary interop are not particularly palatable. Sure, you can write applications that tell users to "Check back later to view the approved meeting list," or you could automate the task and have client applications poll the server periodically until the approval process was completed and they could discover the result, but neither method is as efficient or as satisfying as being able to tell the client the manager's decision directly and immediately. Periodic polling wastes resources when clients repeatedly request results before the approval process is complete, and wastes valuable client time when the approval process completes before the client requests the result. Using binary interop methods eliminates the repeated polling, but wastes memory, as both server and client must keep proxy objects in memory for the duration of the transaction and maintain a connection the entire time. Messaging was created to solve problems such as this, and there's still no better solution.

In spite of Bill Gates' or Java devotees' deepest desires, no universal software development platform will ever be adopted by everyone on earth. For as long as computer programming and software development exist, there will always be differing opinions regarding the best language or technology to solve a particular problem. Correspondingly, the software development landscape will always be in need of ways to communicate between heterogeneous languages and technologies. Interoperability is very much in demand. Of the interoperability options available, sharing a database is the most mature, offers the least risk and the greatest flexibility. Enterprise messaging provides a good middle-ground between maturity, risk, and flexibility, provided that your organization already has a messaging platform in place.



Kyle Gabhart is an independent consultant specializing in service-oriented architecture and application development with both .NET and J2EE technologies. Kyle is a popular public speaker and a prolific writer with dozens of published books and articles. You can find him on the Web at www.gabhart.com,or reach him by email here.
Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap