un’s Java 2 Enterprise Edition and Microsoft’s .NET Framework represent the two undisputed titans of n-tier, enterprise software platforms. Although most IT departments will standardize on one of these platforms as their exclusive dance partner, it’s often necessary and sometimes even desirable to tango with both platforms.

Other articles in this special report cover Web services and binary Java/.NET interoperability, but those aren’t always the best solution, particularly when your applications depend on asynchronous processes. In this article you’ll see two additional interoperability solutions: a shared database and message-oriented middleware. Although these two approaches are considerably less trendy than XML Web services, and perhaps not as exciting as binary interoperability solutions, they are more established, and in some cases more viable, integration solutions.

Build the Sample Project
The sample project that accompanies this article uses a simple case study of a meeting scheduler. A shared database stores meeting requests and scheduled meetings. This database is accessible by both J2EE and .NET clients. This case study will be referenced throughout the database interoperability section. The article concludes by identifying opportunities for extending the application to leverage messaging capabilities of both J2EE and .NET.

Figure 1. The Meeting Scheduler Application: The main page of this sample Web application is a static HTML page that lets users choose among three options.

Figure 2. Meeting Request Submissiong Form: When users elect to create a new meeting, this ASP-driven Web Form appears, letting them enter and submit the request.

Application Design
The application design is very simple. A static HTML page displays a menu of options with three links (see Figure 1).

Figure 3. Viewing Meetings: This JSP page lets users view a list of approved meeting requests.

The first option links to an ASP.NET page that provides a form allowing a user to submit a meeting request (See Figure 2).

The application logs the submitted request into a SQL Server database (MeetingScheduler) in the MeetingRequests table. The second item in the main menu links to a JSP page that allows an administrator to approve or deny meeting requests. Approved requests result in a new record being inserted into the MeetingSchedule table. Denied requests are flagged via the Accepted field in the MeetingRequests table. Finally, the third menu item links to a JSP page that displays the list of approved meetings (See Figure 3).

Database Interoperability
Integrating technologies via a shared data store is a common, and often easily implemented, solution. In many cases, the interfaces that permit each technology to access the underlying database can function independently from one another. This is certainly true in the case of J2EE access and .NET access. Their respective database connections are distinct from one another; each technology communicates with the database just as they do normally.

The database houses tables, views, stored procedures, and supporting metadata. All of this is accessible by the .NET framework via ADO.NET. Likewise, these resources are accessible by the J2EE platform via JDBC. Each platform is able to access the database using standard API calls?in other words, you don’t need to do write special code to achieve interoperability using this solution. Data is inserted, updated, deleted, and selected. When one platform modifies the data in some way, the other platform will see those modifications when it next requests data from the database.

Pros: Database Interop
Due to the fact that the interaction with the database is handled no differently than usual, there is no risk from the database interaction standpoint. Each platform communicates with the database in the usual fashion (API calls translated by some type of database driver component) without regard for how many other systems running on different platforms might later access the data. Developing this type of solution is fast, because there are no unknown variables in this type of integration.

Cons: Database Interop
Using a shared database for interoperability does not allow you to connect business processes running on disparate platforms into a single transaction. Instead, one platform inserts or updates data, and then another platform later accesses the changed or added data. This severely limits the capabilities for cross-platform business process management.

How the Sample Application Works
In the sample project, the ASP.NET page lets a user submit a request for a new meeting. This request is stored in the MeetingRequests database table. Later, a JSP page reads the data from this table and either accepts or rejects the meeting request. There you have it?interoperability via a shared database! Note that this solution works best when the two processes are asynchronous, as in this case, and when you don’t need transactional capability across platforms.

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.

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.