Chapter 8 takes a look at how third-party vendors, such as JNBridge, LLC, and Intrinsyc Software, are writing Java–Microsoft .NET interoperability solutions for heterogeneous environments. The vendors achieve this through various unique approaches. Recently, JNBridge released JNBridgePro to update its existing interop solution. It allows Java code to retain its cross-platform portability and conformance to standards written to accommodate the Java language. The following list itemizes the benefits of JNBridgePro version 1.3:
Support for both J2SE and J2EE.
Support for all major J2EE application servers, including BEA WebLogic, IBM WebSphere, iPlanet, Oracle9i, JBoss, and Borland Enterprise Server.
Support for transactions managed by thread-true classes ensuring data integrity.
Support for J# .NET.
The 100 percent pure Java code residing on a Java Virtual Machine is available on all Java-enabled technology platforms.
The option for passing objects by value or by reference enhances performance. JNBridge suggests various methods for increasing efficiency and performance, and they have made this information available at http://www.JNBridge.com/performance.htm .
Direct mapping between J2EE and .NET classes guarantees better efficiency among distributed applications.
Strong naming of proxy assemblies permits better security.
JNBridgePro distinguishes between service-level integration and class-level integration. Service-level integration is defined as Java components exposed to .NET as a collection of services. Service-level interoperability occurs when developers expose a component (set of individual classes) as a single service. This approach does not expose individual classes because the single component provides the basic functionality. In contrast, class-level integration means Java classes interact in cross- language development, just as .NET classes do. Exposing class interfaces facilitates class inheritance because individual classes are exposed rather than viewed as a single component containing more than one class. This allows developers to develop .NET code based on preexisting Java classes, thereby facilitating interoperability between the two platforms.
Although web services are becoming increasingly popular for moving large blocks of data via SOAP and HTTP, they carry considerable overhead because XML is text based. Additionally, web services do not support callbacks since callbacks allow Java code to call .NET code without having to modify Java code. Another disadvantage to using the traditional web services approach is that the web services do not support passing objects by reference.
Porting the complete .NET platform to Java and reimplementing the entire framework as a set of Java packages is less than satisfactory. Although this solution allows Java to call .NET APIs, it does not permit either Java or .NET classes to call each other. A solution to this problem requires that a cross-compiler translate all .NET source code or binary code. This translation allows all .NET classes and Java classes to interact seamlessly with each other.
The chief advantage to compiling Java code to .NET code solution is cross-platform interoperability, primarily because it makes .NET code interoperable:
Cross-compilation This solution results in no overhead for interplatform communication. Unfortunately, the API for Java must be reimplemented for .NET, an unsatisfactory solution.
Bridging JNBridgePro manages communications between Java and .NET. Proxy classes provide access to the actual classes they represent. JNBridge prefers this because they bypass the conversion factor completely. As JNBridge explains, .NET classes run on a CLR, while Java classes run on JVM. Proxies created in .NET emulate the interfaces of corresponding Java classes. Microsoft .NET classes can inherit from a Java class by inheriting from the class’s proxy, and vice versa.
Because Java runs on a JVM or J2EE platform, it does not require source code if the binary is available. JNBridgePro lends support for passing objects by value or by reference. Depending on context, if the Java runtime components are installed on a J2EE application server, the execution speed is faster than an RMI implementation. However, JNBridge explicitly states that if the runtime components are installed on the client side, there will be some overhead because SOAP and the HTTP protocol are required.
Visual Studio .NET includes Visual J# .NET, a development tool for Java language developers who want to develop applications on the .NET Framework. JNBridge has issued a comparison between JNBridgePro and J# .NET to demonstrate the versatility of JNBridgePro. Whereas J# .NET uses proprietary extensions to the Java language, JNBridgePro allows developers to create applications with standard Java. The JNBCore component of JNBridgePro allows applications to run on any JVM-supported platform, thereby permitting the Java segment of distributed applications to run in any environment. However, .NET classes interacting with Java code must run on the .NET platform.
Intrinsyc Software has much in common with JNBridge Software. They both recognize the need for providing interoperability between J2EE and .NET. Both offer the following features:
Support for enterprise application servers, including WebSphere, BEA WebLogic, Oracle9i, Borland Enterprise Server, and JBoss
Support for HTTP and TCP/IP protocols
Support for SOAP
Support for binary messages
Client-activated and server-activated objects
Invocation of methods on Java objects from the CLR
Invocation of methods on CLR objects from Java
Support for passing Java/CLR objects by reference and by value as parameters/return values
Marshalling objects by value or by reference
Intrinsyc’s Ja.NET bridges the gap between Java and .NET. It is possible to write clients for Enterprise JavaBeans in a .NET language targeting the .NET Framework. Using any language hosted by the framework in conjunction with Ja.NET facilitates interoperability between Java objects or Entity JavaBeans. Additional features permit reusing components written in Java within the .NET environment or vice versa. In essence, Ja.NET Java components act as though they were Microsoft .NET, and vice versa, because Ja.NET leverages .NET remoting.
Ja.NET provides a tool called GenJava to generate a Java proxy for .NET components. For example, access to an Internet Information Server (IIS) component from Java is easy. The Janetor tool configures the Ja.NET runtime. Then, Java clients can use the proxies to access a remote CLR component as though it were a local Java component. The tool can also generate a .NET component bearing proxies for Enterprise JavaBeans client-side classes. Then, Janetor generates a web application archive (WAR) file containing all web server–deployable files. Another nice feature permits the CLR client written in any language to access Enterprise JavaBeans as though they were local CLR components.
Intrinsyc has another interop tool called J-Integra. It is a COM-Java tool employed for accessing ActiveX components as though they are Java objects. Conversely, accessing Java objects as though they are Microsoft .NET components is allowed. J-Integra works seamlessly with any Java Virtual Machine on any platform and requires no native code. Additionally, J-Integra speaks native DCOM and is layered over Remote Procedure Calls. J-Integra requires no JVM or additional software installs on the COM platform.