Using Ja.NET for Interoperability

This section shows how you can use Ja.NET to perform bridging between a .NET Web tier application and a J2EE Business tier. Like the previous section on JNBridgePro, it covers the data format choices, how to build the service interface and how to build the interoperability adapters.

Deciding on a Data Format

Ja.NET also has the ability to provide .NET with proxy classes for the Java data classes, allowing you to use these generated data classes throughout your .NET application. For reasons mentioned earlier in this chapter it is more sensible to place the data into a dataset, which can then be used in the .NET Presentation tier. Hence you are likely to perform some data conversion when building the interoperability adapters in .NET.

Building the Service Interface for Ja.NET

Like with JNBridgePro, you could choose to expose an existing service fa ade to .NET. However, you should protect your code from changes by implementing a layered approach. You can do this by creating another Java class to be your service interface. Because you can return native Java data types to .NET using Ja.NET, this service interface simply calls the appropriate methods on the service fa ade and returns the resultant data types.

Applications that use Ja.NET for interoperability need Ja.NET runtime components on the J2EE side, and proxy definition libraries (DLLs) on the .NET side. 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.

Again the developers created the Ja.NET service interface as a Java class. This class passes the method calls across to the existing session bean service fa ade. This example also shows the AuthenticateCustomer use case:

  1. The developers created a new Web Project called JaNetBLL. They added this to the existing SingleTierXBikes EAR. Like before, they included XBikesCommon and XBikesBiz projects as module references.

  2. The developers created the contents of the Web project using the Janetor tool. This tool creates a WAR that contains the Ja.NET runtime and a configured Web.xml file. After installing the license, they had to configure the host name of the application server, and then export the WAR. They then imported this WAR into the newly created JaNetBLL project, overwriting files as needed.

  3. To allow the JaNet project to talk to the session bean, the developers created an EJB reference in the Web project to point to the BusinessServiceFacade session bean.

  4. Finally, they created a Java Class called BLLServiceInterface in the xbikes.bll.serviceinterface.j2ee.janet package. This class has the same methods as the BusinessServiceFacade and simply passes the method calls onto this session bean.


    This class is exactly the same as the one detailed in the JNBridge section.

While you can use Ja.NET 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 Ja.NET

After you construct the service interface that you want your .NET application to consume, you need to generate the proxy assembly for .NET. This assembly contains .NET proxies for the service interface, along with data classes that the service interface uses. For example, if the service interface returns data of the Java type CustomerData, the .NET assembly that Ja.NET generates would contain a proxy for this class.

You can use the Ja.NET GUI tools to generate these proxy classes. Select which classes for which you wish to generate proxies and Ja.NET creates them.

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

Creating the Java Proxy Classes

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

  1. The developers started GenNet and added the following folders and Project Utility Jars:

    • C:\xbikes\J2EE-IBM\JaNetBLL\Web ContentWEB-INF\classes

    • C:\xbikes\J2EE-IBM\XBikesCommon

    • C:\Program Files\IBM\WebSphere Studio\runtimes\base_v5\lib\j2ee.jar

    • C:\xbikes\J2EE-IBM\XBikesBiz\ejbModule

  2. Next they added the BLLServiceInterface class and all the classes in the package. They changed the data classes to pass by value to improve performance.

  3. The developers then saved the generated proxy assembly as JanetBLLEjb.dll with a strong name. The GenNet proxy generation tool also generates a remoting configuration file, named Remoting_http.config, containing the .NET Remoting settings that enable communication with the Java components.

Now that they had generated the proxies, the next task was to integrate this into the ASP.NET Presentation tier.


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 called XBikes-UseCaseInteropAdapters-JaNET. In this project the developers added a new class called AuthenticateCustomerInteropAdapter to the J2EE\JaNET folder.


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 the Ja.Net-generated Java proxies, the developers copied the JanetBLLEjb.dll to the .NET computer and installed it in the GAC. They then added it as a reference to the XBikes-UseCaseInteropAdapters-JaNET project.

The AuthenticateCustomerInteropAdapter handles the bridging between the .NET Web tier and the J2EE Business tier when authenticating a 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 Ja.NET-generated proxy for the J2EE-based BLLServiceInterface object, which is the object that performs the authentication of the customer. 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 the customers email address and password (both strings), and saves them so that they are 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 by value copy of a J2EE CustomerData object. This is in accordance with the Ja.NET Best Practices in Chapter 4, “Interoperability Technologies: Point to Point.”

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 row object to the native .NET CustomerData object.

 using System; using xbikes.bll.serviceinterface.j2ee.janet; using; using XBikes.Common.Interfaces.Architecture; using XBikes.Common.Schemas; using System.Data; using XBikes.Common.Exceptions; namespace XBikes.UseCaseInteropAdapters.J2EE.JaNET {     /// <summary>     /// Class that implements the IUseCaseCommand interface.     /// This class performs the task of     /// AuthenticateCustomerInteropAdapter.     /// It calls into the J2EE Server to get at its BLL Service     /// Interface     /// and calls the authenticateCustomer method on the     /// BLLServiceInterface contained     /// in the JaNetBLL servlet.     /// In actual fact, you could use Ja.NET and the JNDIContext     /// object     /// to directly call the BLL Bean in the app server.     /// For this Case Study, there is an extra layer that has been     /// added, namely     /// that of     /// xbikes.bll.serviceinterface.j2ee.janet.BLLServiceInterface     /// that lives in the JaNetBll servlet.     /// </summary>     public class AuthenticateCustomerInteropAdapter : IUseCaseCommand     {         private string m_szPassword = "";         private string m_szEmail = "";         // the proxy for the BLL service interface object         private BLLServiceInterface  _facade = null;         /// <summary>         /// The constructor for the authenticate customer use case adapter.         /// </summary>         public AuthenticateCustomerInteropAdapter()         {             try             {                 // instantiate the BLL service interface .                  _facade = new BLLServiceInterface();             }             catch (Exception e)             {                 throw new 
J2EE JaNET Interop Adapter error: ", e); } } /// <summary> /// Sets the parameters for this UseCaseAdapters /// </summary> /// <param name="parameters"></param> public void Initialise(object[] parameters) { m_szPassword = (string) parameters[0]; m_szEmail = (string) parameters[1]; } /// <summary> /// The Actual Execute Method /// </summary> /// <returns>DataSet object</returns> public DataSet Execute() { try { // Create the return DataSet Object XBikes.Common.Schemas.CustomerData custData =
new XBikes.Common.Schemas.CustomerData(); // Get the EJB Data ejbCustData =
_facade.authenticateCustomer(m_szPassword, m_szEmail); // We need a row XBikes.Common.Schemas.CustomerData.CustomersRow cr =
custData.Customers.NewCustomersRow(); // Fill in the values cr.CustomerID = ejbCustData.getCustomerID(); cr.EmailAddress = ejbCustData.getAddress(); cr.FullName = ejbCustData.getName(); cr.Password = ejbCustData.getPassword(); cr.ZipCode = ejbCustData.getZip(); custData.Customers.AddCustomersRow(cr); return custData; } catch (XBikesApplicationException ae) { throw ae; } catch (XBikesInteropException ae) { throw ae; } catch (System.Runtime.Remoting.RemotingException sre) { // Is it a problem with the network? string message = sre.Message; if (message.IndexOf("com.intrinsyc.janet") >= 0) { throw new XBikesInteropException(sre.Message, sre); } else { // or is it an application error? throw new XBikesApplicationException(sre.Message, sre); } } catch (Exception eX) { // generic catch/rethrow throw new XBikesApplicationException(eX.Message, eX); } } } }

The final part of the implementing JaNET interoperability adapter is to set up the configuration files. In ASP.NET Web applications, all .NET Remoting configuration settings must be read during the event handler for the Application_OnStart event of the web application. JaNET uses .NET Remoting to communicate with the Java components, and the interoperability adapters run as part of the .NET Presentation tier’s ASP.NET application. Hence the JaNET configuration settings must also be read in during the event handler for the Application_OnStart event of the ASP.NET application. The event handler for the Application_OnStart event lives in the Global.asax.cs file of the Web application. This introduces two minor complications to the application architecture:

  • If your ASP.NET application communicates with any other components using .NET Remoting, the remoting configuration settings for those components must live in the same file and load at the same time as the Application_OnStart event.

  • By loading JaNET configuration settings from the Global.asax.cs file of the ASP.NET application the interoperability adapter no longer provides complete abstraction.

To accommodate the remoting configuration requirements of the ASP.NET application, the XBikes developers then updated the remoting configuration file, Remoting.config, in XBikes-Web with the content from the client section of the Remoting_http.config file that the proxy tool generated.


You can only configure one instance of a type of channel in a .NET Remoting configuration file. Hence you can only have one HTTP channel configured at a time, which can cause issues if you have existing components in your ASP.NET application that use .NET Remoting to communicate. If you already have a channel configured in the Remoting.config file, check that you do not copy the definition of the same type of channel twice when you copy the Ja.NET configuration settings from Remoting_http.config (the generated configuration file) into the Remoting.config file.

If the .NET and J2EE components are on different computers, then you need to ensure the URL specified in the <client> tag of the JaNET configuration settings within the Remoting.config file contains the name of the computer hosting the J2EE components.

Application Interoperability. Microsoft. NET and J2EE
Application Interoperability: Microsoft .NET and J2EE: Microsoft(r) .Net and J2ee (Patterns & Practices)
ISBN: 073561847X
EAN: 2147483647
Year: 2003
Pages: 104 © 2008-2017.
If you may any questions please contact us: