Chapter 6. EIS integration using Java Message Service 127
Canonical data formats are introduced to reduce the data transformation
complexity. Figure 6-2 shows an example of a hub-and-spoke topology.
Figure 6-2 Hub-and-spoke topology
Hub-and-spoke topologies have been established successfully by many
customers to solve the issue of integrating many different EIS systems. The
software stack for the hub is often provided by WebSphere Business Integration
Message Broker. Message Broker facilitates the implementation of a hub or
broker infrastructure by providing a comprehensive framework for routing,
transforming, and enriching messages that are exchanged between EIS systems
and applications.
6.3 The EIS integration building block using JMS
This section describes in more detail the characteristics of messaging-based EIS
integration. It first discusses the main drivers that can lead to selecting
integration using JMS. Then, it describes the system architecture and its
Siebel CICS
SAP
Broker/Hub
IMS
Other systems…..
128 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
components and discusses possible extensions. Finally, this section positions
the approach using JMS against traditional integration architectures based on
Enterprise Application Integration (EAI) concepts.
6.3.1 Problem statement
In many organizations, EIS systems are still the core component of the IT
infrastructure. New applications that are built to support emerging business
domains have to make use of those systems, because the core business
processes and business rules are implemented there. For example, Internet
banking that is supported by Web browser applications was an emerging
business domain for all banks in the past. However, the core banking processes,
such as account credit or debit, are still processed in the EIS systems.
The emerging business domains in many organizations have become large,
independent divisions. Internet banking is for many banks now a separate
channel with its own management structure, marketing, and IT departments. In
addition to the structural independence of the new business domains, often the
new business unit is based in a different location to the traditional business units.
Large organizations tend to buy smaller, more flexible emerging companies
rather than building up the new business domains within their organization.
The application required to integrate with the EIS system and the EIS system
itself often are not controlled by the same organizational unit of the company.
Thus, in most cases, there is no common approach for software development,
and, more specifically, no common methodology and best practices for data
modeling. If methodologies have been established, they usually are different.
Many EIS systems have a proprietary data modeling method, or they even rely
on a specific data model. New applications are designed using object-oriented
technology and standards such as UML. The lack of a coherent data model
imposes the need for extensive data transformations if new business
applications and EIS systems must communicate.
New business applications and EIS applications are often deployed in
geographically remote data processing centers. Although consolidation of data
centers is important for many organizations, these activities often fail or are
delayed due to organizational independence of business units. In most cases,
however, business units share a private network. Virtual Private Networks (VPN)
might have been established, or organizations can lease dedicated connections
from network providers to connect to their sites.
In addition to these business level requirements, there are a number of technical
requirements on the EIS integration style. From an application design
perspective, most important are two needs: non-blocking calls to the external
systems and abstraction of the location of the external systems.
Chapter 6. EIS integration using Java Message Service 129
Applications call services that provide a specific function, such as calculation of
the interest rate for a home loan, by sending a request (including the input data)
and receiving the reply (including the result). In most cases, these call services
wait for the result to arrive before they continue processing. That is, the service
call blocks the processing. In most technologies, the application can wait forever
if the service becomes unavailable. So, the application designer has to plan for
service outages. In the case of a J2EE application calling a service implemented
by an EJB, at least an exception is thrown if the service is not available. So, the
application might catch the exception, and the processing can continue by using
an alternative service or by notifying the user about the service outage.
On the other hand, many service calls must not block the processing if the
service becomes unavailable. For example, auditing and logging is important.
However, in case of a auditing service outage, the processing of an account
balance query should not be stopped. A better action is to call the service
asynchronously, so the service call is issued and the application continues
processing without waiting for a confirmation response from the service.
Optionally, the confirmation messages can be collected later in the process to
assure that the audit statements have been written to the audit record.
New J2EE applications and EIS systems typically reside on different hosts and
servers. To connect from applications to the EIS systems, physical networks
have to be established and connections have to be configured. The network
infrastructure may change from time to time. That is, host names, TCP/IP
addresses, and ports for EIS systems can vary. Management of these changes is
an issue if these parameters are hard coded or, in general, are held in the
application. In many situations it is of advantage to hide the actual destination of
an EIS request and provide the application with an abstraction of the destination.
In this case, changes and updates of the EIS system infrastructure can be
managed without touching the application.
To conclude, these are the main requirements that can lead to selecting a
messaging-based integration style:
???? No common data model established and need for extensive data
transformation at the interface application to EIS system
???? Geographically remote application and EIS system
???? Need for non-blocking EIS service calls
???? Need for abstraction of EIS service location
130 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
6.3.2 System architecture
Figure 6-3 illustrates the logical system architecture of the building block that
uses JMS. The main components of the building block are:
???? The J2EE application server that runs the application and includes the JMS
connector to send and receive messages.
???? The JMS provider and the message oriented middleware that is installed on
the application host, the EIS host, and optionally on multiple other hosts in the
network.
???? The EIS system and the JMS connector that enables the EIS system to
receive and send messages.
A typical use case is that the application invokes a function at the EIS by sending
a message including the input data. The EIS system replies by sending the reply
message that refers to initial request. The interaction pattern between the
components is as follows:
1. The application initiates the interaction by generating and sending the
message using JMS APIs.
2. The JMS connector that implements the API creates the message and
forwards it to the JMS provider. The message is put on the queue
3. The JMS provider and the underlying messaging infrastructure accepts the
message and transports the message to its destination, either directly to the
receiving host or indirectly by routing the message through other servers
Figure 6-3 Logical system architecture for EIS integration using JMS
4. The JMS provider at the EIS host receives the message and triggers the JMS
connector.
Application Host
J2EE Application
Server
Application
MOM-Enabled
JMS
Connector
JMS
Provider
EIS Host
JMS
Connector
EIS
JMS
Provider
MOM-Enabled
MOM
Host
Y
MOM
Host
X
MOM
Host
Z
Network
Chapter 6. EIS integration using Java Message Service 131
5. The JMS connector processes the message and calls the appropriate EIS
function.
6. The JMS connector receives the result from the EIS and generates the reply
message that is sent back to application.
In case of a
send and wait for reply interaction pattern, the reply from the EIS
system is sent back to the application the same way the initial request message
was sent. In a
send and continue interaction pattern, the application can continue
its processing as soon as the message is put on the queue (when step two is
complete).
6.3.3 Components of the building block
This section discusses the components of the building block that uses JMS in
more detail from a messaging perspective. It describes the components in the
context of the architecture for back-end integration that were introduced in
Chapter 2, “Architecture” on page 9 and in Chapter 3, “Scenario overview and
design” on page 65.
The J2EE application server
The J2EE application, including Web and EJB components, runs on the
application server. The application server is in charge of managing the
application components. For example, it forwards requests to the components
and initializes a thread pool to process requests simultaneously. The
administration console of the application server is used to enable the application
to use JMS and the underlying messaging infrastructure. Typical tasks for the
administrator are the configuration of JMS connection factories, destinations,
and topics. For WebSphere Application Server, you can also select the JMS
provider that is used. A lightweight implementation is provided named
WebSphere Embedded Messaging. Alternatively, WebSphere MQ can be used.
WebSphere Business Integration Server Foundation includes Extended
Messaging that facilitates sending and receiving of messages by providing
support for interaction patterns such as
send and wait for reply.
The application
Web and EJB components build up the J2EE application. JMS messages are
typically sent by and received from EJB applications. The EJB 2.0 standard
specifies MDB that are used to receive and process messages.
We recommend that you use specific message beans to send and receive the
messages. Message beans encapsulate all the JMS-specific setup that you have
to perform before you can actually send a message. For example, you first have
to create a JMS connection using a connection factory. Then, you create a
sender object by specifying the JMS destination, initialize the message, and
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.