Interoperability Capabilities

This section introduces major interoperability capabilities provided by Java EE Platform and discusses how these technologies can be applied to address Java EE .NET interoperability requirements.

Messaging

JMS provides a reliable asynchronous messaging between loosely coupled components with connection management and session management. For point-to-point messaging, a JMS producer issues a "send" command to transmit business data or service request in a pre-defined message format asynchronously to the JMS queue. The JMS consumer then issues a "receive" command to receive the message. However, JMS is an abstraction API, and it requires both ends (the producer and the consumer) to share the same underlying data transport and compatible physical implementation (such as the same middleware implementation).

Please note that Microsoft Message Queuing (MSMQ) does not use the same data transport or physical implementation as JMS products. Thus, it is not feasible for a .NET application to send a service request to the JMS queue via MSMQ and route to a Java application using JMS. For a .NET application to connect to a JMS queue, it is possible to wrap the JMS client (whether consumer or producer) with an ActiveX control. In such a way, the JMS client can act as an ActiveX control object that can send or return business data to a .NET application. Refer to Figure 1-3. [DotNetMQ] discusses an example of how WebSphere MQ uses an ActiveX control to interoperate with a .NET application.

Figure 1-3. Interoperability capability for messaging using JMS

Distributed Objects

RMI-IIOP with the Java Interface Description Language (IDL) provides a standard interface to discover and invoke distributed objects and CORBA services. The RMI-IIOP protocol and the Java IDL are means to invoke CORBA objects dynamically and remotely.

Java technology can also integrate and interoperate with the .NET platform. Java Native Interface (JNI) is a commonly used approach to integrate with C# programs. Developers can generate a JNI stub with a C header file, where JNI will communicate with C++ code, and the C++ code will invoke C# code. With this approach, Java clients initiate the remote C# applications. A COM bridge (Java SE 1.4.2) or a JavaBeans bridge for ActiveX (JRE 1.4.1) also can be used. The COM-ActiveX-OLE container will be able to capture application events fired by JavaBeans. JavaBeans can also act as a server for COM-ActiveX-OLE method invocation. Refer to [FisherSharma] for more details.

Web Services

Java APIs for XML-based Remote Procedure Call (JAX-RPC) enables a Java application to invoke a remote Web service synchronously using a remote procedure call mechanism. The client application can use a standard service definition (as defined in Web Services Definition Language or WSDL) to invoke remote business service or to reply with the data result. A JAX-RPC client stub maps the service request to data types specified in the WSDL file and invokes RPC calls via the service proxy. The server tie (service provider) receives the service request, maps the service request to the local data types, and processes the service request.

The example in Figure 1-4 depicts how a .NET application exchanges business data with another Java application using JAX-RPC synchronous Web services. In the Java EE .NET interoperability scenario, the client can be a JAX-RPC client issuing a service request to a .NET application. JAX-RPC decouples the business services from the underlying data transport, which simplifies the interoperability between the different underlying data transport in both platforms.

Figure 1-4. Interoperability using Web servicesJAX-RPC

JAX-RPC version 1.1 provides the framework for exchanging SOAP messages. However, it does not handle SOAP messages with attachment, which includes large graphic objects or documents. Several mechanisms are used to encode the attachment (such as base64 binary encoding), but none of them is truly interoperable across platforms. SOAP with attachment has been problematic between Java and .NET platforms. Message Transmission Optimization Mechanism (SOAP MTOM) is a draft W3C specification that addresses SOAP with attachment. Java API for XML Web Services (JAX-WS) version 2.0 is a successor to JAX-RPC version 1.1 and is renamed from JAX-RPC to JAX-WS (refer to https://jax-rpc.dev.java.net/ for details). SAAJ provides a lightweight messaging capability for Web services components, including legacy systems. Unlike JMS, SAAJ does not have reliable messaging capabilities due to the nature of the underlying SOAP over HTTP protocol. However, it is more flexible to interoperate and work with a non-Java platform using asynchronous messaging.

Business Process Integration

Java Business Integration or JBI (www.jcp.org/en/jsr/detail?id=208), as specified in JSR 208, defines a framework to orchestrate different business processes. Sun releases early access versions of the reference implementation under http://java.sun.com/developer/earlyAccess/jbi/. Figure 1-5 depicts an example where JBI can connect a Java-based Web service to another .NET Web service. In this sample scenario, the middleware Enterprise Service Bus (also refer to Chapter 9, "Messaging," for details on Enterprise Service Bus) provides a multi-messaging protocol support for both the .NET client and the Java client.

Figure 1-5. Interoperability using Java Business Integration

The NET client may be using MSMQ or SOAP-based XML Web services to issue a service request. The Enterprise Service Bus acts as an intermediary and routes the service request to Business Service 1. The incoming service request ("IN") is processed in Business Service 1 and output ("OUT") to the Business Service 2. Business Service 2 processes the incoming service request (from the "OUT" of Business Service 1) and returns the result to the Enterprise Service Bus. Both Business Service 1 and Business Service 2 are using the protocol specification defined in JSR 208. Upon completion of both business services, the Enterprise Service Bus alerts the Java client to pick up the processing result using the client's preferred protocol (which can be JAX-RPC, JMS, SMTP, and others).

Enterprise Service Bus (ESB) is an overloaded term in the IT industry. IBM defines ESB as a "middleware that unifies and connects services, applications and resources within a business." (http://www-306.ibm.com/software/info1/websphere/index.jsp?tab=landings/esbbenefits). Gartner Research defines ESB as a core component in a Service-oriented Architecture and acts as a "shared messaging layer for connecting applications and other services throughout an enterprise computing infrastructure." (http://looselycoupled.com/glossary/ESB). Some vendors use the term ESB to refer to their current messaging infrastructure products, and some use the term to refer to their workflow products that are JBI-enabled. But in either case, ESB is a core technology that enables business process integration for Java EE .NET interoperability.

Integration with Non-Java Platforms

The integration capability using messaging, distributed objects, and Web services also allows business applications built in Java EE Platform to interact and integrate with non-Java platforms, including .NET and C++. The constraint is that non-Java platforms must support the same integration technology. For instance, there is a C++ implementation for JMS, CORBA, and Web services.

Others

Security and management are two other key interoperability technologies in Java EE Platform. Web services security defines the security framework for exchanging business data using Web services. WS-I Basic Security Profile defines the semantics of the SOAP messages using Web services security. Please refer to Chapter 13, "Java EE .NET Security Interoperability," for more details. WS-Management defines the framework for encapsulating service information in case of hardware fault or system failure. Please refer to Chapter 15, "Managing Java EE .NET Interoperability Applications," for more details.