132 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
finally, send the message using the sender object. Using the JMS API, the
application uses abstract representations of the actual physical destination that
the message has to be sent to. The mapping from JMS destination to actual
physical destination is done by configuration (for example, in the administration
console of the J2EE application server). Optionally, you can provide multiple
send methods at the message bean that are specific for a destination, request
type, or message type you intend to send.
MDB should be used for receiving messages. The interface specification for
MDB includes an onMessage method that is called by the EJB container if a
message arrives. The onMessage typically only includes the mapping of the
message content to a specific request or reply object type or a business object. A
separate session bean should be called for further processing of the message
that runs the business logic. The use of MDBs may require the configuration of
resources in the application server and the EJB container. For WebSphere
Application Server message listeners have to be set up are used to map queues
or topics to the corresponding MDB that is supposed to receive the message.
We recommend that you define the message type according to the data model of
the application, meaning that business objects may be passed via the MOM
infrastructure to the JMS connector on the EIS host. Various alternatives are
available. For example, JMS provides a map-type message format using
name-value pairs. Also, an XML message type can be selected. Another option
is the definition of generalized business objects that include a hierarchical
structure of attributes of name-value pairs.
In context of the EIS integration architecture and design that we presented in the
previous chapters, the sender and the receiver of messages is a business
process. The business process either can be business related (enterprise or
critical business process) or can be of more technical nature (system process).
The process is implemented using BPEL technology and runs on an J2EE
application server that supports deployment and execution of the BPEL
processes. For the business process, sending and receiving messages means
invoking services. Figure 6-4 on page 133 illustrates the system architecture,
including the business processes.
Chapter 6. EIS integration using Java Message Service 133
Figure 6-4 Detailed system architecture for EIS integration using JMS
The BPEL specification caters to communication with MOM by providing specific
elements that allow you to model messaging style interaction patterns. The
BPEL partner link notation binds to task implementations using different
technologies (for example, JMS). The pick activity can be used in a BPEL
process to wait for a message to arrive. Refer to Chapter 9, “Integration into
business processes” on page 241 for more details about business process
management and BPEL.
Both the JMS specification and the BPEL specification of a pick activity provide a
feature that is very useful for a
send and wait for reply interaction pattern. You
can set a time out value for a JMS receiver object and for a pick activity time-out
value, meaning that you specify the maximum time interval you want to wait for a
message to arrive. This setting ensures that applications are blocked only for a
configurable time interval when waiting for a reply message. As soon as the time
has lapsed, the application or the business process can continue (for example,
with error processing).
The JMS connector
The JMS connector is basically an implementation of the JMS API. The
messaging bean and the BPEL engine interact with the JMS connector by calling
J2EE Application
Server
Application Host
EIS Host
Network
EIS
EIS
Component
JMS
Connector
J2EE Application
Server
JMS
Connector
JMS
Service
JMS
Service
System
Process
Business
Process
JMS
Provider
JMS
Provider
J2EE Application
Server
134 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
specific methods on JMS objects as defined in the JMS specification. On the EIS
host, the JMS connector receives messages from the MOM infrastructure and
passes the messages to the EIS system and vice versa.
In the context of our EIS integration architecture, the JMS connector is tightly
coupled with the J2EE application server. The JMS connector is configured via
the administration console of the application server, and it is managed by the
application server runtime. Nevertheless, the JMS connector can also run as
stand-alone component in a J2SE environment, as depicted in Figure 6-3 on
page 130. On the EIS host the JMS connector is not embedded in an application
server.
The advantage of running the JMS connector in a J2SE environment is that there
is no need to install and maintain an application server infrastructure on the EIS
host. A number of EIS host systems are not supported by commercial and open
source application servers, so installation of an application server is not an
option. However, the main drawback of such an architecture is the lack of
application server services at the EIS host. Extended services, such as MDBs,
are not available. Figure 6-4 on page 133 shows our generic approach to EIS
integration in more detail. In this context, the JMS connector runs in the
application server environment.
The JMS provider and the underlying MOM infrastructure
While the JMS connector is the Java enabler for a specific messaging
infrastructure, the JMS provider is the implementation of a MOM infrastructure.
The main features of MOM are described in 6.2, “Message-based EIS
integration” on page 123. This section highlights only two characteristics of
MOM: routing and assured delivery.
Typically, JMS providers have to be installed and configured on the hosts in a
network. Hosts, network, and MOM together built up the messaging
infrastructure. For the applications running on the hosts to send messages to
applications and EIS systems on different hosts, the MOM connections between
the hosts have to be established. WebSphere MQ uses the notation of queue
managers, channels, and clusters that are the basic elements to set up for the
messaging infrastructure. A
queue manager is the endpoint and the control
process of the messaging infrastructure on the host. A
channel is a dedicated
messaging connection between two hosts. A
cluster is a set of queue managers
and queues that build a specific administrative domain.
Having set up and configured these elements, a messaging infrastructure can
have different paths to route a message from its sender to its receiver. Figure 6-3
on page 130 illustrates this setup by the three hosts in the network cloud: MOM
host X can route the message either directly to MOM host Z or can use the path
via MOM host Y. Setting up the routing path is performed by configuration of the
Chapter 6. EIS integration using Java Message Service 135
MOM infrastructure. Thus, the routing of the messages is transparent to the
application.
A message that is sent by an application is supposed to be delivered at the
receiver despite systems and network outages. The MOM must guarantee the
delivery of the messages. For many MOM implementations, delivery is ensured
by two mechanisms:
???? Transactional send and receive
???? Persistent message queues
Messages are typically put on the queues in a transaction. That is, they are either
successfully passed to and from the MOM, or in case of the failure, a rollback is
performed. WebSphere MQ includes an XA resource manager that can interact
with other resource managers (for example, relational databases). So, in case of
failure of passing a message to the MOM, database rollbacks can be performed.
The messages that have been successfully passed to the MOM are made
persistent (for example on the file system of the host). In case of outages of the
MOM infrastructure, components or hosts messages do not get lost. As soon as
the infrastructure component recovers, the MOM sends the messages to their
receiver.
The EIS system
To be enabled for the messaging-based integration style, the EIS system must
be able to send and receive messages from the JMS connector or directly from
the MOM. There are a number of approaches to enable an EIS for messaging.
We focus on two alternatives: extending the EIS for messaging and building an
EIS component.
EIS systems are often built using host technologies (for example, IBM IMS or
IBM CICS transaction monitors). The EIS systems are custom-made applications
that consist of COBOL or PL/I code, libraries, and configuration files. MOM
products, such as WebSphere MQ, provide COBOL bindings so that the EIS
applications can be enabled for messaging by developing COBOL artifacts to
connect to the MOM. Many other EIS systems are written in Java or provide a
Java runtime environment. For those EIS systems, Java message beans can be
developed that interact with the JMS provider on the EIS host (see Figure 6-3 on
page 130).
We recommend the development of an EIS component that contains the
following features:
???? It can be exposed as a service with a JMS binding to participate in a MOM
infrastructure.
???? It is able to process incoming messages, to invoke the appropriate EIS
function, and to return the result by generating a reply message.
136 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
The EIS component, as depicted in Figure 6-4 on page 133, runs in the J2EE
application server. It consists of a set of EJBs and Java utility classes. In
Figure 6-4 on page 133, the application server and the EIS system are running
on the same host. Optionally, the J2EE application server can be installed on a
separate host in case the EIS system host is not a supported platform. A
separate server might also be required if the EIS host is not able to process the
additional workload produced by the application server. Refer to Chapter 3,
“Scenario overview and design” on page 65 and 6.4.1, “The stock trade scenario”
on page 137 for more details.
6.3.4 Extending the building block
The previous sections presented the EIS integration building block by referring to
JMS destinations and WebSphere MQ queues. Besides the point-to-point
interaction pattern, JMS and many MOM products support the publish-subscribe
interaction pattern. With a publish-subscribe method, a message sender
broadcasts messages to a set of receivers. The potential receiver subscribes to a
specific topic to receive the messages. Instead of using destinations for the
sender to locate the message receiver, the sender passes the message to JMS
and the MOM by specifying a topic. Using this pattern, the application can send
messages to many receivers simultaneously with just one JMS interaction. The
MOM, not the application, is in charge of delivering the message to all interested
receivers.
Transformation of data is a core requirement for EIS integration. With the
integration using JMS, transformation from the application data model to the EIS
data model is performed close to the EIS in the EIS-specific message enabler (in
our approach, in the EIS component). Across the application and the messaging
infrastructure, the data model of the application domain is used. For many
reasons, introducing a broker component is an advantage that builds a central
hub in the messaging infrastructure (see 6.2.3, “Hub-and-spoke integration
pattern” on page 126). The broker is in charge of routing of messages to
potential receivers and may also be used to transform the message from the
application domain model to the EIS system data model.
This traditional EAI style was mainly introduced to reduce complexity for
integration problems. In addition, broker implementations such as WebSphere
Business Integration Message Broker provide a comprehensive and powerful
framework for message transformation. Although this book does not cover
complex integration problems, extending the messaging infrastructure with a
broker might be of advantage because of its data transformation capabilities. For
example, EIS systems may require the generation and parsing of EDI
documents, because their data model relies on the EDI standard. WebSphere
Business Integration Message Broker supports EDI parsing and EDI document
generation, and reuse of those capabilities might be of advantage.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.