An enterprise platform has to provide ways to integrate with existing systems and applications. The fact is, most companies have applications and they don’t exist in isolation. New applications developed on the J2EE platform need to be integrated with other applications. Although this might sound relatively simple, we must be aware that companies need fully integrated information systems. This means that all applications, no matter which technology they’re developed in, function as a large integrated system. The total integration of applications within a company is referred to as Enterprise Application Integration (EAI).

Although we won’t go into details, for successful EAI we have to select the integration infrastructure technologies and define the integration architecture.

Effective integration infrastructure should address relevant middleware technologies that are required for EAI. Frequently we’ll have to use more than a single middleware technology. When selecting and mixing different technologies we have to focus on their interoperability. Achieving interoperability between technologies can be difficult even for those based on open standards; for proprietary solutions interoperability is even more difficult.

It’s not only a question of whether we can achieve interoperability but of how much effort we have to put in to achieve it. Therefore, companies are leaning more toward software platforms, such as J2EE, that gather compatible technologies. The J2EE platform provides a number of protocols and technology specifications for these purposes. The most important protocols are HTTP(S) and IIOP. The most important middleware APIs are JDBC, RMI-IIOP, Java IDL, JMS, Java Connector Architecture, and JNDI. Very important APIs, which we’ll discuss in detail later, are also JAXP for XML support, JTA and JTS for transaction support, and JAAS for authentication and authorization.

Integration architecture specifies the overall structure, logical components, and logical relationships between all the different applications we want to integrate. Usually integration architecture is built through the following integration levels:

• Data: Focuses on moving data between applications with the objective of sharing the same data among the different applications.

• Application interface and business method: Both focus on sharing functionality and data, not just pure data. Application interface-level integration is achieved through the use of lower-level APIs. The goal of business-level integration is to develop virtual components that will provide interfaces with high-level business methods that can be considered business services.

• Presentation: Implements a common user interface for the business method–level integrated information system.

The integration architecture should provide the basis for an enterprise-wide information system that will benefit from the synergy provided by the integration of different applications. We have to define an architecture that makes it possible to reuse existing applications. And the architecture should easily accommodate new generation applications, providing a scalable architecture that will allow us to easily make changes and modifications in the future.

There’s nothing controversial in stating that we should use the multitier architecture. The problem is that most existing applications (particularly legacy) don’t comply with this architecture. They don’t look like components, which are the building blocks of modern multitier applications. The challenge, therefore, is how to make the existing applications look like components.

Virtual Components
The solution is to find ways to encapsulate existing applications into virtual reusable components that will provide several interfaces and expose the functionality in a universal manner. To define and implement virtual components, we’ll follow the runtime reusability of the business logic implemented in the existing applications and delegate operations to one or more existing applications.

When accessing these virtual components through the interfaces it doesn’t matter whether we’re dealing with a newly developed component or a virtual component that encapsulates an existing application; we’ll access both in the same manner. Figure 1 shows the business logic tier with two virtual components that reuse existing applications as well as a newly developed component, all exposing their functionality through interfaces.

On one side, the virtual component presents the existing application through abstract interoperability interfaces; on the other, it communicates with the existing application using the existing facilities. Virtual components with abstract interoperability interfaces present an application view that’s implementation-independent. If we keep the abstract interface constant, the other applications are not aware of any changes made on the original application. Thus, when a change is made, there’s no need to modify other applications that depend on the original application. In other words, client virtual components can’t determine how the server virtual components are implemented.

An integrated information system based on virtual components looks like a newly developed information system, as it actually reuses the functionality of existing applications. Note that in each integration level we’ll build more complex and abstract virtual components:

• Data: Virtual components will provide access to the data only.

• Application interface: Virtual components enable you to reuse not only the data, but also the functionality of existing applications. However, the reuse of functionality takes place at a low abstraction level, and basically resembles the application programming interfaces built into existing applications.

• Business method: Raises the abstraction level of virtual components to the level where the interfaces will provide high-level business functions.

• Presentation: Adds a newly developed presentation tier on top and makes the integrated composite information system look like a newly developed information system.

Implementing Virtual Components in J2EE
As we know, J2EE is built on the multitier application model and components are the building blocks of each tier.

• The components for the client tier are application clients and applets.

• The components for the Web component tier are servlets and JSP pages that provide the ability to service thin clients. They respond to HTTP requests and generate thin-client user interfaces using HTML, XML, and other technologies.

• The components for the business logic tier are EJBs. These provide an environment that supports services such as transactions, security, and persistence.

The only tier that doesn’t consist of components is the EIS tier. This tier contains the existing enterprise infrastructure, such as ERP systems, TP monitors, and database management systems.

J2EE supports several open standards for communication between tiers. This includes HTTP(S) and IIOP protocols and APIs, such as JDBC, JMS, JNDI, and Java Connector Architecture. This enables us to include components that haven’t been developed in Java on practically any other tier, thus providing a way to develop virtual components for existing applications.

On the business logic tier we can deploy EJB components as well as CORBA (and RMI-IIOP) distributed objects and components that communicate through a JMS-compliant MOM. This is one of the most important facts for integration. We can see that for developing virtual components on the business logic tier we’re not limited to EJBs, but can use CORBA, RMI-IIOP, and MOM components too. Please note that CORBA and MOM components don’t have to be developed in Java, rather we can use a variety of programming languages. Both CORBA and leading MOM products support all popular programming languages, including C++, C, Smalltalk, Ada, COBOL, Delphi, and even Visual Basic.

Since these non-Java components don’t reside in the EJB container, they can’t take advantage of the managed environment provided by containers. However, they can still take part in transaction and security mechanisms. For this they have to use the corresponding APIs, but we’ll come to this later.

On the Web component tier we can also deploy other non-Java components. These include any components that can respond to HTTP(S) requests. Again, we can’t execute them into the Web container provided by the J2EE application server. However, we usually won’t be accessing existing applications directly from the Web component tier but via the business logic tier.

The same is true for the client tier – the application clients are not necessarily Java applications. They can be developed in other languages and use the identified protocols to communicate with the other tiers. Examples include Web browsers, CORBA clients, and MOM clients.

This brings us to the extended J2EE integration architecture that we’ll use to achieve J2EE EAI, shown conceptually in Figure 2. The extended J2EE integration architecture cleanly separates the tiers and places a limited set of protocols that can be used for communication between the tiers. The business logic tier separates the Web component and the client tier from the EIS tier. The client and Web component tier shouldn’t access the EIS tier.

The only way to access the EIS tier is from the business logic tier. Here the EJB, CORBA, RMI-IIOP, and JMS-compliant components use a variety of protocols and technologies to access the EIS tier. Only here we’re faced with the heterogeneity of the existing applications located in the EIS tier. The business logic tier thus implements the Façade pattern for the Web component and client tiers. Through this Façade, the business logic tier provides access to business functionality through clearly defined interfaces.

Accessing Existing Applications
Virtual components are not very difficult to implement, especially if existing applications already provide some APIs through which we can access the required functionality programmatically. Then we don’t even have to modify existing applications.

If the existing applications don’t provide any APIs or if they’re provided but don’t meet our requirements, we’ll have to define and build them. For this we’ll modify the existing application and add the necessary APIs. We’ll call the API a wrapper and the modified existing application will be referred to as a wrapped existing application.

Adding wrappers can be quite straightforward, especially in solutions developed in-house and where source code and documentation is available. However, if we don’t have the source code and the documentation is limited, changing the application can be difficult.

When faced with such a situation, we can consider using direct database access or even the user interface to access the functionality. Techniques like screen scraping and terminal emulation, where wrappers access the application functionality through the user interface, can help us get the necessary information without modifying the applications. CORBA and JMS are the most frequently used technologies for developing wrappers in J2EE. Wrappers are schematically shown in Figure 3.

Support for XML
Although I’ve discussed the integration architecture, I didn’t mention the formats that can be used for exchanging data between applications. In the last few years XML has established itself as the de facto standard for data exchange.

The power of XML lies in the possibility that we can define the tags ourselves, enabling us to describe any data in any structure (although XML is perhaps best suited to hierarchical data structures). However, freely defined tags can cause semantic problems in the data exchange. It’s impossible for a computer to “guess” the meaning of the data from the tags. A vocabulary agreement must be achieved between the parties in which each party has to support the same set of tags in the form of a clearly defined DTD or Schema. Achieving an agreement on vocabulary inside the company is not as difficult as between companies. Therefore great effort is put into the definition of standardized vocabularies for different industries.

J2EE v.1.3 provides support for XML through the Java API for XML Processing (JAXP). JAXP enables you to verify, create, access, and manipulate XML documents from Java components. To manipulate an XML document, it must first be parsed. In the process of parsing, the document is often validated. Then the content of the document must be made available through an API. Currently, two important APIs are supported – the Document Object Model (DOM) and the Simple API for XML (SAX) – by JAXP. JAXP 1.1 also includes an XSLT framework based on the Transformation API for XML (TrAX).

Support for XML, provided through JAXP, is adequate for EAI. Still, Sun’s Java Community Program is currently defining additional XML-related specifications, most of them focused on Web services, including:

• JAXM (JSR 67) – Java API for XML Messaging: Provides an API for packaging and transporting document-oriented XML messages using on-the-wire protocols defined by ebXML.org, Oasis, W3C, and IETF

• CAX/RPC (JSR 101) – Java API for XML Based Remote Procedure Calls: Supports XML-based RPC standards

• AXR (JSR 93) – Java API for XML Registries: Provides an API for a set of distributed registry services that enables business-to-business integration between business enterprises using the protocols defined by ebXML.org

• JWSDL (JSR 110) – Java Web Service Definition Language: Provides a standard set of APIs for representing and manipulating services described by Web Services Description Language (WSDL) documents. These APIs define a way to construct and manipulate models of service description

• JAXB (JSR 31) – Java API for XML Binding: Allows us to compile an XML Schema into one or more Java classes that can parse, generate, and validate documents that follow the Schema

Support for Different Types of Clients
Integration architecture is also concerned with providing support for different types of clients. In fact, the integration architecture already supports different types of clients: rich GUI and Web. Web clients use the Web component tier, which generates the presentation for the client tier. Today the most common approach is to generate HTML pages.

However, this technique can’t fulfill the increasing requirements to support other types of clients, such as Palm top computers, mobile phones, or any other device that enables client access. While there’s no hindrance in developing different Web components that would generate different presentation formats, this solution is costly because it requires the additional development of Web components for each distinct client type. These Web components also contain very similar logic – they differ only in the way they present the data, which introduces maintenance problems.

The solution is to generate the content in a universal way only once, and then enrich it with the appropriate presentation information in order to present it to the client.

Unfortunately, version 1.3 of the J2EE platform doesn’t provide a technology that would make this procedure automatic, as does Microsoft .NET. But in J2EE we can still reach a high-level of automatism with its built-in support for XML. Rather than generating HTML pages on the Web component tier, we can generate XML, which then has to be transformed to a presentation appropriate for the client tier. This can be HTML for Web browsers, WML for WAP devices, or any other appropriate format. The transformations between these formats can be done with Extensible Stylesheet Language for Transformations (XSLT) supported by JAXP. In addition to XML, the XSLT engine requires a stylesheet that defines how different parts of the document will be represented on the client. The XSLT engine then performs the transformation (see Figure 4).

Summary
J2EE is a very suitable platform for EAI as it provides support for open-standard technologies and protocols that enable integration with existing applications. It also provides support for XML and related technologies, which we can use for data exchange and for supporting different types of clients.

Resource
• Juric, M.B., with Basha, S.J., Leander, R., and Nagappan, R. (2001). Professional J2EE EAI. Wrox Press.

Java was not originally designed as an enterprise platform. However, over the years it gained a new functionality dedicated to enterprise computing that became the Java 2 Platform, Enterprise Edition (J2EE). J2EE, currently in version 1.3, is one of the most important modern enterprise platforms.

• Figure 1
• Figure 2
• Figure 3
• Figure 4