Implementing Interoperability in XBikes

The development team faced several interesting and unusual challenges when they integrated the interoperability elements to the XBikes application:

• The application should demonstrate multiple interoperability techniques.

• The application should not be over-complicated.

• The application should be simple to configure.

• The application should not incur excessive performance penalties from the interoperability methods.

Achieving these aims involved adding interoperability components to the design of both the .NET Framework and J2EE versions of XBikes. This next section covers these changes at the architectural level, looking first at how the developers customized the J2EE version, and the equivalent process in the .NET Framework version. Chapters 7 to 9 then show the details of how the developers implemented these components.

Note

The XBikes application implements multiple service interfaces and interoperability adapters between each connection point to demonstrate how to use each interoperability mechanism. However, in a production environment, you would probably implement only one or two between each connection point, depending on your interoperability requirements.

Adding J2EE Presentation to Business Tier Interoperability

This section looks at the interoperability components that the developers designed into the Presentation and Business tiers of the J2EE version of XBikes to enable interoperability with the corresponding tiers in the .NET Framework version. The client-facing JSP/Struts components in the Presentation tier did not change significantly. However, the developers made significant changes to the way in which calls from the Presentation tier pass to the Business tier. These changes involved adding interoperability components to both the J2EE Presentation and Business tiers.

The following are components that add interoperability features to the J2EE version:

• Service interfaces in the Business tier.

• Use case interoperability adapters in the Presentation tier.

• Use case interoperability adapter factory in the Presentation tier.

• An XML configuration file for the use case interoperability adapter factory.

Figure 6.8 shows how the developers implemented these components.

Figure 6.8: XBikes on J2EE Presentation and business tiers with interoperability elements added

The next section describes the interoperability components the developers added.

J2EE Service Interfaces

To expose the J2EE Business tier to both the J2EE and .NET Framework Presentation tiers, the developers added multiple service interfaces. Each service interface exposes the J2EE Business tier through different interoperability mechanisms. There are four services interfaces in the J2EE Business tier:

• Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) — Exposes the J2EE Business tier through RMI-IIOP for remote consumption by the J2EE Presentation tier.

• Web service — Exposes the J2EE Business tier through a Web service for consumption by either the .NET Framework or J2EE Presentation tiers.

• Ja.NET — Exposes the J2EE Business tier through a Ja.NET runtime bridge for consumption by the .NET Presentation tier.

• JNBridgePro — Exposes the J2EE Business tier through a JNBridge runtime bridge for consumption by the .NET Presentation tier.

Although the RMI-IIOP service interface is specific to J2EE, the WS service interface can field requests from either environment.

Note

RMI-IIOP uses Remote Method Invocation, the Java equivalent of .NET Remoting.

J2EE Use Case Interoperability Adapters

To communicate with either the J2EE or .NET Framework Business tiers, the developers added interoperability adapters to the J2EE Presentation tier. For flexibility, the XBikes developers implemented a series of interoperability adapters for each use case, making it easy to select which interoperability technology to use, depending on whether the next tier is on the same or the alternate platform. The XBikes design refers to these interoperability adapters as use case interoperability adapters.

Take the example of the AuthenticateCustomer use case. For this use case, the J2EE developers implemented five use case interoperability adapters:

• Inproc — Addresses J2EE Business tier’s business service fa ade directly through an in-process call in a single computer environment.

• RMI-IIOP — Addresses J2EE Business tier RMI-IIOP service interface.

• J2EE Web service — Addresses J2EE Business tier WS service interface.

• .NET Framework Web service — Addresses .NET Framework Business tier WS service interface.

• Ja.NET — Addresses .NET Framework Business tier Ja.NET service interface.

Here you can see that there are three ways of linking from the J2EE Presentation tier to the J2EE Business tier, and two ways of linking from the J2EE Presentation tier to the .NET Framework Business tier.

Because the design implements five interoperability adapters for each of the six use cases, there are a total of thirty use case interoperability adapters in the XBikes J2EE Presentation tier.

J2EE Use Case Interoperability Adapter Factory

To increase the flexibility in selecting interoperability adapters, the developers added an interoperability factory to the J2EE Presentation tier. Rather than call the use case interoperability adapters directly, the J2EE Presentation tier components first call an interoperability adapter factory, which the design calls the use case interoperability factory. The factory then checks with an XML configuration file to discover which use case interoperability adapter to select for each use case. The J2EE Presentation tier components then invoke that use case interoperability adapter to connect to the .NET Framework or J2EE Business tiers.

Note

This configuration technique allows you to specify different use case interoperability adapters for individual use cases, giving you maximum flexibility. If you do not foresee the need to change the adapters, you can omit the factory and simply load the correct adapter within your Presentation tier logic.

For example, when a user tries to log on to the XBikes Web site, this action requires the AuthenticateCustomer use case. Rather than select and call the use case interoperability adapter directly, the Web page calls the use case interoperability adapter factory. The use case interoperability adapter factory checks with the configuration file, which contains configuration information mapping use cases to use case interoperability adapters. The factory then returns and loads the correct use case interoperability adapter for the requested use case.

J2EE XML Configuration File

The use case interoperability adapter factory in the J2EE application retrieves configuration information from WebConfig.xml. This file contains a text-based listing of settings that link the use cases to the use case interoperability adapters. Hence the AuthenticateCustomer use case might be set to use the .NET Framework Web service use case interoperability adapter, whereas the GetCategories use case could be set to use the RMI-IIOP use case interoperability adapter. This ensures no interdependence between use cases.

For more information about the settings available to the use case interoperability adapter factory in the J2EE Presentation tier, see Appendix A.

Adding J2EE Business to Data Tier Interoperability

The developers added interoperability components on the J2EE Business and Data tiers to enable interoperability. The J2EE XBikes application has two resources in the Data tier — the SQL Server database and a WebSphere MQ message queuing system. Instead of calling resources in the Data tier directly, the J2EE Business tier components make calls through the various interoperability components.

Interoperability components added to enable interoperability on the J2EE Business and Data tiers include the following:

• Service interfaces in the Data tier.

• Resource interoperability adapters in the Business tier.

• Resource interoperability adapter factories in the Business tier.

• An XML configuration file for the resource interoperability adapter factories.

Figure 6.9 shows how these elements appear.

Figure 6.9: XBikes on J2EE Business and Data tiers with interoperability elements added

The next section describes the interoperability components the developers added.

J2EE Service Interfaces

The developers added multiple service interfaces to expose the resources in the J2EE Data tier to both the J2EE and .NET Framework Business tiers. Each service interface exposes a resource in the J2EE Data tier through a different interoperability mechanism.

There are four service interfaces to expose the database resource, or Data Access Logic tier, in the J2EE Data tier:

• Remote Method Invocation over Internet Inter-Orb Protocol (RMI-IIOP) — Exposes the J2EE Data Access Logic resource by way of RMI-IIOP for remote consumption by the J2EE Business tier.

• Web service — Exposes the J2EE Data Access Logic resource through a Web service for consumption by either the .NET Framework or J2EE Business tiers.

• Ja.NET — Exposes the J2EE Data Access Logic resource through a Ja.NET runtime bridge for consumption by the .NET Framework Business tier.

• JNBridgePro — Exposes the J2EE Data Access Logic resource through a JNBridge runtime bridge for consumption by the .NET Framework Business tier.

Like with the Presentation to Business tier interface, the RMI-IIOP service interface is J2EE-specific; whereas the WS service interface can field requests from either environment.

There are three service interfaces that expose the WebSphere MQ message queuing resource:

• RMI-IIOP-JMS — Exposes the WebSphere MQ resource for remote consumption by the J2EE Business tier.

• Ja.NET-JMS — Exposes the WebSphere MQ resource through a Ja.NET runtime bridge that uses JMS to connect to the .NET Framework Business tier.

• JNBridge-JMS — Exposes the WebSphere MQ resource through JNBridge that uses JMS to connect to the .NET Framework Business tier.

The developers also implemented a sample console application that reads messages from the WebSphere MQ message queue and sends them to the Data Access Logic service fa ade.

J2EE Resource Interoperability Adapters

The developers also added interoperability adapters to the J2EE Business tier to communicate with either the J2EE or .NET Framework Data tiers. They also implemented a set of interoperability adapters for each resource in the Data tier to demonstrate multiple interoperability techniques. The design refers to these as resource interoperability adapters. Unlike the use case interoperability adapters in the J2EE Presentation tier where there is a set of interoperability adapters for each use case, there is only one set of resource interoperability adapters for each resource’s service interface.

To communicate with the Data Access Logic resource in both the .NET Framework and J2EE Data tiers, the developers implemented the following resource interoperability adapters:

• InProc — Addresses the Data Access Logic service fa ade in the J2EE Data tier directly through an in-process call in a single computer environment.

• RMI-IIOP — Addresses the Data Access Logic resource RMI-IIOP service interface in the J2EE Data tier.

• J2EE Web service — Addresses the Data Access Logic resource WS service interface in the J2EE Data tier.

• .NET Framework Web service — Addresses the Data Access Logic resource WS service interface in the .NET Framework Data tier.

• Ja.NET — Addresses the Data Access Logic resource Ja.NET service interface in the .NET Framework Data tier.

This gives you three ways of linking from the J2EE Business tier to the Data Access Logic resource in the J2EE Data tier, and two ways of linking from the J2EE Business tier to the Data Access Logic resource in the .NET Framework Data tier.

To communicate with the WebSphere MQ message queuing resource in the J2EE Data tier, the developers implemented only one resource interoperability adapter. This uses the JMS API to place messages in the WebSphere queue. The PlaceOrder use case command in the Business tier is the only process that calls this resource interoperability adapter.

J2EE Resource Interoperability Factories

The developers added interoperability adapter factories to the J2EE Business tier to provide flexibility when selecting the interoperability mechanism for connecting to Data Access Logic and queue resources in the J2EE Data tier. Instead of calling the resource interoperability adapters directly, the J2EE Business tier components first call the interoperability adapter factory, which the design calls the resource interoperability factory. The factory checks with an XML configuration file to discover which interoperability adapter to select to connect to the resource. The J2EE Business tier components then use that resource interoperability adapter to connect to the corresponding resource in the .NET Framework or J2EE Data tiers.

The XBikes design implements two resource interoperability adapter factories:

• Data Access Logic

• Queue

The resource interoperability adapter factories work the same way as the use case interoperability adapter factory in the Presentation tier. The only difference is that they return interoperability adapters for the Data Access Logic and message queue resources in the Data tier.

Like with the Presentation tier, this configuration technique allows you to specify different resource interoperability adapters for two resources, giving you maximum flexibility. If you do not foresee the need to change the adapters, you can omit the factory and simply load the correct adapter within your Business tier logic. However, it is recommended that you implement interoperability adapter factories to keep your application responsive to future changes.

J2EE XML Configuration File

The resource interoperability adapter factory in the J2EE application retrieves configuration information from an XML configuration file named Bllconfig.xml. This XML file contains settings linking the resources to the resource interoperability adapters. For example, you might configure the Data Access Logic resource interoperability factory to use the .NET Framework Web service resource interoperability adapter for all calls to the Data Access Logic.

For more information about the settings available to the resource interoperability adapter factories in the J2EE Business tier, see Appendix A.

Adding .NET Framework Presentation to Business Tier Interoperability

The interoperability components the developers implemented in the .NET Framework Presentation and Business tiers are very similar to those in the corresponding tiers of the J2EE version of XBikes. The components that add interoperability features to the .NET Framework version include the following:

• Service interfaces in the Business tier.

• Use case interoperability adapters in the Presentation tier.

• Use case interoperability adapter factory in the Presentation tier.

• An XML configuration file for the use case interoperability adapter factory.

Figure 6.10 shows how the linking of the Presentation and Business tiers with the .NET Framework interoperability components added.

Figure 6.10: XBikes on .NET Framework Presentation and Business tiers with interoperability elements added

The next section describes the interoperability components the developers added.

.NET Framework Service Interfaces

To expose the .NET Framework Business tier to both the .NET Framework and J2EE Presentation tiers, multiple service interfaces were added. In the J2EE Business tier, each service interfaces exposes the .NET Framework Business tier by way of different interoperability mechanism. There are three services interfaces in the .NET Framework Business tier. The service interfaces are the following:

• .NET Remoting — Exposes the .NET Framework Business tier by way of .NET Remoting so that it can be consumed by the .NET Framework Presentation tier remotely.

• Web service — Exposes the .NET Framework Business tier by way of a Web service so that it can be consumed by either the .NET Framework or J2EE Presentation tiers.

• Ja.NET — Exposes the .NET Framework Business tier by way of Ja.Net for consumption by the J2EE Presentation tier.

Although the .NET Remoting service interface is .NET Framework-specific, the WS service interface can field requests from either environment.

Note

The .NET Remoting service interface uses typed datasets to exchange data between .NET Framework components. There is a known performance issue when sending DataSet objects across .NET Remoting calls. This is due to the way DataSet objects are serialized in the .NET Framework version 1.0 and 1.1. In a production application, consider implementing surrogate classes that implement their own serialization process for higher performance.

.NET Framework Use Case Interoperability Adapters

As in the J2EE version, to communicate with either the J2EE or .NET Framework Business tiers, interoperability adapters were added to the .NET Framework Presentation tier. In the J2EE Presentation tier, a series of interoperability adapters were implemented for each use case. This enables you to choose different interoperability mechanisms to connect for each use case. These interoperability adapters are referred to as use case interoperability adapters.

The .NET Framework application requires different use case interoperability adapters than the J2EE application to reflect the mechanisms for communicating between the .NET Framework and J2EE Presentation and Business tiers. The .NET Framework developers implemented the following six interoperability adapters for each use case:

• InProc or native mode adapter — Addresses .NET business fa ade directly.

• .NET Remoting adapter — Addresses .NET Remoting service interface.

• .NET Web services adapter — Addresses .NET WS service interface.

• J2EE Web services adapter — Addresses J2EE WS service interface.

• J2EE Ja.NET adapter — Addresses J2EE Ja.NET service interface.

• J2EE JNBridge adapter — Addresses J2EE JNBridge service interface.

There are three ways of linking from the .NET Framework Presentation tier to the .NET Framework Business tier and three ways of linking from the .NET Framework Presentation tier to the J2EE Business tier for each use case. Because six interoperability adapters are implemented for each of the six use cases, there are a total of 36 use case interoperability adapters in the XBikes .NET Framework Presentation tier.

Note

The InProc use case interoperability adapter can only be used in a single computer environment when calls can be made natively to the Business tier on the same computer without the need for going across the network.

.NET Framework Use Case Interoperability Adapter Factory

An interoperability adapter factory was added to the .NET Framework Presentation tier so you can use a variety of interoperability mechanisms. Instead of calling the use case interoperability adapters directly, the .NET Framework Presentation tier components first call an interoperability adapter factory, referred to as use case interoperability factory, which then checks with an XML configuration file to discover which use case interoperability adapter to use for each use case. The .NET Framework Presentation tier components then use that use case interoperability adapter to connect to the .NET Framework or J2EE Business tiers.

The use case interoperability adapter factory in the .NET Framework Presentation tier is similar to the one in the J2EE Presentation tier.

.NET Framework XML Configuration File

The use case interoperability adapter factory in the .NET Framework version of the XBikes application retrieves configuration information from the XML-based Web.config configuration file of the ASP.NET Presentation tier application. Like the J2EE version, this file contains a text-based listing of settings linking the use cases to the use case interoperability adapters.

For more information about the settings available to the use case interoperability adapter factory in the .NET Framework Presentation tier, see Appendix B.

Adding .NET Framework Business to Data Tier Interoperability

The developers added components to the .NET Framework Business and Data tiers to enable interoperability. Like the J2EE version, the .NET Framework XBikes application has two resources in the Data tier. These are the SQL Server database and a message queuing system. Instead of calling resources in the Data tier directly, the .NET Framework Business tier components make calls through the various interoperability components.

The following are interoperability components added to enable interoperability on the .NET Framework Business and Data tiers:

• Service interfaces in the Data tier.

• Resource interoperability adapters in the Business tier.

• Resource interoperability adapter factories in the Business tier.

• An XML configuration file for the resource interoperability adapter factories.

Figure 6.11 shows how the developers implemented these components.

Figure 6.11: XBikes on .NET Framework Business and Data tiers with interoperability elements added

Architecturally, this diagram is very similar to the J2EE version in Figure 6.9.

.NET Framework Service Interfaces

The developers added multiple service interfaces to expose the resources in the .NET Framework Data tier to both the J2EE and .NET Framework Business tiers. Each service interfaces presents a resource in the .NET Framework Data tier through a different interoperability mechanism.

There are three service interfaces that expose the database resource or Data Access Logic tier in the .NET Framework Data tier:

• .NET Remoting — Exposes the .NET Framework Data Access Logic resource through .NET Remoting for remote consumption by the .NET Framework Business tier.

• Web service — Exposes the .NET Framework Data Access Logic resource through a Web service for consumption by either the .NET Framework or J2EE Business tiers.

• Ja.NET — Exposes the .NET Framework Data Access Logic resource though a Ja.NET runtime bridge for consumption by the J2EE Business tier.

Although the .NET Remoting service interface is .NET Framework-specific, the WS service interface can field requests from either environment.

Like the J2EE version of XBikes, a sample console application reads OrderData messages off of a MSMQ queue then calls the Data Access Logic service fa ade and adds the order to the database. You can consider this sample console application (DALMSMQServiceInterface) a fourth service interface for the Data Access Logic. Unlike the J2EE version, the .NET Framework version requires no service interfaces to expose MSMQ to the .NET Framework Business tier, because the MSMQ resource interoperability adapter can communicate with MSMQ directly.

.NET Framework Resource Interoperability Adapters

The developers added multiple interoperability adapters were added to the .NET Framework Business tier to communicate with either the J2EE or .NET Framework Data tiers. To demonstrate multiple interoperability techniques, the design implements a set of interoperability adapters or resource interoperability adapters for each resource in the Data tier. Unlike the use case interoperability adapters in the .NET Framework Presentation tier, there is only one set of resource interoperability adapters for each resource’s service interface.

To communicate with the Data Access Logic resource in both the .NET Framework and J2EE Data tiers, the developers implemented the following resource interoperability adapters:

• InProc or native mode adapter — Addresses the .NET Framework Data Access Logic service fa ade directly through an in-process call in a single computer environment.

• .NET Remoting adapter — Addresses the Data Access Logic resource in the .NET Framework Data tier through a .NET Remoting service interface.

• .NET Web services adapter — Addresses the Data Access Logic resource in the .NET Framework Data tier through a WS service interface.

• J2EE Web services adapter — Addresses the Data Access Logic resource in the J2EE Data tier through a WS service interface.

• J2EE Ja.NET adapter — Addresses the Data Access Logic resource in the J2EE Data tier through the Ja.NET service interface.

• J2EE JNBridge adapter — Addresses the Data Access Logic resource in the J2EE Data tier through the JNBridge service interface.

These adapters give you three ways of linking from the .NET Framework Business tier to the Data Access Logic resource in the .NET Framework Data tier and three ways of linking from the .NET Framework Business tier to the Data Access Logic resource in the J2EE Data tier.

Note

You can only use the InProc use case interoperability adapter in a single computer environment as InProc does not support connections to a remote computer.

To communicate with the message queuing resources in the .NET Framework and J2EE Data tiers, the developers implemented the following three resource interoperability adapters:

• MSMQ — Uses the System.Messaging namespace addresses to address the MSMQ queue resource in the .NET Framework Data tier.

• WebSphere MQ-Ja.NET-JMS — Uses Ja.NET and JMS to address the WebSphere MQ queue in the J2EE Data tier.

• WebSphere MQ-JNBridge-JMS — Uses JNBridge and JMS to address the WebSphere MQ queue in the J2EE Data tier.

Again, the PlaceOrder use case command in the Business tier is the only use case that accesses these resource interoperability adapters.

.NET Framework Resource Interoperability Factories

The developers added interoperability adapter factories to the .NET Framework Business tier to increase flexibility in selecting which interoperability mechanism connects with the Data Access Logic and queue resources in the .NET Framework Data tier. The design implements these interoperability adapter factories in the same fashion as the corresponding ones in the J2EE Business tier and refers to them as resource interoperability adapter factories.

The developers implemented two resource interoperability adapter factories in XBikes, one for the Data Access Logic and one for the queue.

.NET Framework XML Configuration File

The resource interoperability adapter factory in the .NET Framework application retrieves configuration information from an XML configuration file named Dllhost.exe.config. This file in the \System32 folder and contains a text-based listing of settings linking the resources to the resource interoperability adapters. For example, you could configure the Data Access Logic resource interoperability factory to use the J2EE Web service resource interoperability adapter for all calls to the Data Access Logic.

Note

This configuration is for illustrative purposes only. A production application should not read configuration settings from the \System32 folder. For application security best practices, refer to http://www.microsoft.com/practices.

For more information about the settings available to the resource interoperability adapter factories in the .NET Framework Business tier, see Appendix B.