Java/.NET Interoperability via Shared Databases and Enterprise Messaging

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).