160 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
6.5 Qualities of service for integration using JMS
The first sections of this chapter discussed the functional characteristics of MOM.
Qualities of service refers to the non-functional requirements on a messaging
infrastructure.
The basic non-functional requirements such as security, high-availability, and
performance are addressed in various publications and redbooks. This section
focuses on transactions in a mixed application server and messaging
environment. Furthermore, it discusses management and problem determination
in a complex messaging infrastructure.
6.5.1 Transactions
Business processes that are implemented in new composite applications and
that integrate with legacy EIS systems often require transactional behavior
across all components and systems. For instance, in our trading firm scenario,
the debit of the customer’s account and the ordering request and its confirmation
are tightly coupled. If the ordering request fails, the debit must be rolled back,
because customers typically complain if their account is debited although no
stock is added to their portfolio.
From a business perspective, the sending of the request message from the
business process, the transport of the message over the network, the invocation
of the business process, and the sending and receiving of the confirmation
message must form a single transaction. From a technical perspective, the
requirement results in a distributed transaction across business process,
integration components, and EIS system. Although distributed transactions
involving physically remote systems are technically possible, a number of issues
are related to this approach. Among others, performance of distributed
transactions over a network is often poor because of the complex interaction
patterns that are required (for example, for the XA protocol).
A better solution is provided by MOM. The overall transaction scope is split into
multiple transactions of smaller scope. Figure 6-14 on page 161 depicts the
logical architecture of the integration building block that uses JMS including the
MOM. The basic idea is to rely on the MOM’s ability to guarantee the delivery of
a message once it is handed over to the MOM. This characteristic, often referred
to as
assured delivery, allows you to split the actual technical transaction into
three separate transactions of local scope. Hand-over of the message from
application server to the MOM is the first transaction, delivering the message to
the application server on the EIS host and sending the reply back to the MOM is
the second, and finally, another transaction is required to receive the reply in the
application server.
Chapter 6. EIS integration using Java Message Service 161
Figure 6-14 Transactions in a mixed application server - MOM environment
Figure 6-14 visualizes the transactional scope with the red circles. On the
application host, the transaction comprises the system process, the JMS service,
the JMS connector, and the JMS provider. On the EIS host, JMS provider, JMS
connector, and the EIS component are involved in the transaction. This
transaction also includes the EIS system, if the technology to call the EIS system
functions supports transactions. In the Trader scenario, the IMS function is called
using the J2C-compliant IMS connector that supports XA transactions.
Chapter 9, “Integration into business processes” on page 241 addresses the
transactional characteristics of the BPEL business process and the JMS
components on the application host.
On the EIS side, the EIS component is a J2EE component consisting of EJBs
that are deployed on WebSphere Application Server. The application server,
WebSphere MQ, the J2C IMS connector, and the IMS subsystem on the zSeries
host support XA transactions. That is, their transaction managers are able to
interact with the WebSphere transaction coordinator to assure a distributed
transaction across these components.
To enable the EIS component for transactions, the following settings and
activities are required:
???? The JMS queue connection factory that is used for the JMS listener port of the
MDB has to be enabled for XA transactions by checkmarking the XA enable
option.
J2EE Application
Server
Application Host
JMS
Service
System
Process
JMS
Provider
JMS
Connector
J2EE Application Server
Transactional Scope
Host
Y
Host
X
Host
Z
Network
J2EE Application
Server
EIS Host
EIS
Component
JMS
Provider
MDB
JMS
Connector
MOM-Enabled
Transactional Scope
J2EE Application Server
162 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
???? For the EIS component session beans, the transaction type of the methods
has to be set correctly (Supports, Required).
???? The JCA IMS connector supports XA transactions out-of the-box but ensures
that the IMS connect and IMS subsystem on the zSeries host are enabled to
participate in a XA transaction.
If a confirmation message is required for the calling business process, the sender
bean that creates and puts the message on the reply queue also has to be
enabled to participate in the transaction by setting the appropriate transaction
type.
In case of failures and system outages, the WebSphere transaction coordinator
rolls the transaction back and the message is not deleted from the WebSphere
MQ queue. If WebSphere itself fails while a transaction is in-flight, the transaction
continues as soon as the application server recovers. The IMS Connect and the
IMS system, however, do not always rollback or recover the transactions
correctly. We have encountered situations where manual interaction on the IMS
side was required if transactions failed.
To be able to resolve these issues, detailed information about the messages
received and processed in the EIS component is needed. Therefore, a powerful
and reliable logging and audit mechanism across the application server and
messaging infrastructure is useful. We discuss this requirement in 6.5.2,
“Problem determination and resolution” on page 162.
6.5.2 Problem determination and resolution
WebSphere Application Server and WebSphere MQ log relevant events and
exceptions in log files on the hosts. We also recommend that all application
artifacts, such as business processes and EJBs log activities, messages, and
exceptions, generate log events or log messages. To detect problems and to
identify the probable cause for failures, the WebSphere Administrative Console
provides functions to visualize and analyze the log files.
The WebSphere Administrative Console provides the single entry point to a
WebSphere cluster. For the integration building block using JMS, however, the
application host and the EIS host typically belong to separate WebSphere
clusters. Problem detection and resolution can become cumbersome if many
different log files on separate host systems have to be checked.
Chapter 6. EIS integration using Java Message Service 163
Figure 6-15 Logging mechanism in complex messaging environment
To facilitate problem determination and resolution in the complex environment,
we recommend that you establish a common policy and procedure for logging
and auditing of activities and exceptions. To provide a single view of all activities
performed and messages delivered in a distributed environment, a staged log
mechanism can be implemented. Figure 6-15 shows the environment for staged
logging in a mixed application server and MOM environment.
At the first stage, log messages are recorded in log data stores at the physical
node the corresponding software component is running on. The data store can
be a flat file, but also a database or a persistent message queue can be used to
store the logs.
At a second stage, all log events are extracted from the log data stores of the
physical nodes. Log events extracted can include messages that are delivered
by the MOM infrastructure and that provide detailed information about how
requests have been processed in the application and EIS component. The
extraction mechanism can be based on scripts running at customizable time
intervals or can run continuously in parallel to first stage logging. The extracted
Logging Host
Log and Audit
Data Warehouse
J2EE
Application
Server
JMS
Provider
Application Host
J2EE
Application
Server
JMS
Provider
EIS
Log
Extraction
and
Archiving
Log
Extraction
and
Archiving
EIS Host
164 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
events can be stored in a central data warehouse. Sophisticated analysis can be
performed on the database. For example, log events for all messages related to
a specific application request can be combined and analyzed together.
The main reason for introducing a staged approach rather than setting up a
central log datastore is that log events are available on each node independent
of the availability of the centralized log service. Particularly, detection and
resolving of failures is still possible even if the system affected is disconnected
from all other infrastructure components.
In WebSphere Business Integration Server Foundation the WebSphere Common
Event Infrastructure (CEI) recently became available. WebSphere CEI is an
implementation of a consistent, unified framework for the creation, transmission,
persistence, and distribution of a wide range of business events, such as log and
audit messages. CEI is based on the Common Base Event (CBE) format which
was proposed as a new standard to the Organization for the Advancement of
Structured Information Standards (OASIS). Although we have not attempted to
include WebSphere CEI into the design presented in this chapter, we
recommend that you evaluate its use for real environments.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.