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.
Figure 1:
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.
Figure 2:
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.
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).
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.
Author Bio
Matjaz B. Juric is an assistant professor at the University of Maribor, and
is the author of Professional J2EE EAI and coauthor of Professional EJB. Matjaz holds a PhD in computer and
information science.
matjaz.juric@uni-mb.si
