Java EE and .NET Interoperability: Integration Strategies, Patterns, and Best Practices

Having come a long way, Web services considerably simplify integration of heterogeneous applications. However, Web services alone become insufficient to execute complex business processes due to the lack of inherent support for workflow orchestration and management of the distributed infrastructure. Also the messaging patterns mentioned earlier such as Aggregator, Splitter, Routing Slip, and Process Manager, are built in as higher-level functionality implemented as part of an Enterprise Service Bus (ESB), offering, rather than requiring, low-level programming at the messaging layer. Please refer to [ESB] for details.

Scope

Today most companies invest in implementing Web services based on applications in Java or .NET. In most cases these new applications have to be co-dependent on legacy business systems. Building reliable integration across disparate applications can be achieved with Web services and messaging. However, for a successful business execution, enterprises require a platform that delivers a high degree of technology interoperability and offers support for business workflow orchestration, data transformation and routing, security, and process management. Management of a distributed Web services environment includes automated deployment and monitoring functionality.

Solution

The answer for these complex Java EE .NET and legacy integration requirements brings into light the value of the Enterprise Service Bus. In a nutshell, an ESB is an integration infrastructure that enables interoperability across heterogeneous applications including Java EE and .NET. For example, a Java EE Customer Sales, .NET Finance, and a legacy ERP system may have to communicate as part of the business flow. Each of those systems may expose different sets of APIs and do not seamlessly integrate with each other. An Enterprise Service Bus can be used to achieve interoperability across these systems. Modern ESB solutions offer support for Business Process Execution Language (BPEL) and WS-ReliableMessaging in addition to traditional Web services SOAP and WSDL support. Companies such as Sonic Software, Fiorano, Cape Clear, and SpiritSoft, among others, ship ESB solutions. Industry leading ESB vendors offer enhanced performance and security, support for multiple protocols, and adapters to integrate with legacy applications. An open source ESB solution is available from Mule, www.muleumo.org. Refer to [OASIS_WSBPEL], [WS-ReliableMessagingSpec], [SonicESB], [FioranoESB], [SpiritWaveESB], [CapeClearESB], and [MuleESB] for more information.

Figure 9-19 outlines the integration points of an enterprise Web services architecture where the business flow has to be orchestrated across multiple systems.

Figure 9-19 depicts a typical ESB-distributed object broker infrastructure. The architecture is composed out of ESB service containers deployed along with a lightweight message queue. These containers are distributed at the individual application nodes, such as the Java EE application node and .NET application node, and leverage either Web services or custom, proprietary APIs. Specifically, this architecture comprises Java EE and .NET systems accessed via Web services APIs and a SAP legacy system accessed via proprietary SAP BAPI interfaces. The ESB facilitates the overall business process orchestration across Customer Sales, Finance, and ERP systems critical to successful business operations. One of the main benefits of an ESB solution is the ability to plug in existing applications to the integration environment with a minimal amount of work. Some implementations of the ESB solution offer communication between individual service container nodes in addition to the centralized hub provided by the ESB message broker. Most of the ESB vendors offer the capability of monitoring a distributed Web services environment to ensure successful execution of the business processes.

Data Routing

In the context of ESB, data routing is transparent to the Web services implementation. A service can be implemented in Java EE and .NET or embracing legacy ERP and CRM systems. This element of ESB allows individual services to be agnostic to the transport protocol, for example, HTTP or TCP. Data routing can utilize different transport protocols while Web services remain unchanged.

Benefits

An ESB offers a scaleable and secure middleware solution that operates as a backbone of enterprise communications. The remainder of this chapter does not discuss each and every aspect of ESB functionality, but outlines key features supported by most commercial ESB solutions, for example, from Fiorano or Sonic Software.

Management

One of the fundamental requirements of a distributed Web services architecture is the ability to monitor services deployed over the entire network, as well as offer versioning and configuration management of the Web services infrastructure. Administrative tools that are provided as part of the ESB infrastructure allow monitoring of the distributed services from any ESB node on the network. Event-based notification can be employed to notify the administrator of a critical error in the business flow. Developers can troubleshoot live data flows via break points on distributed message queues and dynamically change trace levels for debugging components and business processes.

Remote deployment and upgrades of services across the distributed application environment, which is supported by most ESB solutions, significantly simplifies the system management and accelerates an SOA development cycle. Web services versioning is one of the common issues encountered during SOA development. To address this, FioranoESB, for example, provides a GUI-based tool for managing multiple versions of Web services. Web services endpoints are being labeled accordingly based on development, QA, staging, or production version. These features address common development concerns when building SOA.

Scalability and Performance

The idea of ESB is to be able to leverage Web services technologies and additional functionality within a flexible and scalable architecture. This idea is realized by executing some of the activities nearer to the application itself to avoid bottleneck of a central hub. As was shown Figure 9-19, each of the applications has a component of an ESB deployed near that application to achieve a loosely coupled component-based architecture.

For instance, both Sonic and Fiorano's Enterprise Service Bus employ a brokered Point-to-Point (P2P) architecture that includes the following functionalities: data routing, business workflow processing, and data transformation. Each of these functionalities is performed at the individual network endpoints that interface specific applications. This distributed architecture improves scalability of the overall enterprise system. Centralized ESB servers are responsible for reliable messaging, event handling, security, and administration.

SonicESB supports independent scalability of remote services through a service container architecture. This service container model can provide selective scalability of intermediary services that facilitate the integration process itself. For example, an XSLT-based data transformation can be deployed as a separate service on the ESB. Using the scalability model of the ESB service container, multiple instances of an individual transformation service can be load-balanced across multiple machines to handle various kinds of processing loads, required by the individual data transformations. The ESB messaging servers can also be independently load-balanced and scaled across multiple machines to handle a high volume of message traffic. The independently scalable distributed container model and the independently scalable messaging layer, which work together to support one unified view of an abstract process model, are what make an ESB unique from other approaches to interoperability.

Orchestration

One of the main advantages of an ESB solution over a plain messaging infrastructure is the ability to perform content-based routing. Being able to determine a message destination based on its content to orchestrate business flow simplifies individual application design. With respect to intelligent routing, an ESB solution enables SOA across the enterprise and over the Internet. Otherwise, each and every application participating in a business flow has to have a built-in knowledge of the service endpoint, which results in hard-to-manage and costly integration.

Web Services Security with ESB

The wide acceptance of open-standards like HTTP, XML, SOAP, WSDL, and secure JMS yields an ideal foundation for Web services. When building a secure Web services environment, application assets can be protected using firewalls, SSL, and digital signatures. An XML digital signature is typically applied to only the sensitive portion of a SOAP message to ensure non-repudiation of the message and at the same time to reduce performance overhead. By selectively applying security techniques to a granular content, performance overhead of the application is minimized.

Using Access Control Lists, Java EE, and LDAP-compliant security features enables system administrators with a fine-grained security control across distributed Web service environments. Enhanced security offered by Sonic and Fiorano ESBs includes support for digital signatures, SSL, RSA and DSA encryption, and single sign-on capability.

Support for Standards

Standards-wise, Java and .NET interoperability is achieved by ESB solutions via Web services standards such as WSDL and SOAP. On the Java side ESBs support JMS and Java Connector Architecture (JCA) standards. As you may have already noticed, the business orchestration is one of the fundamental features of an ESB. As a part of the Java Community Process, leading industry vendors are collaborating on standardizing enterprise application integration (EAI) as part of JSR 208, Java Business Integration (JBI), [JSR208]. JBI will provide further standardization around the ESB container and will help drive the shape and definition of ESBs, much like the EJB specification drove the shape and definition of application servers.

The JBI initiative defines architecture and Java and Web services interfaces for plug-in components including document transformation and business process engines. Once JSR-208 becomes a standard, it will foster an ecosystem where integration architects will be able to pick and choose from best of breed integration enabling components that will plug together into an ESB using JBI-conformant SPIs. Examples of pluggable integration enabling components include a Business Process Execution Language (BPEL) engine, or a business rules engine.

JSR-208 will bring a standards-based technology to the industry, and it will be up to the individual ESB vendors to comply with the standards to achieve, Java, .NET, and legacy code integration. Sun Microsystems plans to implement an integration solution, known as Project Shasta, based on the Java Business Integration architecture. There's no doubt that ESB industry leaders such as Sonic Software will deliver commercial ESB solutions that adhere to upcoming JBI standards.

Limitations

Until Java Business Integration standards are adopted across the industry, ESB remains mostly a proprietary solution. Not all ESB vendors provide the independent scalability model of the ESB as outlined in this chapter, thus it is important to evaluate the ESB feature set required by an enterprise. Some integration broker vendors are adding Web services interfaces to their integration brokers and EAI broker productsand labeling it an ESB. Enhanced performance, clustering, failover, and other features are specific to the individual ESB provider and may vary drastically.