Using JNBridgePro for Interoperability

This section shows how you can use JNBridgePro to perform bridging between a .NET Web tier and a J2EE Business tier. You look at the data format choices, how to build the service interface, and how to build the interoperability adapters.

Deciding on a Data Format

JNBridgePro has the ability to generate proxy classes in .NET for the Java data classes. You can then use these generated data classes throughout your .NET application. However, for reasons mentioned earlier in the chapter, it may make more sense to put this data into a dataset, which you can then easily use in the .NET Presentation tier.

Note

You are highly likely to carry out some form of data conversion when building the interoperability adapters in .NET.

Building the Service Interface for JNBridgePro

JNBridgePro can expose existing Java classes to .NET, so you could choose to expose an existing service fa ade to .NET. However, you should protect your code from changes by using a layered approach. To do this, create another Java class which is your service interface. Because you can return native Java data types to .NET with JNBridgePro, this service interface simply calls the appropriate methods on the service fa ade and returns any resultant data types.

Applications that use JNBridgePro for interoperability need JNBridge runtime components on both the .NET and J2EE sides. The Java-side runtime component acts as a .NET Framework remoting server, marshalling and unmarshaling parameters, returning values, dispatching methods, and managing the lifecycles of Java objects that .NET references.

Following the pattern of creating a service interface class, the developers built a Java class that implemented exactly the same methods as the existing BusinessServiceFacade session bean. This section shows the overall process of how the developers created the AuthenticateCustomer use case:

1. The developers created a new Web Project called JNBridgeBLL and added it to the existing SingleTierXBikes EAR. They then included the XBikesCommon and XBikesBiz projects as module references.

2. They then installed the JNBridgePro Java-side runtime component, JNBCORE.JAR to the WEB-INF\lib folder and added the jnbcore_tcp.properties file to the WEB-INF folder, copying these files from the JNBridge install folder.

3. Next they added the JNBServlet to the Web Deployment Descriptor and specified Load on startup and set the Load Order to –1, which loads the class when the application server starts.

4. The developers created the BLLServiceInterface class in the xbikes.bll.serviceinterface.j2ee.jnbridge package. This class simply passes any method call across to the existing service fa ade. The next code example shows the BLLServiceInteface class.

    Source Code Listing package xbikes.bll.serviceinterface.j2ee.jnbridge; import javax.naming.*; import javax.rmi.*; import java.rmi.*; import xbikes.bll.facade.*; import xbikes.common.data.*; public class BLLServiceInterface {     BusinessServiceFacade facade=null;     private final String BUSINESS_FACADE_JNDI =         "BusinessServiceFacade";     private final String BUSINESS_FACADE_CLASS =         "xbikes.bll.facade.BusinessServiceFacadeHome";     /**      * Constructor for BLLServiceInterface.      */     public BLLServiceInterface() {         try         {             InitialContext ic = new InitialContext();             Java.lang.Object objRef = ic.lookup(BUSINESS_FACADE_JNDI);             BusinessServiceFacadeHome home =                 (BusinessServiceFacadeHome) PortableRemoteObject.narrow(objRef,                 Java.lang.Class.forName(BUSINESS_FACADE_CLASS));             facade = home.create();         }         catch (Exception excp)         {             System.out.println(excp.getMessage());         }     }     public CustomerData authenticateCustomer(String email, String password)     throws Exception     {         return facade.authenticateCustomer(email, password);     }     public CategoriesListData getCategories()     throws Exception     {         return facade.getCategories();     }     public OrderListData getCustomerOrders(int customerID)     throws Exception     {         return facade.getCustomerOrders(customerID);     }     public ProductsListData getProductsByCategory(int categoryID)     throws Exception     {         return facade.getProductsByCategory(categoryID);     }     public ProductsListData getSearchResults(String keyword)     throws Exception     {         return facade.getSearchResults(keyword);     }     public void placeOrder(OrderData theOrder)     throws Exception     {         facade.placeOrder(theOrder);     } } 

The BLLServiceInterface is mostly a pass-through to the existing BusinessServiceFacade EJB. The additional functionality that the wrapper class provides is the constructor, which encapsulates the code necessary to find and access the EJB.

While you can use JNBridgePro to generate proxies that access the BusinessServiceFacade and the supporting JNDI classes directly, it is more efficient if you perform these operations entirely on the Java side and encapsulate the operations within a wrapper. In other situations, where you cannot change the J2EE code, you might have to access JNDI and EJB classes directly. The section on Using the MSMQ-MQSeries Bridge in Chapter 9, “Implementing Asynchronous Interoperability,” shows how to create an adapter that accesses the MQSeries APIs and demonstrates how you could create such an adapter if it were impossible to change the J2EE code.

Building the Interoperability Adapters using JNBridgePro

After you construct the service interface that you want the .NET application to consume, you need to generate a proxy assembly for .NET. This assembly contains .NET proxies for the service interface, as well as any data classes that the service interface uses. Therefore if the service interface returns Java data of the type CustomerData, the .NET assembly that JNBridgePro generates would contain a proxy for this class.

Note

In your code, consider prefixing the name of the proxy class with the name of the platform from where the proxy class originated, for example, if the .NET class was CustomerData, the Java proxy class would be javaCustomerData.

You can use the GUI tools that JNBridgePro provides to generate these proxy classes. You simply select the classes for which you wish to generate proxies and JNBridgePro creates them.

You can then add this assembly to your .NET project as a reference, along with the required JNBridgePro configuration files, and applications can consume it like any other .NET class, such as the interoperability adapter. Again, you should decide upon the level of fine control that you need with the interoperability adapters, either implementing one for each use case, or one for the whole service interface.

Note

The XBikes developers implemented an interoperability adapter for each use case.

Creating the Java Proxy Classes

The first stage for creating the interoperability adapters in XBikes was to generate the proxies for the Java service interface. The GUI-based proxy generation tool that is part of JNBridgePro was used to do this.

The first time this tool is executed, you have to setup the Java environment. This is done by specifying where the Java.exe program file is located. After that was done, the developers moved on to generating the adapters:

1. The developers loaded and configured the JNBProxy tool with the correct Java configuration, then added all the project folders and the Project Utility Jars that the service interface required to the class path created earlier. This included the following J2EE project folders and the Project Utility Jars:

   • C:\xbikes\J2EE-IBM\XBikesBiz\ejbModule, the root directory for the business fa ade classes.

   • C:\xbikes\J2EE-IBM\XBikesCommon, the root directory for the common data transfer objects.

   • C:\xbikes\J2EE-IBM\JNBridgeBLL\Web Content\WEB-INF\classes, the root directory for the fa ade wrapper classes.

   • C:\Program Files\IBM\WebSphere Studio\runtimes\base_v5\lib\j2ee.jar, the library containing various J2EE and EJB-related classes and exceptions.

   • C:\Program Files\IBM\WebSphere Studio\runtimes\base_v5\mqjms\Java\lib\jndi.jar, the library containing various JNDI-related classes and exceptions.

     Note

     The folder and file paths may differ depending on your installation.

2. The development team had to select which classes they wanted to access from .NET, eventually adding the following classes, plus all the supporting classes:

   • xbikes.bll.serviceinterface.j2ee.jnbridge.BLLServiceInterface

   • xbikes.common.data.CategoriesData

   • xbikes.common.data.CategoriesListData

   • xbikes.common.data.CustomerData

   • xbikes.common.data.OrderData

   • xbikes.common.data.OrderDetailsData

   • xbikes.common.data.OrderListData

   • xbikes.common.data.ProductsData

   • xbikes.common.data.ProductsListData

3. JNBProxy then loaded the required Java classes. This only exposed the classes listed above, and the developers added these to the exposed proxies pane.

4. The goal was to create an assembly that would load into the GAC, so the developers configured JNBProxy to build a strong name, supplying the version number of 1.0.0.0, and a strong name key file.

5. Finally, the developers instructed JNBProxy to build the assembly with the name Jnbridgebllproxies.dll.

JNBridgePro also ships with a configuration file that contains the settings for how the .NET Framework client can communicate with the Java application, such as the URL or location of the Java application. This file is named jnbproxy_tcp.config. Now that they had generated the proxies, the next task was to integrate this into the ASP.NET Presentation tier.

Note

This example focuses on the AuthenticateCustomer use case; however the rest follow the same pattern.

Implementing the Interoperability Adapters

The developers opened the .NET XBikes solution and added a new project named XBikes-UseCaseInteropAdapters-JNBridge. In this project the developers added a new class called AuthenticateCustomerInteropAdapter to the J2EE\JNBridge folder.

Note

The JNBridge and JaNET use case interoperability adapters reside in separate Visual Studio projects from the other XBikes .NET use case interoperability adapters. This avoids conflicts when using JaNET and JNBridge elements within the same project. In a production environment, it is unlikely that you would need both JaNET and JNBridge.

Because the interoperability adapter uses JNBridge, the developers copied both the created proxy assembly, Jnbridgebllproxies.dll and the JNBridge .NET support assembly Jnbshare.dll to the .NET computer and added them as project references. They also copied the configuration file Jnbproxy_tcp.config to the WWWroot folder on this computer and renamed it Jnbproxy.config.

The AuthenticateCustomerInteropAdapter handles the bridging between the .NET Web tier and the J2EE Business tier when authenticating the customer’s identity. It implements the IUseCaseCommand interface, which means it implements two methods:

• Initialise() — Sets up the use case adapter and assigns parameters for the upcoming action.

• Execute() — Causes the use case adapter to perform its action.

The interoperability adapter creates a JNBridge-generated proxy for the J2EE-based BLLServiceInterface object, which is the object that performs the lookup of products by category. The interoperability adapter’s constructor creates the proxy, and as part of that action creates the underlying J2EE BLLServiceInterface object.

The call to Initialise() simply takes a category identifier (an integer), and saves it so that it is available when the command executes. The call to Execute() calls the authenticateCustomer() method in the BLLServiceInterface proxy object, which causes the equivalent method to execute in J2EE, and returns a reference to a J2EE CustomerData object.

On the .NET side, this CustomerData object is a proxy of the J2EE CustomerData object. The remainder of Execute() converts the J2EE CustomerData object into an equivalent native .NET CustomerData object. It does this by iterating through the individual product data in the J2EE CustomerData object, extracting the details of that product, and assigning a new native .NET CustomerRow object to the native .NET CustomerData object.

Note

The namespaces ndata and jdata represent the longer .NET and J2EE namespaces in order to improve readability and to allow you to recognize and distinguish between .NET-based and J2EE based objects easily.

 using System; using System.Data; using XBikes.Common.Exceptions; using XBikes.Common.Interfaces.Architecture; // namespace of the J2EE BLL Service interface using xbikes.bll.serviceinterface.j2ee.jnbridge; // namespace for J2EE version of common data objects using jdata = xbikes.common.data; // namespace for .NET version of common data objects using ndata = XBikes.Common.Schemas; namespace XBikes.UseCaseInteropAdapters.J2EE.JNBridge {     /// <summary>     /// Use case adapter to authenticate customer information.     /// </summary>     public class AuthenticateCustomerInteropAdapter : IUseCaseCommand     {          private BLLServiceInterface facade = null;          /// <summary>          /// Summary description for AuthenticateCustomerCommand.          /// </summary>          public AuthenticateCustomerInteropAdapter()          {             try             {                 facade = new BLLServiceInterface();             }             catch (Exception e)             {                 throw new XbikesInteropException                     ("[AuthenticateCustomer]: JNBridge Interop                      Adapter error: ", e);             }         }         private string _email;         private string _password;         public void Initialise(object[] parameters)         {             _email = (string) parameters[0];             _password = (string) parameters[1];         }         public DataSet Execute()         {             try             {                 // perform the customer authentication                 // on the J2EE side                 // and retrieve the customer data                 jdata.CustomerData cust =                     facade.authenticateCustomer(_email,_password);                 // copy the Java data into a .NET data object                 // create the .NET data object                 ndata.CustomerData ds =                     new ndata.CustomerData();                 // create a new row in the .NET data object                 ndata.CustomerData.CustomersRow cr =                     ds.Customers.NewCustomersRow();                 // copy the individual fields from the                 // J2EE data object to the .NET data object                 cr.CustomerID = cust.getCustomerID();                 cr.EmailAddress=cust.getAddress();                 cr.FullName=cust.getName();                 cr.Password=cust.getPassword();                 cr.ZipCode = cust.getZip();                 // add the data row to the data set                 ds.Customers.AddCustomersRow(cr);                 return ds; }             catch (XBikesInteropException intExp)             {                 //This will already have been logged on its own tier.                 //re-throw up the stack for logging at the client.                 throw (intExp);             }             catch (XBikesApplicationException appExp)             {                 //This will already have been logged on its own tier.                 //re-throw up the stack for logging at the client.                 throw (appExp);             }             catch ( Exception e )             {                 throw new XbikesInteropException                     ("[AuthenticateCustomer]: JNBridge Interop                      Adapter error: ", e);             }         }     } } 

The final part of the configuration the developers carried out is on the .NET side of the XBikes application, where they needed to configure the file that tells the two computers how to communicate. This file is Jnbproxy.config and lives in the WWWroot folder. The developers changed the name LOCALHOST to point to the J2EE computer. They also installed Jnbshare.dll and Jnbridgebllproxies.dll in the global assembly cache.