44 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
The EIS component must do the following:
???? Delegate the back-end integration request to one of its EIS integration
components, using the factory pattern to get a EIS integration component,
where the factory uses the back-end integration style
???? EIS integration components use J2C connectors or a SQL DataSource to get
a connection to the back-end system or database
???? EIS integration components use feature class to create request byte buffers
or SQL Statement objects
???? EIS integration component use the same feature class to parse the response
from the back-end system into a response data object.
Behavioral view
Figure 2-9 illustrates the behavioral view of the conceptual architecture.
Figure 2-9 EIS integration conceptual architecture behavioral view
Using Figure 2-9, we will step through a conceptual business process that must
integration with two different back-end systems. Let’s assume that the business
Local EIS
EIS
EIS
EIS
Remote EIS
EIS
EIS
EIS
Business Processes
System Process (EIS)
Chapter 2. Architecture 45
process must buy stock, and the business process is being called by the ITSO
Trading Firm Internet Trading System application.
For this example the business process must integrate with a back-end system to:
???? Debit an account
???? Reserve the stock purchased
A contextual overview of the complete process could be:
???? The business process is invoked by the Internet Trading System application.
???? The business process must integrate with a back-end system to debit an
account.
The business process does not know where the back-end system is that it
must integrate with, nor does it know which J2C connector is used or how the
byte buffer is created. It only knows that it must integrate with a back-end
system to debit an account. It invokes the EIS system process, passing it a
context string and a request data object. The request data object contains all
the data that is needed as input for the back-end transaction that will debit the
account, such as the account number, an amount, and so on.
???? The EIS system process handles the back-end system integration request. It
references its configuration data and invokes the local EIS component. When
it invokes the EIS component, it passes the following parameters:
– Integration style
– Feature class name
– Request object that the business process provided
???? The EIS component uses a factory to get an EIS integration component,
where the factory uses the back-end integration style to return the correct EIS
integration instance. You could have EIS integration components for:
–J2C-CICS
–J2C-IMS
–JDBC
Potentially, you could have multiple JDBC integration objects or even multiple
J2C-CICS integration objects, if for example you have multiple configured
DataSources or multiple configured J2C CICS resource adapters.
???? The local EIS component delegates the request to the EIS integration
component. The EIS integration components handles the back-end
integration by using a J2C connector or a DataSource, and it uses the feature
class to create the request object and to parse the back-end system response
into a response data object.
???? The business process continues after the successful EIS system process
invocation. (We have not included exception handling and reporting in our
46 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
scenario for the sake of discussing the behavior of the conceptual
architecture.) The business process must now integrate with a back-end
system again to reserve the stock.
Note that the business process is agnostic towards which back-end system it
has to integrate with or which J2C connector is used. It delegates the
back-end integration handling to the same EIS system process.
???? The EIS system process handles the business process request. It references
its configuration source to determine which EIS component must be called.
(Configuration data must also include the back-end integration style and the
EIS feature class name.) In this scenario, the EIS system process must
invoke a remote EIS component.
???? The remote EIS component has been defined for this business context, and
for this example, the remote EIS component has a JMS adapter. All of the
JMS values are defined in the EIS system process configuration.
???? EIS system process calls the remote EIS component using the JMS adapter,
and the remote EIS component handles the EIS system process.
Using a JMS adapter to invoke the remote EIS component enables the EIS
system process to use the benefits of message-based integration:
– Guaranteed message delivery
– Asynchronous messaging
See Chapter 6, “EIS integration using Java Message Service” on page 121
for a detailed discussion about using JMS and message-oriented middleware
(MOM) for back-end integration.
Note: The EIS system process is not aware of any business process rules. Its
main function is to facilitate integration into a back-end system, using a local
or remote EIS component. See Figure 2-10 on page 47 for a logical view of
the EIS component.
Chapter 2. Architecture 47
2.2.6 Logical architecture
The logical architecture view represents a detailed view of the EIS integration
architecture, focusing on the EIS process and the EIS component.
Structural view
Figure 2-10 illustrates the structure for the EIS integration logical architecture.
Figure 2-10 EIS integration logical architecture structural view
Three of our architectural layers are referenced in Figure 2-10:
???? Process
???? Components
???? EIS
See Table 2-1 on page 14 for descriptions of the logical architecture layers.
EIS Service Endpoint
Request Handling
Cache
Security
Response Handling
Interaction Layer
Processing Layer
Process Exception
Handler
Business Delegate
EIS System Process
<<uses>> <<call>>
JDBC
DataSource
JCA
MQ
JCA
IMS
JCA
CICS
MQ
IMS
CICS
JDBC
EIS Integration
EIS Feature
<<uses>>
J2C Connectors
<<uses>>
javax.resource.cci
DataSource
javax.sql.DataSource
<<uses>>
EIS
Business
Delegate
EIS
Integration
Factory
EIS
<<uses>>
<<uses>>
<<uses>>
<<creates>>
Database
CICS/IMS
Processing Layer
Component Layer
EIS Layer
48 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
The EIS system process executes in the process layer, and it is exposed as a
service, using a services-based architecture style. The EIS system process has
a service end-point that exposes the system process as a service or even as an
enterprise service. The next sections discuss the two major architecture
elements of the structural view.
EIS system process
The major architectural elements of the EIS system process include:
???? EIS system process executes in the process layer
???? Exposed as a service, using a services-based architecture and Web services
technologies
???? Service end-point is layered
– Interaction layer
• Request handling
• Response handling
• Security
• Cache
– Processing layer
• Implementation layer of the service end-point
• Implemented using BPEL and Business Process Choreographer
???? Processing layer uses business delegate to delegate processing to the EIS
system process
???? EIS system process has an exception handler to handle any exceptions that
either the EIS system process or any of the local or remote EIS components
can potentially create. This exception handler must handle:
– EIS system process faults
– EIS system process configuration faults
• If the system process cannot find any configuration data for given
business process
• Invalid configuration data or no configuration data
– EIS component errors (local and remote)
• The EIS component can potentially also have J2C connector or JDBC
Connection errors
– General or Catch-All error handling
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.