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 callsin 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 itinteroperability 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.