4 Implementing and Administering WebSphere Business Integration Server V4.2.2
1.1 Overview
In the world of business integration, there is no single solution for all situations.
This is why the IBM WebSphere software platform contains several
complementary technology offerings that provide BI functionality. In this book, we
describe the use of WebSphere Business Integration Server. In addition to
WebSphere MQ itself, which forms the foundation, there are four additional
components to be discussed here:
򐂰 WebSphere MQ Workflow
򐂰 WebSphere InterChange Server
򐂰 WebSphere BI Message Broker
򐂰 WebSphere Business Integration Adapters
These components are packaged together as WebSphere Business Integration
Server in order to give customers the opportunity to choose the best fit for each
of their integration projects.
This redbook is about implementing and managing an integration solution built
upon these four components.
1.2 The evolution of business integration technology
It seems inconceivable today that before the mid-1960s every new generation of
computers changed the programming model so much that effectively all
applications had to be rewritten or were condemned to run in emulation mode,
where available.
The IBM S/360™ computing architecture promised customers for the first time
that future architectures would be backward-compatible so that investments in
software would be protected.
Several diverse architectures exist still, but they have evolved over a period of
time and the issues surrounding the porting of code between them are well
understood, if not completely solved.
Historically, applications were written to solve specific, well-delineated problems.
There was little vision of an application landscape that would cover the whole
range of business requirements, so no need for an integrated architecture was
seen. As a result, solutions would evolve on a great variety of platforms. If and
where integration was needed, it was usually achieved by hosting the
applications on the same system and sharing files. This was no great restriction,
because most applications at that time were batch-oriented and large central
computers (mainframes) were the accepted technology standard. With the
Chapter 1. The state of business integration technology 5
evolution of database management systems, the models surrounding the sharing
of information soon moved to this technology.
Whenever a business identified a need for information to be shared across their
computing platforms, they had to use the networking capabilities of the day,
which were anything but user-friendly. Protocols on all levels were proprietary,
often complex, and usually not well-understood, especially for cross-platform
implementations. Files remained the favorite entities to share, for several
reasons:
򐂰 They had worked well between applications on the same system.
򐂰 Support was available for cross-platform file transfers and file-sharing on
network servers.
򐂰 Above all, most applications were still batch-oriented.
Where online processing had been introduced, businesses found it more
acceptable from risk and system-capacity perspectives to simply collect data
during the online day (in files) and do the actual processing during nightly batch
runs. This mode of operation is still prevalent in businesses.
Occasionally, though, a need for real-time—or near real-time—communication
between two applications on disparate platforms would emerge. This brought
several problems with it:
򐂰 Technology choices had to be made on all levels of network protocols - on
both platforms. (These early solutions used to be strictly point-to-point.)
򐂰 Then the communications functions had to be added to the applications. This
involved highly specialized programming skills, often different on each of the
platforms.
򐂰 The APIs were complex at best and lots of exception handling and recovery
logic was required in the code if there was to be any degree of success.
In a nutshell, such applications were exceedingly expensive to build. They also
took so long to implement that business benefits often were realized too late to
justify the effort.
This is where messaging middleware came in, notably WebSphere MQ. By
providing a simple, easy-to-use API that would hide network complexities from
application programmers, WebSphere MQ made writing communication
functions into application programs much easier and faster. And, because it was
made available on so many different platforms, cross-platform communications
became much easier as well.
Asynchronous communication via queues allowed for loose coupling of systems
and reliability (if queues were kept safe on disks) without compromising the

Get Implementing and Administering WebSphere Business Integration Server V4.2.2 now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.