Chapter 7, “Integrating .NET in the Presentation Tier,” described how to integrate a .NET Framework Presentation tier with a J2EE Business tier and how to define Java service interfaces that encapsulate J2EE business service fa ades. It then covered the design of .NET Framework interoperability adapters so that .NET Framework applications, such as ASP.NET Web Forms, can invoke the Java service interfaces.
This chapter is the reverse of Chapter 7; it describes how to integrate a J2EE Presentation tier with a .NET Framework Business tier. It includes two sections that define different ways to achieve this interoperability:
Using Web Services for Interoperability — This section describes how to define .NET Framework Web service (WS) service interfaces to encapsulate .NET Framework business service fa ades. It then describes how to design Java interoperability adapters to enable Java code, such as a J2EE Presentation tier to invoke the .NET Framework WS service interfaces.
Using Ja.NET for Interoperability — This section describes how to use Ja.NET to enable a J2EE Presentation tier to access .NET Framework business service fa ades through the use of .NET Remoting.
For each of these approaches, this chapter describes how to address the following technical issues:
Determining data exchange formats and types.
Designing and building the service interface.
Designing and building the interoperability adapters.
The following sections briefly summarize how you can resolve these technical issues in the Web services and Ja.NET scenarios. The chapter then provides detailed descriptions of each scenario and describes what the XBikes developers did in the sample application.
As Chapter 7 illustrates, one of the keys to interoperability is to define and use consistent data exchange formats and data types in the .NET Framework and Java applications. This chapter describes how to expose data formats and data types from the .NET Framework Business tier and how to consume these data formats and data types in the J2EE Presentation layer.
A good way to achieve consistency is to define XML Schemas to represent your data types. You can then generate .NET Framework and Java classes that are compatible with the XSD types and use XML serialization to convert between XML data and objects in memory. This approach is particularly suitable when you use Web services as the interoperability mechanism, because Web services always exchange data in XML format (enclosed in a SOAP envelope).
When you use .NET Remoting as the interoperability mechanism, Ja.NET allows you to expose most .NET Framework data types to Java. You can therefore pass actual .NET Framework objects between the J2EE Presentation tier and the .NET Framework Business tier.
For a detailed discussion about data exchange factors, see Chapter 3, “Interoperability Fundamentals.”
As described in Chapter 7, the role of the service interface is to expose the functionality of the business service fa ade so that other parts of the application can access it.
Chapter 6, “Implementing Interoperability Design Elements,” described how the developers implemented the XBikes business service fa ade in .NET Framework. In your application, this could be either a serviced component or an ordinary .NET Framework class. The service interface exposes this .NET Framework functionality to the J2EE Presentation tier. The J2EE Presentation tier can call into the service interface, and then the service interface relays the calls on to the .NET Framework business service fa ade.
Depending on your implementation details, the service interface might need to manipulate data before it is passed into the business service fa ade, and it might also need to manipulate returned values from the business service fa ade.
Interoperability adapters change the data from your applications into a suitable format for interoperability. They also hide the implementation details of the interoperability technique from the connected applications.
You should create interoperability adapters based on the design of the service interface and the level of fine control that you require. You may choose either to build an interoperability adapter for each use case or implement a single interoperability adapter for each service. The interoperability adapters may have to change the structure of the data before returning it to the calling application.
In the XBikes application, the developers created an interoperability adapter for each use case. This choice allows selection of the interoperability technology at the use case level, showing how different use cases can execute through different interoperability adapters. For example, the AuthenticateCustomer use case could execute in the .NET Business tier, whereas the GetCategories use case calls into the J2EE Business tier.