Chapter 2. Architecture 29
describing your enterprise customer? How complete is the data model that
describes the business units and operations in your organization?
If you do not have an enterprise domain object model, then you should consider
using a generic data object to pass data between your EIS system process and
your EIS component. Figure 2-6 shows a class diagram of such a generic data
object, with a helper class to manipulate the object data elements.
Figure 2-6 Generic EIS integration data objects
30 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
2.2.2 Architecture options
Decomposing the back-end integration system into smaller building blocks
presents some architectural options that we need to decide on before we present
the final blue print of the architecture to the designers. Here are some of the
options we have in context to an EIS integration level 3:
???? Expose every back-end transaction (for example, every CICS / COBOL
routine) as a J2C service
– One to many J2C services, depending on the number of back-end
transactions you have, a service for every back-end transaction
???? Use an EIS component framework with feature classes for every back-end
transaction
– Only one EIS component (that is exposed as a service) with one to many
feature classes, a feature class for every back-end transaction
See “Level 3, application to EIS system process” on page 16 for a discussion on
this level of back-end system integration.
Figure 2-7 illustrates the architecture options.
Figure 2-7 EIS integration architecture options
EIS System Process
Option 1
EIS
Option 2
J2C Connectors
Feature
Feature
Feature
Feature
Feature
.
.
.
.
.
.
.
.
.
.
.
. . . . .
Represents one to many
J2C
J2C
Chapter 2. Architecture 31
Benefits and drawbacks of the two architecture options
Table 2-5 and Table 2-6 on page 32 list the benefits and drawbacks for the
following architecture options:
???? Option 1: many J2C services, a service for every back-end transaction
???? Option 2: an EIS component framework that uses feature classes, one EIS
component service with many feature classes
Table 2-5 EIS integration option 1: many J2C connector services
Benefits Drawbacks
Excellent development tools support in
WebSphere Studio Application Developer
Integration Edition.
Potential to end up with J2C services for
every back-end transaction. Difficult to
maintain in a development environment
with developers of different skills and
levels of experience.
Depending on the developer’s (or project
team) experience and skill level, it is
relatively easy to expose a back-end
transaction as a J2C service. The steps to
create the J2C service are well
documented and easy to follow (see
Chapter 3: Building CICS ECI enterprise
services in the IBM Redbook Exploring
WebSphere Studio Application Developer
Integration Edition V5, SG24-6200).
Generated services result in many
artifacts being created in the development
workspace that must be managed,
maintained, and placed in source control.
Principles of SOA:
• Technology neutral: endpoint
platform independence
• Standardized: standards-based
protocols
• Consumable: enabling automated
discovery and usage
• Reusable: use of service, not reuse
copying of code and implementation
• Abstracted: service is abstracted
away from the implementation
Skill set of developers. The tool support is
excellent, and it abstracts a lot of the Web
services technologies from the
developers. However, developers can
potentially introduce a new set of
problems when re-factoring the original
service definition and implementations
(WSDL files, classes, projects, and so on).
Increased separation between consumers
and providers.
Not a formalized structured development
framework that facilitates a disciplined
development environment for developers
and project teams, across all channels in
the enterprise.
32 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
Table 2-6 EIS integration option 2: EIS component framework and feature classes
Ability to map messages (including parts
of the request and response message)
graphically or by using development tools
such as WebSphere Studio Application
Developer Integration Edition. For
example, if the process that you have
created graphically invokes a J2C service,
then you can graphically map the request
and the response (that is, map from a
business process variable to the J2C
service variable).
The possibility exists that your
organization can end up with hundreds or
even thousands of J2C services for every
back-end transaction. This scenario can
create maintenance and management
problems on another layer using another
technology.
There is maintenance of exposed J2C
services when back-end transaction
contracts change (for example, changing
a COBOL copy book).
Creates a false sense of security that the
tool set does everything. In reality,
production systems, including the
back-end transactions, are dynamic (new
business requirements) and complex
(COBOL copybook re-defines).
Benefits Drawbacks
Component-based architecture. Proprietary framework that developers
have to learn. (Although one can argue
that creating implementations using a
concrete framework requires very little
understanding and learning from
developers.)
Framework creating a disciplined
development environment for developers
(managing risk of in-experienced
developers or project teams).
EIS component requires effort to analyze,
design, and construct. Benefits are
realized only after the EIS component has
been created.
Benefits Drawbacks
Chapter 2. Architecture 33
The architecture for our back-end integration uses option 2 (EIS system process
using EIS component framework and feature classes).
2.2.3 Components and SOA
One of the most important principles of SOA, and possibly the most widely
misunderstood, is that of loose coupling. Today, development productivity is no
longer the number one concern of IT management. This fact means either that
the original software crisis has been fixed or that it has simply been overtaken by
a new, more serious crisis — the crisis of adaptability. The crisis of adaptability
moves the priority away from new development to integration and reuse.
Table 2-7 and Table 2-8 on page 34 show the potential benefits and drawbacks of
components without and with SOA.
Table 2-7 Components without SOA
Fewer artifacts (such as WSDL files,
classes, deployment-descriptors,
projects, and so on) that must be created
and maintained. Only one feature class
per back-end transaction.
The possibility exists that custom mappers
classes might have to be created to map
request messages to the EIS system
process and response messages from the
EIS system process. For example, a
business process variable, or parts
thereof, must be mapped into either a
general data object or another type of
object (variable) for the EIS system
process. You might have to code this
mapping in Java code (using a Java
snippet), as opposed to using graphical
mapping capabilities when graphically
composing a process.
Maintains the benefits of SOA but with
components (see“Components with SOA”
on page 34).
Greater flexibility to change back-end
integration. The EIS component can
declaratively use a different J2C
connector (for example, if a back-end
transaction was changed from an IMS
transaction to a JDBC stored procedure).
Benefits Drawbacks
Potential benefits Potential drawbacks
Economics of scale achieved from reusing
available components.
Components are permanently assembled
into applications. It is easier to plug-in than
to unplug.
Software solutions are developed rapidly
from existing components.
Lack of post implementation flexibility.
Choice of different components yields
some pre-implementation flexibility.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.