Technology has revolutionized the way business functions. On numerous occasions, technology has been the driving force behind business. Keeping pace with the technology advancement has been the hardship with many disparate technologies cruising ahead in meeting the ever growing business needs. Software giants are always on the move finding ways and means to simplify/automate the complete paradigm in which a business operates.

‘Interoperability’ in a broad sense means the ability to communicate or transfer data between functional units running on heterogeneous platforms, implemented in different technologies, using industry standard or widely accepted data description and communication protocols.

With so many technologies lined up to challenge the Enterprise, ‘Interoperability’ has been the need of the hour. Businesses these days are thronged by the genesis of various technologies which are meant to solve/ease the existing business process. Hence there is always a need/hunger to opt for such technologies without ruling the fact to retain existing investments.

This white paper specifically addresses the ‘Interoperability’ between .NET and J2EE applications, in explaining the various techniques by which ‘Interoperability’ can be achieved. This white paper also recommends the preferred way and charts down some of the best practices in achieving ‘Interoperability’.

2. Prelude

Microsoft.NET and J2EE are the two new solution development environments which cater to the technological demands of an organization. They have proved their mettle in the market and each of these platforms has their share in the market. Both of these platforms support open standards such as SOAP, Web Services Description Language (WSDL) and XML.

Organizations round the globe have invested on these platforms to a greater extent and with the surge in new features/enhancements to the technology framework, businesses tend to invest on new systems or enhance their existing systems. In the process of building new systems, the one question that stands out is on the existing investments. Organizations want to leverage on existing investments thus achieving collaboration and information sharing. This is only possible if the applications are interoperable outside their paradigm.

Irrespective of the technology chosen, either .NET or J2EE, the one major question for which we need an answer is ‘How Interoperable would be the new system with the existing systems in the Enterprise?’ The organizations outlook on the latest trend in technology definitely includes a thought on leveraging the past investments. Many organizations have heterogeneous applications being developed and maintained and making those applications interact would pose a big challenge unless the technology supports certain industry standard communication protocol.

In the past, it would have been a costly investment to achieve scalability, reusability, and collaboration if the technology does not carry certain ingredients to achieve the same.

Gone are the days wherein Organizations opted to substitute their entire Business Operations, which cost them time and money. With increasing demand for efficiency, responsiveness and thin budgets, Interoperability has been the key factor for the business to grow.

Here in this white paper we specifically address the Interoperability techniques that are available for applications developed in .NET and J2EE to interact. The Interoperability techniques have been addressed at each application tier namely presentation, business and data/resource tier.

3. Need for Interoperability: .NET and J2EE

Many organizations already operate large enterprise environments based on either Java or Microsoft.NET. Hence if the company perceives a need for a new application or addition to their current architecture, the automatic tendency is to start thinking in terms of the currently implemented environment. Designing enterprise systems using either J2EE or Microsoft.NET is an expensive business, but there are often sound business reasons for organizations to implement a mixed environment that has elements of each platform

Under such mixed environment in the enterprise, there is always a need for applications to interact in meeting the business goals. Again, reusing existing systems is usually highest on the list of considerations in developing interoperable solutions.

4. Common Questions on Interoperability

Having understood the need for Interoperability, we are posed with certain technical challenges in achieving Interoperability between .NET and J2EE. Following are some of the questions that prop up

How can we create a solution in .NET that interoperates with a J2EE application?

What products exist today that would assist interoperability?

How do we exchange data?

What should be the approach in designing such applications?

How easy or tough is to make these disparate systems interact?

This white paper answers most of the above questions further in the document with respect to .NET or J2EE

5. Common means to achieve Interoperability

At the most basic level, implementing interoperability between application platforms involves the exchange of data. There also exists, data exchange challenges in primitive data type mappings, non-existent data types and complex data types. In other words, to make data exchange possible, both the platforms should agree upon a data type before any attempt is made for data exchange.

In Enterprise environments, there are three interoperability scenarios that frequently occur when developing a common format for exchanging data between .NET and J2EE. They are

Linking New Applications
Linking a new application to an existing application
Linking two or more existing applications

In such scenarios the techniques of XML Serialization in conjunction with XML schemas are adopted to enable interoperability.

Interoperability can happen at any tier of an application architecture. Applications can communicate at presentation, business or resource/data tiers. There can also be a point to point interoperability in which the technology boundary defines the integration point at each end of the application. From there on any interaction between the applications across technology boundary communicates via the integration point.

Web Services and .NET Remoting via technology bridges, asynchronous communication via queues are some of the most predominant ways of achieving interoperability.

The following section discusses more in detail the adaptation of various techniques at various tiers to enable interoperability between .NET and J2EE applications.

6. Collaborative Techniques

6.1 Point to Point Interoperability

As mentioned before, Point to Point interoperability is one of the predominant ways of implementing interoperability between .NET and J2EE. Point to Point interoperability is more of a synchronous communication and the technology options to achieve such communication is via

6.1.1 Microsoft .NET Remoting (Ja.NET)

Remoting is Microsoft’s communication and data transfer mechanism for distributed computing built on the .NET framework. This is primarily designed for communication between .NET framework applications. Remoting provides an extensible communication framework that can be built on and customized to enable connectivity with Java applications. However, Java applications cannot connect using .NET framework directly. They require the implementation of a runtime bridge. Runtime bridges expose Java objects and methods in a way to address the same via .Net Remoting and vice versa. There are quite a few of the runtime bridges in the market, and Ja.NET from Intrinsyc (http://www.intrinsyc.com) is one of the popular runtime bridges.

Ja.NET is a unique bridge between the world of Java and the world of Microsoft.NET. Ja.NET provides a two-way implementation of the .NET Remoting stack for Java. Using Ja.NET, you can generate Java proxies that expose or consume components using the .NET Remoting protocol. Since Ja.NET is a bi-directional bridge, accessing Java from .NET generates a set of C# proxies. Similarly, accessing .NET from Java generates a set of Java proxies.

One of the most interesting features of .NET Remoting is that the transport protocol and the data formatting are configurable and extendable. Currently .NET and Ja.NET support both HTTP and TCP/IP transport protocols, and either SOAP or binary data formatting.

In the generated proxies, the by value class contains all its fields and the remote by reference class contains only the shell that defines the class definition. Ja.NET needs these for compile definitions, and then again at runtime for the Transparent Proxy class to mimic the remote server. This is a typical scenario wherein calls are marshaled across technology boundary.

When accessing .NET from Java we need custom code to initialize the Ja.NET runtime, as well as any remote send or receive classes. On the other hand, .NET does not require any special code, as Ja.NET follows the .NET rules for remotable objects.

Common Steps Involved in implementing Interoperability between .NET and J2EE application using Ja.NET

· Step 1

GenJava or GenNET tool generates the relevant proxies for .NET component and the EJB accordingly. These proxies would be configured with the Ja.NET runtime in terms of the location/URL.

· Step 2

The Ja.NET runtime would be configured to route the calls accordingly to the relevant functional entity. Step 3 depicts a sample application interoperability implementation between Java and .NET in Java accessing a .NET component

· Step 3

The above is a typical implementation to demonstrate interoperability between .NET and J2EE using Ja.NET Runtime Bridge.

Ja.NET has a set of tools assisting the generation of proxies as well as the runtime management of calls across application/platform boundary. The same are highlighted/discussed in the section titled ‘Tools Assisting Interoperability’.

6.1.2 Borland Janeva

Borland® Janeva™ is designed to provide seamless, high-performance interoperability between Microsoft® .NET Framework applications and J2EE™ and CORBA® infrastructures. Janeva allows Microsoft .NET Framework client- or server-based applications to access J2EE and CORBA server-side components through the highly scalable and secure Internet Inter-ORB Protocol (IIOP™). Janeva is tightly integrated with popular development environments for the Microsoft .NET Framework, including Microsoft Visual Studio® .NET and Borland C#Builder™.

Janeva helps accelerate the application lifecycle at a low total cost of ownership: implementation requires no expertise with J2EE or CORBA technologies, no change to back-end systems, and no additional hardware or software infrastructure.

Features of Janeva

· Ease-of-use layer for client-side development

With Janeva, .NET developers can rely on an ease-of-use layer to shield them from the complexity of the J2EE and CORBA models, keeping the client-side .NET programming model simpler and more familiar. Client side developers can program exclusively using the Microsoft .NET Framework, requiring virtually no expertise with server-side development issues.

· Support for any Microsoft .NET language, any .NET development tool

During development, Janeva compilers produce .NET stubs, which are packaged into .NET Assemblies. The stubs do not target a specific language but rather target the Microsoft® Common Type System – the Microsoft language-neutral type system. Thus, Janeva stubs are directly accessible in any .NET language and can be inspected by any development tool that supports .NET Assemblies.

· Non-invasive server-side deployment

During deployment, Janeva embeds a .NET Assembly and runtime library directly in the client-side .NET application. Unlike alternative connectivity solutions, which typically require technology deployment into both the client and server environments (and may even require refactoring of the server components), Janeva is non-invasive and transparent to existing J2EE and CORBA deployments.

· Enterprise-class runtime capabilities

At runtime, Janeva provides rich middleware functionality including: advanced quality of service such as load balancing, fault tolerance, transactions, and scalability; a high-performance, scalable engine for reading and writing IIOP packets; and automatic data conversion with support for complex data types. Janeva also provides for stateful services with a distributed object model.

6.1.3 JNBridgePro (http://www.jnbridge.com)

JNBridgePro is a Java/.NET interoperability tool that enables the integration of pure Java with Microsoft .NET applications, while maintaining Java’s cross-platform capabilities and conformance

to Java standards. JNBridgePro allows classes written in .NET languages like C#, C++, and Visual Basic to seamlessly and transparently access Java classes as though Java were itself a .NET language.

JNBridgePro supports J2EE and the leading J2EE application servers, allowing .NET code to access J2EE facilities including EJBs and JNDI.

JnbridgePro is designed so that the .NET objects interact with the Java objects through an automatically generated set of proxies. The Java objects behind the proxies may be on the same

Machine as the invoking .NET objects or on a different machine on the local area network or across the Internet; communication between the .NET and the Java objects uses .NET’s remoting

Mechanism, and both HTTP/SOAP and a fast binary protocol are supported. The Java objects’ Lifecycles are managed through .NET’s native lifecycle management mechanism; the user need not worry about .NET remoting’s more complicated lifecycle management mechanism.

JNBridgePro Architecture

A system using JNBridgePro consists of components on both the Java side and the .NET side (As Shown Below). On the .NET side are the classes of the driving .NET application, the assembly consisting of the generated proxies, and a runtime component containing a set of core proxies and classes to manage Java-.NET communication and references to Java objects. On the Java side are the Java classes (either as individual class files or JAR files), and a Java runtime component that manages communication, method dispatch, and object references on the Java side. The Java side can run inside a standalone Java Virtual Machine (JVM), or in any application server that contains a J2EE servlet container. The .NET side can be a standalone application, an ASP.NET Web application, or a Web service. JNBridgePro supports communication between Java and .NET sides using HTTP/SOAP or a fast binary protocol based on .NET remoting. No change to the code is required to switch between communication protocols, only changes to configuration files.

6.1.4 Web Services

In the previous section, we saw how .NET Remoting along with a runtime bridge, enables interoperability between Java and .NET. But .NET Remoting is proprietary to Microsoft and hence this calls for a platform neutral solution to enable interoperability between a .NET and a J2EE application. This brings forward a technique based on standard internet protocols and industry standard data exchange protocol – ‘Web Service’

Web Service is spearheading the interoperability initiative in the market. Web Service expose useful functionality through industry standard protocols i.e. SOAP over HTTP. Because Web Services are standard based and platform independent, they provide a natural fit when it comes to getting applications in different platforms to interoperate with each other.

Web Service contain useful functionality exposed via standard protocols and the same is available in detail in an xml file called Web Service Description Language (WSDL). WSDL is enough to build a client application which interacts with a web service.

Both .NET and Java offer implementations of web services, with varying degrees of integration into the underlying platform. Web Services are well suited in serving functionality over the internet and they are a promising technology for Enterprise Application Integration. Both .Net and J2EE development environment supports development of web services. On development, they can also be published in a universal registry for exposing the same to the external world. This is commonly referred to as UDDI (Universal Description, Discovery and Integration) registry database. A web service can be consumed by any application irrespective of platform or language. Below diagram illustrates typical application integration via a web service

The above process works in the same fashion when a Java Client consumes a web service.

Also, Web Service may not be desirable for all kinds of application interoperation as SOAP is text based and the calls might be too slow for applications that require frequent, fast and fine grained communication.

6.1.5 TCP Socket Communication

This is one of the most common means of achieving interoperability between a .Net application and a J2EE application. This qualifies as a point to point synchronous communication technique. .Net and J2EE applications can communicate via sockets by sending data packets conforming to a predefined industry standard or a custom format.

6.2 Interoperability @ Presentation Service Tier

It is interesting to understand the way we make a .NET application and a J2EE application interoperate at the presentation tier. Typically we can have a web service interface, a Ja.Net or a Janeva interface which can act as a bridge to such interoperation. But this may require a bit of revamp at each side of the platform. If we need to just reuse the existing investment and make interoperability happen, then we can make an ASP.NET application consume a Servlet. Yes, this is possible though it is not a straight forward usage of the Servlet. We got to host the Servlet in an IFRAME within an ASP.NET page.

Another important tool which assists interoperability, in the presentation tier, is Jacob; it’s been heavily used in office automation application written in Java Swing.

6.2.1 Jacob (Java-COM Bridge)

JACOB is a JAVA-COM Bridge that allows you to call COM Automation components from Java. It uses JNI, Java Native interface, to make native calls into the COM and Win32 libraries. The JACOB project started in 1999 and is being actively used by thousands of developers worldwide. As an open-source project, it has benefited from the combined experience of these users, many of whom have made modifications to the code and submitted them back for inclusion in the project.

Jacob can also be made to interact with .Net components by using the COM interop technology.

6.3 Interoperability @ Business Service Tier

Interoperability at the business tier is nothing different than a point to point interoperability discussed earlier in the paper.

6.4 Interoperability @ Data/ Resource Tier

6.4.1 Data Tier

One of the easiest and the most common way to achieve interoperability is via shared databases. There might be scenarios wherein two applications, on different platforms, share the same underlying database. This configuration addresses the issue of maintaining multiple data stores. Sharing a database between .NET and J2EE is a simple and effective means of implementing interoperability between the two environments.

Both platforms have had mechanisms to implement database connectivity since they started. The existence of database drivers makes it easy to link business tier applications to a common back-end storage and share tables, records, and fields between platforms. Each platform has a built in data access API: ADO.NET in .NET Framework and JDBC in Java, which enables data access.

6.4.2 Resource Tier

Implementing Interoperability at the resource tier is more of asynchronous communication. Asynchronous interoperability covers the situation where a client makes a call to another tier or process. Having made the call, the client can then continue to operate while the remote component processes the request, rather than wait for the result.

The usage of Microsoft Messaging Queuing (MSMQ) and IBM Web sphere MQ (MQ Series) fall under the implementation of asynchronous interoperability. Introducing BizTalk Server between two disparate systems would also contribute towards implementing interoperability.

Java Messaging Service (JMS) and System. Messaging service provide the necessary interfaces to interact with the queue. It is possible for a .NET/ J2EE application to send and receive messages via MSMQ or MQ Series accordingly. Again if there is a need to implement interoperability between MSMQ and MQ Series, then we got to go for MSMQ-MQSeries Bridge that is shipped with Microsoft Host Integration Server. This provides a bridge between Microsoft MSMQ and IBM MQ Series.

In addition to the above, BizTalk Server can be adopted for XML document exchange between .Net and J2EE application (A typical scenario of an Enterprise Application Integration)

7. Tools assisting Interoperability

In this white paper, we have discussed about the usage of Runtime bridges to achieve Interoperability between a .NET application and a J2EE application. These runtime bridges are provided by a third party vendor. There are two such vendors, one of which we have discussed in this whitepaper.

Ja.NET (http://www.intrinsyc.com ): is a unique bridge between the world of Java and the world of Microsoft.Net. There are six parts that make up the Ja.NET toolset. These are

· GenService: The GenJava and GenNet tools use GenService to provide access to .NET Framework assemblies for development. You require only GenService to generate proxies, so you do not need to install it in the production environment

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

· GenJava: generates Java proxies that access .NET Framework assemblies through Ja.NET runtime

· Janetor: The Janetor tool allows you to view and modify the Ja.NET runtime configurations settings. You can also Janetor to generate WAR (Web Application Archive Files that reside on Web Sphere Server) files to assist with deploying the Ja.NET runtime onto a web server.

· Ja.NET TCP Server: provides standalone hosting for Java classes through the Ja.NET runtime where the classes are not hosted on a J2EE server. The Ja.NET runtime includes this component.

· Ja.NET Runtime: is the main collection of classes that hosts the tools. The Janet.jar file contains the runtime components

8. Recommendations or Best Practices

Following are some of the practices that are recommended while implementing interoperability between .NET and J2EE applications.

· While using Ja.NET to implement interoperability, recommended practice

o Usage of binary protocol for .NET Remoting

o Deploy WAR packages on the application server to access EJBs and JMS

o Understand .NET Remoting to facilitate good design practice

· While using Web Service to implement interoperability

o Use simple data types so that it compliments each of the platform involved in interoperability

o Base all data types on XSD data types so that this ensures that the data types is the complex data objects map to types in .NET Framework and Java

o Separate out the data types from the proxy file and store them is a separate location. This is particularly useful when the .Net and the Java assemblies require a single XML namespace for all types

· While sharing data between ADO.NET and JDBC, it is recommended

o To abstract database access code from the rest of the application

o For ease of coding and consistency, a layer that abstracts the database code from the business logic should be implemented

· In general, from the architecture perspective of .NET and J2EE

o It is recommend to divide a multi tiered application into three logical layer namely presentation, business and data/resource tier

o Implement service interfaces that expose each tier’s façade through the interoperability mechanisms

o Create interoperability adapters either for each service interface or for each use case depending on the level of fine control required

o Provide multiple abstraction layers to ensure maximum flexibility for future developments

9. References

· Patterns & Practices: Application Interoperability: .NET & J2EE

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/jdni.asp

· .Net and J2EE Interoperability MSDN Chat:

http://msdn.microsoft.com/chats/vstudio/vstudio_121202.asp

· Jacob

http://danadler.com/jacob

· Janeva

http://www.borland.com/janeva/

· JnBridge

www.jnbridge.com

· Ja.NET

http://www.intrinsyc.com

10. Conclusion

Interoperability sets a new paradigm for Enterprise Applications to collaborate. The need for Interoperability aggravates, as more and more applications are developed in an Enterprise. A careful thought has to be given while designing an implementation strategy for interoperation. End of the day, it does not matter what technology or platform the applications are developed, as long as the applications collaborate and benefit the business in its functioning. Even though .NET and J2EE are disparate platforms which works on different strategies, could collaborate, thus complimenting the reuse of existing investments in an Enterprise.