Chapter 2. Architecture 19
In this scenario, the same EIS system process gets invoked for every back-end
integration or transaction. Instead of the application, or in this scenario, the
business process, calling a service-enabled J2C connector explicitly from the
critical business process, it delegates the back-end integration handling to
another system process. It is the responsibility of this system process to facilitate
back-end integration to any back-end system for all applications or critical
business processes.
Notice that the business processes are themselves exposed as services and that
the EIS component is also exposed as a service. This architecture is discussed
in detail in 2.2, “Architecture discussion and best practices” on page 19.
Table 2-4 lists the benefits and drawbacks of EIS integration at level 3.
Table 2-4 Benefits and drawbacks of EIS integration at level 3
2.2 Architecture discussion and best practices
This section discusses the architecture for the ITSO Trading Firm. See
Chapter 3, “Scenario overview and design” on page 65 for a detailed discussion
of the ITSO Trading Firm use cases and scenarios.
2.2.1 Architecture challenges
Every architect or designer, when challenged with a new business problem, will
try to create an architecture that adheres to common architecture principles,
such as extensibility, stability, scalability, portability, flexibility, and so on. One can
argue that the architects of a high-rise building must consider possible disaster
scenarios such as earthquakes, high winds, thunderstorms, and so on. Likewise,
Benefits Drawbacks
There is an increasingly graphical,
declarative development approach.
Enterprise services and processes require
organizational changes to process,
architecture, and infrastructure.
It is driven by business process. It is difficult to define ownership of the EIS
system process.
The EIS integration process is completely
abstracted from business process.
There is a dictatorship in that all channels
must use the EIS system process.
There is a shift to an on demand operating
environment by virtualizing the back-end
implementations.
There is a reduced effort to code.
20 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
software architects attempt to design a robust software system that not only
exceeds the business expectations but that also adheres to architecture and
software design principles.
Imagine for a moment that you are an architect of a high rise building in
downtown Johannesburg, South Africa. What are some of the challenges you
face? In this location, there are natural challenges, such as earthquakes,
thunderstorms, and high winds, as well as man-made challenges, such as
adequate parking and access to the building. As the architect, you must consider
all the challenges in your final blue print. Software architects should apply the
same theory when designing new software systems.
As discussed in previous sections of this chapter (see 2.1, “Integrating a remote
EIS” on page 10), back-end system integration can be very complex. Back-end
system integration presents its own set of unique, and common, architectural
issues that must be considered when creating a software solution that exceeds
business expectations while at the same time adhering to IT principles.
Wide area network (WAN)
The application or business process that must integrate with a back-end system
can be physically remote from the back-end. (See 2.1, “Integrating a remote EIS”
on page 10 for descriptions of local, remote, and external back-end systems.)
When your application must integrate with a back-end system over the WAN, you
have to consider the available bandwidth.
For example, if your available bandwidth is 64 KB and you share SNA and IP
traffic over the same physical infrastructure, then you would definitely want to
consider using compression between your application and the back-end system.
The fact that you maybe have a 256 KB, or even 1 MB, link available between
your application and the back-end system should not mean that you can push
XML documents over the WAN.
Consider, for example, that over time the volume and concurrency of
transactions to the back-end system might increase. You might have designed
elegant solutions on the application and back-end integration layers. However,
the WAN might void all that effort if it cannot handle the volume.
Suggestion: Consider designing a back-end integration solution where you
can declaratively enable or disable data compression to a back-end system
over the network. For example, using the J2C CICS connector, you can
specify security classes. These classes can handle the compression of
requests to the back-end system and the decompression of responses from
the back-end. Figure 2-4 illustrates how to configure J2C CICS connector
security classes that are used for data compression.
Chapter 2. Architecture 21
Figure 2-4 Defining J2C CICS connector security classes for compression
Transaction management
A key service that is required for robust server-side development is transactions.
Transactions, when used properly, can make your mission-critical operations run
predictably in an enterprise environment. Transactions are an advanced
programming paradigm that allow you to write robust code. Transactions are also
very useful constructs to use when performing persistent operations, such as
updates to a database.
Distributing your application or business processes across the network
introduces failure and reliability concerns. For example, what happens if the
network crashes during a banking operation? Typically, an exception will be
generated and thrown back to the client code. However, this exception is quite
ambiguous in nature. The network may have failed before money was withdrawn
from an account. It is also possible that the network failed after the withdrawal.
There is no way to distinguish between these two cases. All the client code sees
is a network failure exception. Thus, we can never know for sure how much
money is in the bank account.
22 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
In fact, the network may not be the only source of problems. Because we're
dealing with bank account data, we are dealing with persistent information that
resides in a database. It is entirely feasible that the database itself could crash.
The machine on which the database is deployed could also crash. If a crash
occurs during a database write, then the database could be in an inconsistent,
corrupted state.
For a mission-critical enterprise application, none of these situations is
acceptable. Mainframe systems and other highly available systems offer
preventive measures to avoid system crashes. In reality, however, nothing is
perfect. Machines, processes, or networks will always fail. There needs to be a
recovery process that can handle these crashes.
In 2.1.1, “Levels of EIS integration” on page 12, we discuss the different levels of
EIS integration and, in particular, focus on level 3 integration where the
application or business processes use an EIS system processes for all of its
back-end integration requirements. In the domain of processes, or more
specifically BPEL and Business Process Choreographer, transactional behavior
depends on the interoperability of the process. (See 2.3, “Key technologies” on
page 58 for definitions of BPEL and Business Process Choreographer.)
Non-interruptible processes execute within a single transaction. In contrast, each
activity within an interruptible process can have its transactional behavior set. In
either case, if a failure is detected, the current uncommitted transaction is rolled
back, and any pending compensation activities are applied.
Interoperability
A major benefit of Web services is interoperability between heterogeneous
platforms. To get the maximum benefit, you want to design your services to be
interoperable with clients on any platform. The Web Services Interoperability
(WS-I) organization helps in this regard. WS-I promotes a set of generic
protocols for the interoperable exchange of messages between Web services.
The WS-I basic profile promotes interoperability by defining and recommending
how a set of core Web services specifications and standards (including SOAP,
WSDL, UDDI, and XML) can be used for developing interoperable Web services.
Using Web services does not imply that you will achieve interoperability by
default. For example, if your EIS system process is exposed as an enterprise
service, then you must consider that consumers of your EIS system service can
run on a .NET platform, or even a Siebel or SAP system for that matter. Your
development tool set, such as WebSphere Studio Application Developer
Integration Edition, has the ability to generate services that are WS-I compliant,
but it can also generate service bindings that are not supported by the WS-I
Chapter 2. Architecture 23
basic profile 1.0 specification. For further information about WS-I Basic Profiles,
see:
http://www.ws-i.org
Parameters for Web service calls can be standard Java types and objects.
However, the type of the parameter that you use has a significant effect on the
portability and interoperability of your service. Specifically, be careful when
passing XML documents as parameters. Because of portability limitations, you
should avoid passing parameters that require the use of vendor-specific
serializers or deserializers.
Versioning
You must include support for versioning in your back-end system architecture
from the beginning. You do not want to re-factor your design or implementation,
or worst case scenario your architecture, to support versioning after you have
deployed your system into production. You want to be able to plug-in
(programmatically or declaratively) new versions of components, new versions of
EIS connectors, and new feature classes (see “EIS integration feature classes”
on page 40 for a discussion on feature classes).
You also want to be able to integrate with new versions of CICS / COBOL
copybooks, while at the same time still supporting older versions. This scenario
typically occurs when you want to introduce a new release to an application or
process, while the remainder of the production applications continue to use the
older version. When you have an enterprise service, then all of your channels
use that service, or viewed differently, all of your enterprise business processes
use your EIS system service. By changing that service, you risk affecting your
service level agreements.
If you pilot a change in your EIS system process to a specific business process
or channel application, you can minimize that risk. However, doing so means that
you have to consider building versioning support into your architecture. When
you introduce new changes or extensions to your applications or critical business
processes, you would probably pilot the new release to a selected group of
channels, applications, branches, users, or the requirements you have from your
business units or customers. Because all channel applications can potentially
call the same critical business processes, you must build support for versioning
into your EIS system process. This support caters to the piloting and rollout
scenarios where you do not have a big-bang approach when you introduce
changes into a production environment.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.