You should now understand the architecture of the XBikes application and the interoperability techniques that XBikes uses. In this chapter, you look in detail at the code that allowed the XBikes developers to implement interoperability by integrating an ASP.NET Presentation tier application with a J2EE Business tier.
When deciding to add an ASP.NET Presentation tier to a J2EE application, there are three areas you need to address, regardless of the technology you decide to use:
Which data format to use for interoperability.
How to design and build the service interfaces in the J2EE application.
How to design and build the interoperability adapters in the .NET Framework application.
There are several factors to consider when deciding on which interoperability technology is best for your project. Performance, standards compliance and cost are just some of the factors that affect your choice and each choice has advantages and disadvantages.
Web services offers an industry standard solution, supported by many vendors on a variety of platforms including .NET and Java. However, while being fairly easy to implement, Web services do not offer the performance of some third party binary interoperability technologies.
JNBridgePro from JNBridge and Ja.NET from Intrinsyc both offer high performance, high control binary solutions, although they do not completely conform to open industry standards.
Choose Web services as the interoperability technology unless performance is an overriding requirement. This is because Web services follow open standards and are the best way to ensure interoperability with future applications and industry developments.
For a detailed discussion about choosing an interoperability technology, see Chapters 3 to 5.
In Chapter 3, “Interoperability Fundamentals,” you saw how Java and .NET complex data types are unlikely to correlate between the two platforms. You also saw how it is possible to create a common format for exchanging data between the platforms through the use of custom serializable classes generated from a common XML Schema.
In Chapter 4, “Interoperability Technologies: Point to Point,” you saw how Ja.Net and JNBridgePro can create proxies for Java data classes that a .NET Framework application can then use. While these are two valid solutions for getting data from Java to .NET, using custom data classes or proxy Java classes may not be desirable within the .NET Presentation tier. It is likely that you will want to use native .NET data types, such as a typed DataSet, to take advantage of the rich features provided by ASP.NET such as data binding.
To get around this issue, you either need to package the data up on the Java side into the format you want for .NET, or send the Java data and repackage it on the .NET side. To do this, your service interfaces and interoperability adapters may need to manipulate the data. In the XBikes application, the mapping techniques differ, depending on the interoperability technology.
For a detailed discussion about data exchange factors, see Chapter 3.
The XBikes sample application follows the J2EE best practices described in Chapter 6, “Implementing Interoperability Design Elements,” so access to the Business tier is through the session bean BusinessServiceFacade. To expose this functionality to the .NET Framework application, the developers created a service interface that exposes BusinessServiceFacade. Depending upon the interoperability technology in use, this service interface class either calls the existing service fa ade directly or manipulates the data before calling the service fa ade. Again, on the return path the service interface either returns the data to the service interface caller directly or manipulates it before returning it. Figure 7.1 shows this arrangement.
Figure 7.1: Implementing a service interface and service fa ade to link the J2EE Business tier to the .NET Presentation tier
For a detailed discussion of service interfaces, see Chapter 6.
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.
Implementing interoperability adapters at the use case level was mainly for demonstration purposes. Your application may not require that level of granularity.
Figure 7.2 shows the interoperability adapters linking the ASP.NET application to the service interface.
Figure 7.2: Interoperability adapters connecting the ASP.NET application to the service interface
For more information about implementing interoperability adapters, see Chapter 6.