Defining Interoperability

This book defines Interoperability as follows:

The ability to communicate or transfer data between functional units running on different platforms, implemented in different technologies, using industry standard or widely accepted data description and communication protocols.

For.NET/J2EE interoperability, this process consists of ensuring that applications built on one platform connect to those created on the other. Figure 1.1 shows the J2EE and .NET equivalent components in an enterprise application environment, and highlights the opportunity and need for interoperability at different tiers in the architecture.

Figure 1.1: J2EE and.NET equivalent components in an enterprise application environment

Organizations benefit from the greater flexibility of being able to choose the best from either enterprise application environment to suit their business needs. However, this interoperability should come with minimal performance overhead or reduction in functionality.

Understanding Interoperability Scenarios

Interoperability comes in a range of guises, with certain scenarios more likely than others, and some combinations either not possible or highly unlikely. This book concentrates on three main interoperability scenarios. These are the following:

• Integrating .NET components at the Presentation tier.

• Integrating .NET components at the Business tier.

• Implementing asynchronous interoperability.

Chapters 4 and 5 show the interoperability techniques you can use in these scenarios. Chapter 6 describes how to apply these techniques in an enterprise class application and summarizes the implementation strategies used in the XBikes sample application. Chapters 7, 8, and 9 work through each interoperability technique at the code level.

Integrating .NET Components in the Presentation Tier

Presentation tier to Business tier interoperability is a very common scenario, accounting for a large slice of all .NET/J2EE interoperability projects. Usually, interoperability between these two tiers involves replacing JSP elements with an ASP.NET-based front end to achieve a richer client experience. Figure 1.2 shows how such an implementation would look.

Figure 1.2: .NET Presentation tier linked to J2EE Business tier

The challenge with this first scenario is in getting the ASP.NET components to interact with the J2EE middle tier elements, as Figure 1.2 shows.

Integrating .NET Components in the Business Tier

The next scenario preserves the existing JSP front end but integrates .NET components in the Business tier. This approach allows developers to create programs and assemblies in .NET using any language that the .NET Framework supports. Reasons for implementing .NET Business tier components might include the need to respond to rapid changes in business practice or to make use of third party products. Figure 1.3 shows how such an implementation would look.

Figure 1.3: Integrating .NET Business tier components into a J2EE architecture

Here you have the challenge of two interfaces between .NET and J2EE — one from Presentation tier to Business tier and one from Business tier to Data tier. Chapter 8 gives a detailed example of how to do this.

Implementing Asynchronous Interoperability

This last major interoperability scenario covers the situation where you need to use transactional support, cope with long running transactions, or provide resilience to network outages. You provide these services by addressing an asynchronous resource or message queue component, such as Microsoft Message Queuing (also known as MSMQ) or IBM WebSphere MQ. Figure 1.4 shows this implementation.

Figure 1.4: Business tier to Data tier interoperability

An example of this scenario might be a link to an order queue that manages and monitors the production of a bespoke bicycle. The application can check items in the queue or can receive notification when a particular operation finishes. After the bicycle is complete, a message can go to the purchaser telling him or her that it is on its way.

Chapter 9 covers this scenario in detail.

Listing Interoperability Technologies

There are a number of ways in which you can implement J2EE to .NET interoperability. Each has particular advantages and disadvantages, and each works in some circumstances but not others. These technologies are the following:

• XML Web services.

• Runtime bridges.

• Message orientated middleware.

• Shared database.

• Integration brokers.

Web services define applications that deliver a service (usually by exposing a programmatic interface) where you can either fulfill client requests directly or integrate the provider service with other Web services using Internet standards. External consumers or applications communicate with Web services by means of XML formatted messages, usually using XML over HTTP. Both .NET-based and J2EE based applications can implement XML Web services.

Runtime bridges are third-party solutions that provide interoperability between J2EE and .NET, so that Java classes appear as .NET classes and vice-versa. This allows you to use .NET Remoting as a communication method, with the Runtime Bridge handling the calls to the Java side. This book looks at two products in this area, JNBridgePro from JNBridge and Ja.NET from Intrinsyc. Chapter 4 provides more information about these products.

Messaging offers an asynchronous mechanism for communicating between tiers, often based on MSMQ or IBM MQSeries. Messaging enables loosely coupled operation, particularly where you need more than just a one-to-one linkage between application components and Web services are not suitable. Messaging also supports transactions, security (encryption and authentication), tolerance for network outages, and recorded message delivery. However, messaging does not offer any form of synchronous operation and can cause issues with port assignments and firewall operation.

Shared database techniques often involve using some form of database independent connectivity API, such as Open Database Connectivity (ODBC) or Java Database Connectivity (JDBC) to provide a level of abstraction from the database itself (usually SQL Server or Oracle). However, challenges with this technique involve generating an appropriate database schema that all applications can address.

Integration brokers go beyond point-to-point connections to provide end-to-end integration of applications, enabling the automation of critical business processes across an entire distributed application or enterprise. Typically built on a messaging framework, integration brokers are particularly important in environments that use trading partners within the application solution. Integration brokers also provide prefabricated application adapters, allowing multiple external components such as mainframe or third-party applications to interact with the integration broker as either provider or consumer or both. Some leading integration broker products include IBM MQSeries Integrator, CommerceBroker, and Microsoft BizTalk Server 2004.

Note

Chapters 4 and 5 expand on all of these technologies except for integration brokers.

Linking Interoperability Technologies to Business Scenarios

Table 1.2 shows the possible interoperability permutations along with technologies that can provide solutions for each combination. The check marks indicate which techniques are appropriate for each scenario.

Table 1.2: Interoperability Scenarios

	Presentation to Presentation	Presentation to Business	Business to Business	Business to Data
XML Web Services
Runtime Bridges
Messaging
Shared Database
Integration Brokers

The recommended procedure wherever possible is to implement your interoperability solution using XML Web services. For a detailed discussion of the advantages and disadvantages of each interoperability technology, see Chapters 4 and 5 later in this book.