Chapter 6. EIS integration using Java Message Service 137
In our approach, the JMS-enabled EIS component is in charge of data
transformation. From an EAI perspective, the EIS component can be regarded
as an adapter. WebSphere Business Integration Adapters are implementations
of traditional EAI adapters that are JMS- and MOM-enabled and include data
transformation capabilities. Specific adapters are available for many EIS
systems. Refer to Chapter 8, “Integration using WebSphere Business Integration
Adapters” on page 199 for more details about how adapters can be used in our
context.
6.4 Develop EIS integration using JMS
This section focuses on implementing the integration building block using JMS. It
describes how we created the artifacts using WebSphere Studio Application
Developer Integration Edition. We developed the design of the building block
using the UML tools of Rational XDE Developer.
6.4.1 The stock trade scenario
In the stock trade scenario described in Chapter 3, “Scenario overview and
design” on page 65, the stock broker that processes the sell or buy stock request
belongs to a separate organizational unit. The stock broker implements a
business process for stock ordering and exposes this business process as a
service that is used by the ITSO Trading Firm. You can find a more detailed
description of the business processes and their implementation in Chapter 3,
“Scenario overview and design” on page 65 and in Chapter 9, “Integration into
business processes” on page 241.
The stock broker business process itself uses the Trader service to actually
process the buy and sell transaction. The transactions are executed in an IMS
environment on a zSeries® host.
Figure 6-5 on page 138 depicts the Trader service and the components behind it.
The Trader system process exposes the Trader service. This system process
uses the Trader EIS service that is exposed by the Trader EIS component. The
Trader EIS component in turn connects to the IMS system and invokes the IMS
stock order transaction.
138 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
Figure 6-5 Component model for Stock Broker EIS integration
The system process was introduced to de-couple the business process from
technical details of the EIS service implementation, that means no EIS service
should be directly called from a business process. In the stock trade scenario,
the Trader system process has basically three tasks to fulfill:
1. Validate the service request by checking context and business object that are
passed.
2. Decide which service to call, either directly call an EIS service or route
through the EIS component.
3. Log the request for auditing purposes.
Figure 6-6 on page 139 shows the activity diagram describing the system
process. The first activity in the process is the validation of the request data and
the final activity is the logging for audits. The core of the process is the decision
of which EIS service to invoke. Based on context information, a decision is made
whether to call the EIS service directly or to call the EIS component. The actual
decision criteria is the location of the EIS system. If the system is located in the
same data center, the service is called directly and data transformations have to
be performed before and after the service invocation. If the EIS system is
remote, then the system process calls the EIS component that is located close to
the EIS system. Here, the integration building block using JMS is used and the
Trader EIS service is invoked via JMS and the MOM infrastructure.
Data transformations are required if the EIS service is called directly because the
system process and its service interface operate on business objects. In the
stock trade scenario, the Trader system process receives a StockOrder business
Trader EIS ComponentTrader System Process
IMS
Tr a de r EI S Ser v iceTr a de r Se r v ice
«reside» «reside»
Chapter 6. EIS integration using Java Message Service 139
object. This object would have to be transformed into the data object required by
the EIS service.
Figure 6-6 Trader system process
The EIS component, however, also operates on business objects. So, the Trader
systems process can pass the StockOrder object to the Trader EIS component.
The EIS component transforms the business object to the data format that the
called EIS system requires.
Besides data transformation, the EIS component invokes the appropriate EIS
function. In our scenario, the function is an IMS transaction. IMS systems are
accessed from J2EE or J2SE environments by using a J2C-compliant IMS
connector. Running the J2C connector in a J2EE environment is of advantage
because the J2EE application server is able to manage the connection to the
back end. For instance, reuse of connections is supported by a connection pool
that is set up by the application server. We recommend that you deploy the EIS
component in an J2EE environment, except for testing purposes. In this
situation, the component has to be implemented as EJB application.
Figure 6-7 on page 140 shows the design of the Trader EIS component. Although
we have focused only on the stock order use case, the EIS component has been
designed according to our approach for back-end integration. In particular, we
have implemented the feature pattern. A EIS integration feature comprises all
artifacts that are required to enable access to a function of the EIS system (for
Star t En d
Audit Request
Invoke Trader EIS Ser vice
Invoke Stock Broker
Service
Set Request Data Transform Result
Validate Request
Local or Remote
?
Merge
[ Remote]
[ Local]
140 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
example, an IMS transaction). In the class diagram, the feature is represented by
the session bean TraderEISFeatureBean that implements the feature interface.
The feature can also include various utility classes (for example, for data
transformation).
Figure 6-7 Class diagram for Trader EIS component
The feature interface specifies three methods that the TraderIMSFeature bean
implements:
???? setInput(), used to set the request data by passing a business object
???? getOutput(), used to receive the result in form of a business object
???? runTransaction(), used to invoke the EIS function
For our rather simple use case, we have defined the StockOrderBO business
object with attributes for the account of the client, the stock to purchase, and the
quantity. The input for the TraderIMS feature is the StockOrderRequest object,
«EJBSessionBean»
TraderIntegrationBean
+ «EJBCreate,EJBRemoteMethod» ejbCreate ( )
+ «EJBBusiness,EJBRemoteMethod» invoke ( )
«EJBSessionBean»
TraderIMSFeatureBean
+ «EJBCreate,EJBRemoteMethod» ej bCreate ( )
+ «EJBBusiness» setInput ( )
+ «EJBBusiness» getOutput ( )
+ «EJBBusiness» runTransaction ( )
StockOrderRequest
+ Context : java.lang.String
St ockOrderConfirmat ion
+ Message : java.lang.String
«interface»
Fe a t u r e
+ setInput ( )
+ getOutput ( )
+ runTransaction ( )
St ockOrderBO
+ Account : java.lang.String
+ Stock : java.lang.String
+ Quantity : int
- StockOrderB
O
1
- StockOrderB
O
1
Chapter 6. EIS integration using Java Message Service 141
including the business object and context information. Output is defined by the
StockOrderConfirmation business object and a confirmation message.
The TraderIMSFeature is the only feature we have designed, but in real
environments, many features are available in an EIS component. To provide an
interface to the feature set, we defined the session bean TraderIntegrationBean.
In our scenario, the bean implements an invoke method and is exposed as a
service, the Trader EIS service.
In our case, the invoke method calls the TraderIMSFeature methods directly. The
advantages of the feature pattern become apparent if the TraderIntegration
session bean is extended to include a more sophisticated method of calling a
feature. If you call directly and a new feature is added, you have to touch the
TraderIntegration bean. To avoid this situation and to enable the
TraderIntegration bean to call the new features as they are added, we
recommend that you implement a configuration mechanism so that new features
are registered at the TraderIntegration bean and so that the features are called
by using the interface methods.
The implementation of the Trader EIS component is described in detail in 6.4.2,
“Creating the EIS component” on page 141. For more details about how to create
the system process, refer to Chapter 9, “Integration into business processes” on
page 241.
6.4.2 Creating the EIS component
This section explains how to build the EIS component. First, it describes how to
set up the project environment on WebSphere Studio Application Developer
Integration Edition. Then, it shows how to generate Java utility classes for
accessing the IMS system. Finally, it describes the implementation of the
TraderIMS feature and the TraderIntegration session bean.
Creating the EIS component project
When you start WebSphere Studio Application Developer Integration Edition, the
default perspective that is shown is Business Integration. This perspective, and
the J2EE and the Server perspective, provide the tools that we used in our
development process.
If you start with an empty workspace, you might wish to set preferences first. To
set preferences:
1. Select Window
→ Preferences to open the preferences editor.
We recommend that you enable server targeting because it allows you to
choose the application server type and version for the projects and artifacts
that you create.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.