10 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
2.1 Integrating a remote EIS
Most companies today have some sort of a back-end EIS that processes
business transactions and maintains business data in a database. Examples of a
corporate EIS are:
???? Enterprise Resource Planning (ERP) systems (for example, SAP)
???? A CICS and IMS system running business transactions
???? A corporate database running SQL stored procedures
???? A corporate database storing company data
???? A combination of some or all of these scenarios
To further complicate the integration for architects and designers, any or all of the
enterprise information systems can be either:
???? Remote
The back-end system is geographically remote to the application or business
processes integrating with the back-end system. An example of such a
scenario is where an application server is running an application in Minsk,
Belarus, and the back-end system that processes the transactions is in
Johannesburg, South Africa. In this scenario, where a back-end system is
remote to an application or business process, the back-end typically would be
accessed over a wide area network (WAN) or over the Internet.
???? Local
The back-end system is located on the same local area network (LAN) as the
application or business processes.
???? External
A remote back-end system where an application or business process must
integrate with an external company’s back-end system. An example of this
scenario would be an external company that provides a stock portfolio
analysis service.
Why is it so difficult for IT developers and project teams to integrate with
back-end systems? From a conceptual point of view, you can architecturally
model two systems with defined boundaries, layers, and interfaces. So,
conceptually a Web application that is running a company’s call center should be
able to integrate with its back-end system effortlessly, correct?
Well, conceptually, yes. However, if you analyze the two systems, you would find
that the company’s call center was implemented using a proprietary language or
tool set, while the back-end was implemented with another language (for
example CICS / COBOL). There are almost an infinite amount of EIS integration
scenarios.
Chapter 2. Architecture 11
Developers have different skills and levels of experience. When you start on a
new project (or even a maintenance project), depending on how your
organization structures and staffs new projects, you can end up with a project
team of mixed levels of experience and technical skills. You might have a few
good J2EE developers, but the back-end system that you need to integrate with,
was (or is being) developed using CICS / COBOL. Usually, it will be a case of the
application and processing layers being developed in one language and tool set
other than the back-end system transactions. You then have developers sitting
on different sides of the fence, talking different languages to describe their
interfaces.
For example, lets say the Java developer needs to send a field that represents
an amount to the back-end system. Typically the Java developer will use a Java
type such as BigDecimal to represent the amount and will define the same
amount field in a COBOL copy book as a S9(13)V99 COMP-3 field. Translating
from a Java BigDecimal type to a COBOL S9(13)V99 COMP-3 type is not an easy
task. The challenge for developers here is really how to create a request that
meets the contract definition of the EIS (a request record) and how to parse the
response from the EIS (a response record) into an object or component that the
application or business process can handle. At the same time, you must consider
how you will connect to the back-end system. In addition, you should consider
quality-of-service issues such as transaction management, security, and
connection pooling.
Fortunately, specifications and technologies exist that help with back-end
integration requirements. However, using technologies or development tool sets
alone just for the sake of solving back-end integration challenges might not
adhere to your organization’s IT standards and principles. In addition, it probably
will not meet the expectations of your business unit or customers in the long run.
There are many issues to consider before you start plugging in the available
technology options. Some of the issues are known, and some you will probably
discover as you start unit and integration testing with back-end transactions. For
example, have you thought about what impact versioning will have on your
applications and business processes when you start re-factoring the interfaces of
your back-end transactions? In reality, business requirements do change,
sometimes as late as the testing phase. If you are on the critical-path of a project
and you need to change back-end transactions, then you want to have a
back-end integration solution that can handle these type of changes with minimal
impact.
12 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
Consider the skill level of your project team, standards and principles of your IT
organization, and last but not least, expectations from your business units or
customers. If you do not have an architecture for your back-end integration
solution, then your development (or maintenance) project might not adhere to
your organization’s or customers’ IT standards and principles and might not meet
the expectations of your business unit.
2.1.1 Levels of EIS integration
Architects and designers have designed and successfully implemented different
back-end integration solutions for many years. Chances are good that there are
still production systems running in many companies today that integrate with a
back-end system that is running CICS / COBOL, through SNA, using APPC. In
these environments, it is likely that the company has created a framework for
their back-end integration requirements. A common approach used by such
frameworks is to create a request record and to parse a response record using
connection management.
The way that applications were architected, designed, and constructed in the
past (the “client/server era”) is quite different from how we perform those tasks in
the era of the Web. Even now, when we talk about on demand computing and
creating composite applications using services-based architecture styles, our
architectures, designs, and implementations probably will be quite different in the
future.
There are three different levels of back-end systems integration:
???? Applications directly to a back-end system
???? Applications to a EIS integration component and service
???? Applications to a EIS system process
Figure 2-1 on page 13 illustrates these three levels.
Chapter 2. Architecture 13
Figure 2-1 Levels of EIS integration
Logical architecture layers
The architecture layers in Figure 2-1 illustrate the different levels of back-end
system integrations. These architecture layers represents a logical view of an
enterprise’s layered architecture. We acknowledge that every enterprise
probably has its own layered architecture that adheres to its own naming
standards and the principles of its IT department. These logical layers represents
a general (or abstract) view for discussion and illustration of the different levels of
back-end integration. Most enterprises probably have many channels or
business units. Often, you will find that channels have implemented their own
applications, using their own EIS integration frameworks, patterns, and
components.
Illustrates that components are exposed as services
Illustrates an interface
Presentation
Application
Presentation
Process
Presentation
EIS
Presentation
Components
Logical Architecture Layers
Level 1
Level 2
Level 3
Presentation
Presentation
14 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
The levels of EIS integration should not be seen as levels of maturity or technical
capabilities of any particular organization. The levels illustrate the different styles
for EIS integration and set the scene for the architecture that we propose in this
redbook.
Table 2-1 gives a description for the logical layers that the diagrams in this
redbook use.
Table 2-1 EIS integration architecture layer descriptions
Level 1, application to EIS
Before the J2C specification was created many project teams used the Common
Connector Framework (CCF) from IBM to integrate with back-end systems. In
some instances, developers created their own legacy frameworks using sockets
and proprietary protocols between their applications and a corporate back-end
system.
Layer Description
Application Represents the business-facing solution which consumes
services from one or more providers and integrates those
solutions into the application- or channel-specific business
processes or presentations.
Process Where enterprise business processes are exposed as
services that can be used by applications or other enterprise
business processes. Enterprise processes are exposed using
a service-based architecture style. The process layer can
contain:
???? Enterprise business processes
– Create and maintain customer
– Buy and sell stock
– And so on
???? System processes
– EIS connectivity process
– Security service
???? Utility processes
Components The various components that support the implemented
processes, the business objects, and their implementations.
EIS Back-end data processing or transactions systems.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.