J-Integra for Java EE .NET Integration


Scope

While Web services provide a very powerful technology for enterprise application integration, they are not suitable for all applications and interoperability scenarios. Both the .NET Framework and Java offer implementations of Web services, with varying degrees of integration into the underlying platform. Because SOAP is text-based, Web service calls might be too slow for applications that require frequent, fast, and fine-grained communications.

Service-oriented interfaces such as Web services are also unsuited for conventional object-oriented models. Although a service can be thought of as a single, persistent server-activated object, client-activated objects such as ones that the new operator constructs and access requests to static methods are not generally supported.

Similarly, if an application needs to access a wide variety of objects and classes or link to a rich object-oriented set of Java APIs from the .NET Framework, Web services are probably not the solution. In addition to the preceding issues, Web services do not support callbacks in the same manner as local object-oriented architectures.

In such cases, an alternative solution is required that enables interoperability between .NET Framework applications and Java applications with .NET Remoting as the underlying connecting protocol. Developers familiar with Java EE technology may wish to view .NET Remoting as a .NET parallel to Remote Method Invocation (RMI) and Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP).

The problem is that .NET Remoting can normally only be used in a homogeneous (.NET) environment. To achieve interoperability using .NET Remoting, you can use J-Integra for .NET (also known as Ja.NET) that allows .NET applications to access existing Java/Java EE applications as though they were actually .NET. Ja.NET is part of Intrinsyc Software's J-Integra Interoperability Suite. It is a runtime bridging product that exposes Java objects and methods in a way that enables the user to address them with .NET Remoting and vice versa. Ja.NET differs from a number of other Java/.NET Remoting bridging products in that it is bi-directional. Thus, as well as enabling Java server side objects to be accessed from .NET clients, it can also be used to access .NET servers from Java.

Solution

Ja.NET provides a two-way implementation of the .NET Remoting stack for Java. It comprises a Java runtime component and a development toolset used to generate proxies and to configure the runtime.

Using Ja.NET, a set of C# proxies can be generated to access Java from .NET. Similarly because Ja.NET is a bi-directional bridge, Java proxies that expose or consume .NET Common Language Runtime (CLR) components using the .NET Remoting protocol can be generated.

The main components of Ja.NET are

  • Ja.NET Runtime The Ja.NET runtime core is the main collection of Java classes that provides an implementation of the .NET Remoting stack for Java. It is the only Ja.NET component that is required at runtime. The runtime components are contained in the janet.jar file, and it uses a configuration file (by default janet.xml) that is generated during development by the Janetor tool. The Ja.NET runtime component also includes a Ja.NET TCP server that provides standalone hosting for Java classes through the Ja.NET runtime where the classes are not hosted on a Java EE/Web server and are accessed via a TCP channel.

  • Janetor The Janetor tool allows viewing and modification of the Ja.NET runtime configuration settings. Janetor can also be used to generate Web Application Archive (WAR) files to assist with deploying the Ja.NET runtime onto a Web server.

  • GenNet GenNet generates the .NET Framework proxies that access the Java classes through the Ja.NET runtime.

  • GenJava GenJava generates Java proxies that access .NET Framework assemblies through the Ja.NET runtime.

  • GenService The GenJava and GenNet tools use GenService to provide access to .NET Framework assemblies for proxy generation during development. GenService is only required for proxy generation and does not have to be installed in the production environment.

Accessing an EJB from .NET Framework

Accessing an EJB from a .NET client is achieved as follows:

  • The GenNet tool is used to generate a .NET component containing proxies for the EJB classes. The generated .NET proxies use no custom code, just pure .NET Remoting. Refer to Figure 5-7.

  • The Janetor tool is used to generate a WAR file containing all the files to be deployed in the Web server. Refer to Figure 5-8.

  • The WAR file can then be deployed in any Web server that supports servlets. The CLR client (written in any supported .NET Framework language) can access the EJBs as if accessing local CLR components. Refer to Figure 5-9.

Figure 5-7. Generation of .NET proxies for EJB


Figure 5-8. Generation of Web Application Archive


Figure 5-9. Deployment for accessing Java EJB from .NET CLR client


Accessing a .NET Component from Java

Ja.NET can also be used to enable Java clients to access .NET CLR components as follows:

  • The GenJava tool is used to generate the Java proxies for the .NET component. Refer to Figure 5-10.

    Figure 5-10. Generation of Java proxies for .NET CLR component

  • The Janetor tool is used to configure the Ja.NET runtime. Details such as the URL of the CLR component can be specified here. Refer to Figure 5-11.

    Figure 5-11. Configuration of Ja.NET runtime

  • Java clients can use the generated proxies and access the remote CLR component as if it were a local Java component. The .NET CLR component can be hosted in an Internet Information Server (IIS) and accessed via .NET Remoting over HTTP (as shown in Figure 5-12). Alternatively, standalone .NET servers (such as a server implemented in Visual Basic .NET) can be accessed using TCP and a binary message format.

    Figure 5-12. Deployment for accessing .NET CLR component hosted in IIS from Java

Channels and Formatters (Messaging and Object Serialization)

The .NET Remoting Framework supports the use of interchangeable formatters and channels. Channels are used to transport messages to and from remote objects. Formatters are used to serialize the data to be transmitted in a particular format. Currently SOAP and binary formats are supported over either HTTP or TCP channels. Using these channels and formats, Ja.NET is wire-line compatible with the .NET Remoting Framework, which is why there is no need to deploy any Ja.NET runtime components on the .NET side.

The HTTP channel is used when, as in the EJB case, the server-side component is accessed via a Java EE/Web server. Developers can choose to either use the internal Web server that is shipped with Ja.NET to host their Java server components or use a WAR file to deploy them in any other Java EE application server/Web server that supports servlets. Alternatively, for standalone hosting of Java classes, the TCP server that is part of the Ja.NET runtime can be used to access them via a TCP channel.

The stream of messages flows when a .NET client invokes a method on a Java server-side object, as illustrated in Figure 5-13. The .NET client invocation goes through the proxy object (generated by the GenNet tool) to the .NET Remoting Framework, where it is serialized using the configured formatter (binary or SOAP) and sent to the configured URL using the specified channel (HTTP or TCP).

Figure 5-13. Message flow for invocation of Java component method from .NET CLR client


On the Java side, the incoming message is received by the Ja.NET runtime (either via the Web server and Ja.NET servlet in the case of HTTP or via the Ja.NET TCP server). The message is deserialized using the appropriate Formatter (binary or SOAP) and dispatched by the marshaler to the appropriate Object Ref instance, which invokes the method on the actual Java object. The response message flows back in the opposite direction for serialization and transmission to the .NET Framework. Refer to Figure 5-13.

Object Lifetime Management

Knowing when to destroy an object that is referenced remotely is always a problem for distributed technologies. COM used reference counting to solve the distributed garbage collection problem. .NET Remoting uses leasing. With leasing, a remote object remains available for a configurable period of time before being destroyed. Leases may also be configured to be extended when the object is accessed, and additionally sponsors may be configured to be responsible for renewing leases before they expire.

Because Ja.NET adheres to the .NET Remoting standard, the Ja.NET runtime contains a Lease Manager for administering leases so that Java objects instantiated by .NET clients follow the same leasing mechanism.

Scalability

When using HTTP, Ja.NET is entirely compatible with the use of Web servers/Java EE application servers to achieve deployment scalability. For TCP-based deployments, Ja.NET gives developers and administrators the ability to manage resource usage through configuration of TCP server parameters, such as the thread pool size and the maximum request queue size. Ja.NET also provides a connection pooling mechanism to improve performance and optimize resource usage.

Security

Ja.NET leverages standard mechanisms for securing channels and authenticating clients. HTTPS may be used when accessing components via a Web server. Also the desired authentication method can be selected to specify how the client authenticates itself to a Web server when trying to access remote objects. HTTP Basic or Digest authentication methods may be usedor "Best," which causes the most secure method supported by the server to be automatically selected.

Ja.NET supports the SecureRemoting protocol and various standard encryption algorithms (3DES, DES, RC2, and Rijndael). TCP channels can be secured by configuring the Ja.NET runtime to use the desired encryption protocol and algorithm and deploying a .NET SecureRemoting channel provider to encrypt/decrypt the data on the .NET side.

Benefits

Web services is a technology that is specifically designed for businesses to provide services and exchange information over the Internet. While .NET Remoting is not an industry-wide standard, it does have the following advantages over Web services, which are especially relevant in an intranet environment:

  • Multiple protocol support including high-speed binary over TCP faster than SOAP over HTTP

  • Support for activation and lifetime control of remote objects by the client

  • Support for passing objects by reference and by value

  • Support for callbacks

  • Guaranteed interoperability

  • Support for events

  • Support for type system fidelity, which means that there is a one-to-one mapping between the class and type hierarchy. Web services and SOAP do not support such an object-oriented mechanism for accessing remote objects.

Because Ja.NET uses .NET Remoting, it also has these advantages over Web services.

Ja.NET is wire-line compatible with .NET Remoting and does not require any custom runtime components to be deployed on the .NET side. It supports standard Web server/.NET Remoting security mechanisms.

Interoperability between .NET and Java/Java EE is achieved without the need for developers to write any custom code on either the client or server sides. Ja.NET provides tools for auto-generation of the proxy classes that are used in deployment, and developers can access existing Java components from .NET as if they were accessing them as CLR components using the standard .NET Remoting protocol. Similarly, Ja.NET allows Java clients to access existing CLR server components as if they were local Java objects.

Limitations

Currently a single type of .NET Remoting exception is returned to the client, regardless of the specific type of the underlying exception that occurred. Future releases of Ja.NET will include support for returning specific system and custom exception types.

Examples

As an example, a financial services provider has used Ja.NET to integrate the components of an online trading system. Refer to Figure 5-14. The presentation layer runs on Windows Desktop devices and includes MS .NET GUI components that interact with other MS Office applications. These use Ja.NET to interoperate via .NET Remoting with business logic components that are hosted by Java EE application servers running on commercial Unix or Linux platforms. The application components in turn use JDBC/JMS to interact with database servers that provide persistent services.

Figure 5-14. Online trading system (simplified architecture)


This deployment configuration is like the one shown previously for accessing EJB components from a .NET client.

The following sample code illustrates in more detail how a .NET client can access a Java server via .NET Remoting using Ja.NET. This example is based on a simplified scenario from the WS-I Supply Chain Management architecture, in which a client queries the server for a catalog of available products. The Java server comprises a Catalog class, which implements an ICatalog interface. This interface has a getProducts method, which returns an array of Product objects.

The Catalog class provides an example of a PassByReference object. Refer to Listing 5-5.

Listing 5-5. Sample "Pass by Object" Object

//----------------------------------------------------------------- // ICatalog.java package java_server; public interface ICatalog {   Product[] getProducts(); } //--------------------------------------------------------------------- // Catalog.java. Example PassByReference class. package java_server; public class Catalog implements ICatalog {   public Catalog() {   }   public Product[] getProducts() {     // in a real implementation, this might involve a database query     Product[] products = new Product[10];     products[0] = new Product("TV", "Brand 1", 329.99);     products[1] = new Product("TV", "Brand 2", 359.99);     products[2] = new Product("TV", "Brand 3", 289.99);     products[3] = new Product("TV", "Brand 4", 265.99);     products[4] = new Product("DVD", "Brand 1", 128.99);     products[5] = new Product("DVD", "Brand 2", 156.99);     products[6] = new Product("DVD", "Brand 3", 145.99);     products[7] = new Product("video camera", "Brand 1", 425.99);     products[8] = new Product("video camera", "Brand 2", 476.99);     products[9] = new Product("video camera", "Brand 3", 520.99);     return products;   } } 

The Product class provides an example of a PassByValue object. This class implements the Serializable interface. Refer to Listing 5-6.

Listing 5-6. Sample PassbyValue Object

//----------------------------------------------------------------- // Product.java. Example PassByValue class. package java_server; import java.io.Serializable; public class Product implements Serializable {   public Product(String type, String manufacturer, double price) {     this.type = type; this.manufacturer = manufacturer; this.price = price;   }   public String type;   public String manufacturer;   public double price; } 

.NET proxies for these classes are generated using the Ja.NET GenNet tool. Upon examining the generated proxies, one should notice how the byvalue class contains all its fields, and the remote byreference class is only a shell that defines the class definitions. .NET needs these for compile definitions and then again at runtime for the .NET Remoting transparentProxy class to mimic the remote server. If one attempts to create a local copy of this class, this generates an exceptiononly remote instances of this class are generated. The proxies use no custom code, just pure .NET Remoting managed code. Refer to Listing 5-7.

Listing 5-7. Sample .NET Proxy

//----------------------------------------------------------------- /// <summary> /// This file is a .NET proxy file auto-generated by JaNET, the Java/.NET /// integration product from Intrinsyc Software Inc. /// </summary> namespace java_server {   using System;   public class Catalog : System.MarshalByRefObject, java_server.ICatalog {     private String ProxyCalledExceptionMsg = "Configuration error:\nThis exception is thrown by a Ja.NET-generated proxy file. \n" + "This method should not be invoked; it is only used at compile time.\nCheck the " + "remoting.config file or remoting configuration.";     public Catalog() {       throw new System.Exception(ProxyCalledExceptionMsg);     }     public java_server.Product[] getProducts() {       throw new System.Exception(ProxyCalledExceptionMsg);     }   } } //--------------------------------------------------------------------- /// <summary> /// This file is a proxy file auto-generated by JaNET, the Java/.NET /// integration product from Intrinsyc Software Inc. /// </summary> namespace java_server {   using System;   [Serializable()]   public class Product {     public string type;     public string manufacturer;     public System.Double price;     public string getType() {       return type;     }     public void setType(string param) {       type = param;     }     public string getManufacturer() {       return manufacturer;     }     public void setManufacturer(string param) {       manufacturer = param;     }     public System.Double getPrice() {       return price;     }     public void setPrice(System.Double param) {       price = param;     }   } } 

The .NET CLR client application configures .NET Remoting in the standard way using the configuration file remoting.config. This file specifies the URL of the java_server.Catalog object and the channel and formatter types to be used. For example, if the Ja.NET TCP server is used to host the java_server on the same machine using port 7562, the configuration file would contain the following application entry:

<client>    <wellknown url="tcp://localhost:7562"    type="java_server.Catalog, JanetExample"/> </client> 


The client can then just instantiate and invoke methods on the Java server objects as if they were local CLR components. Refer to Listing 5-8.

Listing 5-8. Sample .NET Client to Access Product Catalog Java Server

// Example .NET client to access Product Catalog Java server using System; using System.Runtime.Remoting; using java_server; namespace csharp_client {   class Client   {     static void Main(string[] args)     {       // configure .NET Remoting       RemotingConfiguration.Configure("remoting.config");       // access the Product Catalog       Catalog catalog = new Catalog();       // call a method of the Catalog to get By-Value Product objects       Product[] p = catalog.getProducts();       Console.WriteLine("Products:");       for (int i = 0; i < p.Length; i++)       Console.WriteLine(p[i].manufacturer + " "         + p[i].type +  " $" + p[i].price);      Console.WriteLine("Press any key to continue...");      Console.ReadLine();     }   } } 

Resources

  • More information on Intrinsyc's J-Integra Interoperability Suite, including a free trial version download, is available at http://j-integra.intrinsyc.com/.

  • Ja.NET is also featured in Chapter 4 Part II of Microsoft .NET and Java EE Interoperability Toolkit by Simon Guest. Microsoft Press. ISBN 0-7356-1922-0.

  • Some introductory technical articles on .NET Remoting are: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/hawkremoting.asp and www.developer.com/net/cplus/article.php/1479761.




Java EE and. Net Interoperability(c) Integration Strategies, Patterns, and Best Practices
Java EE and .NET Interoperability: Integration Strategies, Patterns, and Best Practices
ISBN: 0131472232
EAN: 2147483647
Year: N/A
Pages: 170

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net