Redpaper

Martin Keen
Stuart Jones

Case Study: Service Connectivity

SOA Scenario

This paper is one in a series of service-oriented architecture (SOA) papers that

feature a case study involving a fictitious company called JKHL Enterprises
(JKHLE).

The focus of the case study in this paper is the challenges and solutions
associated with the connectivity of services for opening new accounts. This
paper describes how to apply the realization patterns of the Service Connectivity
SOA Scenario to solve the business and IT challenges as they relate to the case
study.

© Copyright IBM Corp. 2008. All rights reserved. ibm.com/redbooks 1

Introduction to the case study
JKHL Enterprises (JKHLE) is undergoing a set of fundamental business changes
in an effort to ultimately maximize profits. JKHLE has decided to adopt SOA
principles to address the business and IT challenges that it faces.

The JKHLE team is focusing on solving the challenges that are presented by
creating new customer accounts in a consistent manner throughout each of the
sales channels. This SOA adoption initiative is known as the Account Open
Project. Using an SOA approach will allow for a more rapid implementation and
greater flexibility for future changes that the business might need.

Note: For more detailed information about the case study, refer to Case Study:
SOA Account Open Project Overview, REDP-4376.

The case study that we describe in this paper includes the following key actors
and roles:
򐂰 Edmund Smythe-Barrett, Enterprise Architect
򐂰 Sandy Osbourne-Archer, Chief Technical Architect

Account Open Project challenges

The Account Open Project challenges that we define in this paper are associated
with the Service Connectivity SOA Scenario.

As described in Case Study: SOA Account Open Project Overview, REDP-4376,

the JKHLE challenges include accessing outdated and complex applications
from a variety of resources and, in some cases, relying on paper-based business
processes. These issues increase the time and cost of processing new accounts
and, as a result, can impact customer satisfaction negatively.

The Account Open Project architecture team is focused on solving the significant
issues with the existing multiple mechanisms that customers use when opening
accounts with JKHLE. They want to develop an improved, single mechanism for
opening accounts from both the business and IT viewpoints.

The Account Open Project will be the first test case for a new SOA
implementation within JKHLE.

2 Case Study: Service Connectivity SOA Scenario

Account Open Project requirements
The Account Open Project will be implemented in two phases:
򐂰 Phase one requirements
The first phase will introduce initial service connectivity SOA concepts into the
Account Open Project architecture.
򐂰 Phase two requirements
The second phase will implement more complex SOA solutions.

Phase one requirements

JKHLE will use the Account Open Project as the first test case to implement SOA
within the organization.

Sandy Osbourne-Archer, Chief Technical Architect, is concerned about declining

revenue and profits and is eager to address this issue using the Account Open
Project as an opportunity to better align business and IT objectives with the IT
infrastructure.

Edmund Smythe-Barrett, Enterprise Architect, has specific responsibility for

connectivity. He has some ideas for changes that he can introduce into the
JKHLE environment that will enable a more agile, flexible environment and that
will provide direct, significant benefits to both the Account Open Project and the
JKHLE IT environment as a whole.

There are some clear requirements that Sandy has for this project with which
Edmund can help.

REQ-01: Enable multi-channel access

Sandy wants the new Account Open process to be accessible from multiple
channels within the organization. Thus, the same process must be consistently
accessible from JKHLE offices, from the Internet, from the intranet, and as a
callable service.

Note: For solution details, refer to “Expose Existing Systems to Multiple

Channels” on page 7.

Case Study: Service Connectivity SOA Scenario 3

 REQ-02: Access external services in a secure and reliable way
The Account Open process must access external services in a secure, reliable
way, without exposing the JKHLE infrastructure to external access.

Note: For solution details, refer to “Gateway - Securely Connect to External

Third Parties and Trading Partners” on page 8.

REQ-03: Access existing back-end systems

The Account Open process must access existing back-end applications
seamlessly, although there is no current mechanism to accomplish this easily.

Note: For solution details, refer to “Adapting Enterprise Applications to Web

Services” on page 10.

REQ-04: Enable multiple internal clients to access Web services

The JKHLE organization consists of multiple remote offices, many which using
different standards. Sandy wants a unified way for these remote offices to access
the systems that are running at headquarters.

Note: For solution details, refer to “Internal connectivity based on open

standards” on page 12.

Phase two requirements

After addressing Sandy’s initial requirements, the Account Open Project will be
used to address some more advanced challenges. JKHLE has implemented an
SOA solution successfully but wants to improve it further.

Sandy has issued Edmund with four additional requirements.

REQ-05: Access external systems efficiently based on availability

The Account Open process uses a third-party provider for credit verification. This
third-party service sometimes has response times that exceed acceptable limits.
Sandy wants a smarter way to access external services in an efficient manner,
based on business value driven availability.

Note: For solution details, refer to “Business Value Driven Service Availability”
on page 14.

4 Case Study: Service Connectivity SOA Scenario

 REQ-06: Flexible communication between connectivity domains
Each JKHLE connectivity domain plans to implement an Enterprise Service Bus
(ESB) solution. Some JKHLE domains operate autonomously and so are free to
choose any ESB implementation. Future acquisitions might also lead to
additional ESB implementations in the enterprise. Sandy wants to impose
standards for service interaction that offer each domain the freedom to make
changes without impacting the other domains.

Note: For solution details, refer to “ESB Federation” on page 18.

REQ-07: Integrate business processes with diverse consumer and

provider applications

The Account Open business process needs to make calls to a variety of

back-end systems and receive calls from multiple channels. Sandy wants this,
and other, business process to make use of the existing ESB infrastructure within
the JKHLE environment.

Note: For solution details, refer to “WebSphere Message Broker and

WebSphere Process Server Interaction” on page 20.

REQ-08: Minimize impact of changes to partner service consumers

As JKHLE moves environments and services, they want to ensure that the
service consumers of trading partners are disrupted minimally.

Note: For solution details, refer to “Consumer Side ESB” on page 23.

Applying the SOA realization patterns to the case study:

Phase one
In preparation for the JKHLE SOA adoption, Edmund engages in many SOA
educational activities, including learning from the knowledge captured in the
IBM® SOA Foundation and SOA scenarios. Edmund is convinced that using
proven SOA realization patterns can provide an excellent entry point for
designing a solution. Edmund determines that JKHLE can take advantage of the
Service Connectivity SOA Scenario for the Account Open Project requirements.

Case Study: Service Connectivity SOA Scenario 5

 Edmund explains to Sandy that many of the patterns in the Service Connectivity
SOA Scenario make use of an ESB. An ESB is a logical architectural component
that provides an integration infrastructure that is consistent with the principles of
SOA. An ESB provides connectivity between service consumers and service
providers, as shown in Figure 1.

Service Service
ESB
Consumer Provider

Figure 1 An ESB

The basic capabilities that are provided by an ESB are:

򐂰 Inter-connections between service consumers and providers
– Interactions between consumers and providers are loosely coupled. The
consumer needs only a minimal amount of information about the provider
to connect to it. The ESB makes connections more straightforward and
makes it simpler to change the way consumers and providers are
connected at some future point.
– ESB Supports separation of concerns. The ESB demonstrates separation
of concerns by providing all loosely coupled connectivity capabilities in a
single architecture component.
򐂰 Service virtualization of:
– Identity through routing
There is no requirement for the service consumer to know the identity of
the target service. The ESB can determine the identity of the target
service.
– Protocol through conversion
There is no need for the consumer of a service to know the transport
protocol that is required by that service. The ESB can mediate between
the protocol that is used by the consumer and the protocol that is required
by the target service.
– Interface through transformation
There is no need for the service consumer to be aware of the request or
reply data format required by the target service. The ESB provides data
conversion services to converts between data representations.
򐂰 Aspect oriented connectivity of security, management, logging, auditing, and
so forth

6 Case Study: Service Connectivity SOA Scenario

 In phase one, JKHLE will use the following realization patterns from the Service
Connectivity SOA Scenario:
򐂰 Expose Existing Systems to Multiple Channels
򐂰 Gateway - Securely Connect to External Third Parties and Trading Partners
򐂰 Adapting Enterprise Applications to Web Services
򐂰 Internal connectivity based on open standards

Expose Existing Systems to Multiple Channels

The current connectivity architecture at JKHLE does not enable a process or
application to be accessed from different channels easily. Edmund wants to
enable users from different environments, such as rich clients, Internet browsers,
and intranet browsers, to be able to access the Account Open process in a way
that is natural for each consumer, without the requirement for different
mechanisms for each access channel. In particular, the JKHLE environment has
browser-based Internet and intranet users, voice-only users using an interactive
voice response system, and voice-only users who work with customer service
representatives, using Microsoft® .NET based application platforms.

A mechanism that encapsulates the different access mechanisms will insulate

Sandy’s other architecture teams from the different styles of access used within
the JKHLE environment.

Proposed solution
Edmund proposes an ESB architecture. The ESB can interact with multiple
channels and can convert the different message types from each channel into a
single canonical format that is passed on to the Account Open process. Figure 2
shows this architecture.

SOAP/JMS
Intranet Portal

SOAP/HTTP
.NET Application
Applications

Applications
Consumer

Provider
Enterprise
XML/HTTP SOAP/JMS
Internet Application Service
Bus
Fixed length/MQ Account
Rich Client Apps Open
Process
SOAP/HTTP
IVR Apps

Figure 2 Proposed solution: An ESB

Case Study: Service Connectivity SOA Scenario 7

 Sandy is pleased to see that this architecture places the burden of working with
different transport protocols and messaging formats with the ESB component
and not with the Account Open process. This architecture also eases the
integration of additional channels in the future. Any additional channels only need
to be configured with the ESB before other components, such as the Account
Open process, can receive calls from them.

This ESB component can also be used to communicate with other back-end
processes, as described in “Internal connectivity based on open standards” on
page 12.

Edmund recommends that JKHLE implement the ESB in IBM WebSphere®

Message Broker. The diverse channels used in this solution are a good fit for the
versatility of WebSphere Message Broker.

Gateway - Securely Connect to External Third Parties and Trading

Partners
Edmund was challenged to provide a solution for accessing external service
providers. The Account Open process needs to connect to an external service
provider to perform credit verifications on potential account holders. JKHLE is
very sensitive to external connections because of previous negative experiences.

Sandy has counseled Edmund that she needs a secure, controllable, and
manageable connection to a fixed set of external services. This is the only way
that the CIO/CTO will allow her to connect to an external provider.

8 Case Study: Service Connectivity SOA Scenario

Proposed solution
Edmund has a good solution to this set of requirements. He extends his ideas
around the ESB architectures to include a new class of ESB-integration
appliances. Coupled with appropriate components to provide a Registry and
Repository, as well as security and manageability, this architecture is shown in
Figure 3.

Partner
Account
Open SOAP/HTTP
Integration
Process Appliance
Credit
Verification
Registry/ Service
Repository

Security SOA
Manager Management

Figure 3 Proposed solution: An Integration Appliance

This environment includes the following components:

򐂰 Integration Appliance
Contains a service proxy built in to the Integration Appliance. The service
proxy performs the following functions:
– Uses the Service Registry and Repository to ensure that only services
that are sanctioned by the JKHLE architecture team can be accessed.
– Mediates the service request, so that the service request that is received
from the Account Open process is not necessarily the service provider that
is ultimately invoked.
The Integration Appliance also supports the full range of Web service security
standards, which are required for communication with the Credit Verification
Service.
Edmund recommends that JKHLE implement the Integration Appliance with
IBM WebSphere DataPower® XI50 for its support of Web services standards
and Web services security

Case Study: Service Connectivity SOA Scenario 9

 򐂰 Service Registry and Repository
Defines registered services sanctioned by the JKHLE architecture team. IBM
WebSphere Service Registry and Repository provides capabilities to store
and manage service metadata that make it a perfect fit to implement this
component.
򐂰 Security Manager
Verifies that requests to the Credit Verification Service are authorized to make
that request. Additionally this component verifies that responses from the
Credit Verification Service are valid responses to credit verification requests.
Although the Integration Appliance provides security capabilities, Edmund
proposes to use this component to participate in a centralized security
environment.
Edmund recommends that JKHLE implement the Security Manager with IBM
Tivoli® Access Manager for its enterprise-wide authorization services.
򐂰 SOA Management
Monitors service calls. The Integration Appliance also offers service
monitoring, but the JKHLE Management Architect requires a centralized
reporting capability.
Edmund recommends using IBM Tivoli Composite Application Manager for
SOA to monitor Web service calls.

Edmund explains to Sandy that the Account Open process simply has to make a
service call and the Integration Appliance will take care of the details. Edmund
explains that some of the other advantages of adopting an Integration Appliance
are:
򐂰 The Integration Appliance can be positioned in the JKHLE demilitarized zone
(DMZ), therefore providing further protection for the JKHLE environment. The
Integration Appliance is a security-hardened device that has been designed
to handle connections to external networks.
򐂰 The Integration Appliance contains specific built-in capabilities to protect
against a range of XML and Web services attacks.

Adapting Enterprise Applications to Web Services

The Account Open process needs to connect to existing back-end applications
running in environments such as SAP® and Siebel®. Sandy has requested that
the Account Open process should not be exposed to the mechanics of how the
back-end applications are called. Sandy has also requested that no application
changes are required in the back-end systems to accommodate communication
with the Account Open process.

10 Case Study: Service Connectivity SOA Scenario

Proposed solution
Edmund proposes a solution that uses an ESB as an intermediary between the
Account Open process and the back-end applications (see Figure 4).

SAP IDOC
Adapter
Enterprise
SOAP/HTTP SAP
Service
Bus
Account Siebel XML
Open Adapter
Process
Registry/ Siebel
Repository

Service Monitoring

Figure 4 Proposed solution: An ESB with adapters

This environment includes the following components:

򐂰 ESB with adapters
The ESB accepts service calls from the Account Open process as Web
services SOAP over HTTP messages. The ESB uses the appropriate adapter
to convert these messages into a format and transport protocol that the
back-end system understands and sends the messages to the back-end
application.
Edmund recommends that IBM WebSphere Enterprise Service Bus is a good
fit for this component. It has support for Web services calls and J2EE™
Connector Architecture resource adapters, and the group within JKHLE
requesting this architecture are keen to keep everything within the IBM
WebSphere Application Server stack.
򐂰 Registry and Repository
Stores service metadata. This component ensures that only registered
service calls are able to access back-end applications. This component is
implemented by WebSphere Service Registry and Repository.
򐂰 Service Monitoring
Monitors the service calls to and from the ESB. Edmund recommends using
IBM Tivoli Composite Application Manager for SOA to monitor Web service
calls.

Case Study: Service Connectivity SOA Scenario 11

 Edmund explains that this solution also provides protection against future
changes in the JKHLE environment. For every additional back-end application
that is required, an appropriate adapter can be added to the ESB.

Internal connectivity based on open standards

There is a pressing issue to address on behalf of the many remote offices that
make up the JKHLE organization. These remote offices have a long-standing
requirement to issue a controlled set of service requests to the JKHLE
headquarters environment. Although this issue is not directly related to the
Account Open Project, Sandy wants to address it as part of a move to an SOA
solution.

Some of these requests are standards-based service requests and others are
XML grammars that need to be mapped to a SOAP-based service request.
These requests are all internal to JKHLE and so do not suffer from some of the
issues mentioned previously. However, there is still a need to exercise a level of
control over the service requests. Consequently, Edmund wants to ensure that
there are service control and management capabilities in place.

The applications in the remote locations are all reasonably modern, using
various XML grammars as their data formats and Java™ Message Service (JMS)
as their transport. The headquarters applications, however, all require Web
service protocols, SOAP over HTTP.

12 Case Study: Service Connectivity SOA Scenario

Proposed solution
Edmund proposes the solution shown in Figure 5.

JKHLE Remote Office JKHLE HQ

XML/JMS

ESB
Application 1 SOAP/HTTP
Service
SOAP/JMS
Registry /
Repository
Application 2

SOA SOA
Management Agent Management

JKHLE Remote Office

JKHLE Remote Office
JKHLE Remote Office

Figure 5 Proposed solution: ESB, registry, and SOA Management

The JKHLE remote offices include the following components:

򐂰 ESB
Mediates between the various messaging types used by the remote office,
and the Web service formats used by the JKHLE headquarters. Edmund
explains that the need to support Web services and JMS makes WebSphere
Enterprise Service Bus a good fit for the ESB component.
򐂰 SOA Management Agent
The SOA management capability allows JKHLE to monitor the Web service
activity from the remote offices. Sandy wants the SOA management
capabilities under the control of the JKHLE headquarters, so each remote
office contains an SOA Management Agent that sends management data to
the headquarters domain.

Case Study: Service Connectivity SOA Scenario 13

 The JKHLE headquarters include the following components:
򐂰 Registry and Repository
Ensures that only registered headquarters services are used. This is
implemented by WebSphere Service Registry and Repository.
򐂰 SOA Management
A centralized store of SOA management data containing Web service activity
from the remote offices. The ability to monitor service calls is provided by IBM
Tivoli Composite Application Manager for SOA.

Applying the SOA realization patterns to the case study:

Phase two
After a successful implementation in phase one, Sandy and Edmund have
designed an SOA environment for JKHLE based around service connectivity. In
phase two, JKHLE is eager to expand the SOA environment to take advantage of
some advanced capabilities of service connectivity.

Sandy and Edmund use four more realization patterns for the Service
Connectivity SOA Scenario to help design their solutions:
򐂰 Business Value Driven Service Availability
򐂰 ESB Federation
򐂰 WebSphere Message Broker and WebSphere Process Server Interaction
򐂰 Consumer Side ESB

Business Value Driven Service Availability

Sandy is eager to maximize the business value of the Account Open process. To
do this, she wants to focus on minimizing cost and maximizing satisfaction.

Sandy explains to Edmund that there is a problem with the Credit Verification
Service that the Account Open process uses. Currently the Account Open
process connects directly to a Credit Verification Service that is hosted by an
external provider called CVCo. This direct connection provides a low cost
solution, but customers have complained about slow response times. Sandy
wants to improve the response times to meet acceptable limits, which in turn
should lead to higher customer satisfaction.

14 Case Study: Service Connectivity SOA Scenario

Current environment
The current architecture consists of a direct call between the Account Open
process and the Credit Verification Service, through an ESB Gateway (Figure 6).

JKHLE CVCo

ESB Gateway
SOAP/HTTP SOAP/HTTP
Account Credit
Open Verification
Process Service

Figure 6 Current environment: A direct connection

The request messages from the Account Open process to the Credit Verification
Service pass through an ESB Gateway. The ESB Gateway allows the connection
to take place between the JKHLE and CVCo, providing a service proxy, XML
firewall, and Web services security.

Edmund explains to Sandy why this architecture has resulted in variable

response times. This direct connection approach does not offer an alternative
service to which the Account Open process can connect. It can only invoke the
Credit Verification Service that CVCo hosts. The CVCo service has variable
response times due to an inadequate and aging architecture. In this direct
connection architecture, those slow response times are passed on to the
Account Open process.

Sandy points out to Edmund that although the service that CVCo hosts is
occasionally unreliable, it is the lowest cost option and, in many cases, does
provide acceptable response times. Other service providers offer similar credit
verification services with improved and more reliable response times but at a
higher cost. JKHLE is reluctant to adopt this higher cost for every customer credit
verification.

Case Study: Service Connectivity SOA Scenario 15

 Proposed solution
Edmund explains to Sandy that the best solution is to continue to use the CVCo
service provider when its response times meet service level agreements. When
CVCo cannot meet the service level agreements, a second service provider,
called Verity, should be used. The service offered by Verity is more expensive but
is a better performing service.

Using this approach, JKHLE can offer a business-driven solution. They can
improve customer satisfaction by offering better response times to users of the
Account Open process while also minimizing cost. They can keep costs in check
by only using the more expensive Verity service provider when there is a
business need to do so. This solution represents a significant cost saving over
using Verity for all credit verifications, while offering the same level of customer
satisfaction that a solution that uses the Verify service exclusively would provide.

Edmund shows how both CVCo and Verity can be incorporated into the new
architecture, using dynamic routing. CVCo remains the preferred service
provider, but when it is not meeting the predefined service level agreement, the
Verity service provider is used instead (see Figure 7).

JKHLE ESB Gateway CVCo

SOAP/HTTP
ESB

Credit
SOAP/HTTP Verification
Account Service
Open
Process
Verity

Registry / System
Repository Management SOAP/HTTP
Credit
Verification
Service

Figure 7 Proposed solution: Dynamic routing using an ESB

16 Case Study: Service Connectivity SOA Scenario

This environment includes the following components:
򐂰 Additional credit verification partner
An additional partner, Verity, is engaged to provide a second Credit
Verification Service.
򐂰 ESB
Enables dynamic routing. At runtime, the ESB engages the Registry to
determine available providers (providers that meet a predefined availability
metric, defining whether a particular service currently has response times
above defined thresholds). The ESB then chooses the Credit Verification
Service that meets the availability metric and connects to it using the ESB
Gateway.
Edmund recommends implementing the ESB in WebSphere Enterprise
Service Bus. It supports Web services requests and can perform dynamic
routing through mediations built into IBM WebSphere Integration Developer.
򐂰 ESB Gateway
Calculates the response times for calls to the third-party providers (CVCo and
Verity) in addition to its role providing a service proxy, XML firewall, and Web
services security. WebSphere DataPower XI50 provides all of these
capabilities.
򐂰 System Management
Monitors the response time of service providers through the ESB Gateway.
System Management reports situations when response time fails to meet
service level agreements and generates an event when this situation occurs
or clears.
Edmund recommends that JKHLE implement the System Management
component with IBM Tivoli Composite Application Manager for SOA. The IBM
Tivoli Composite Application Manager for SOA Agent monitors response
times of service providers and report situations when response time fails to
meet expected service level agreements or after a timeout period. IBM Tivoli
Composite Application Manager for SOA generates an event when a situation
occurs or clears.
򐂰 Registry and Repository
Includes service definitions for both Credit Verification Services. The Registry
also holds information about the availability of each service, based on events
received from the System Management component.
Edmund recommends using WebSphere Service Registry and Repository
(with the SupportPac™ SA04: IBM Tivoli Composite Application Manager for
SOA Event Handler for WebSphere Service Registry and Repository for
versions of the registry prior to V6.1).

Case Study: Service Connectivity SOA Scenario 17

 With this environment Sandy can see how response time thresholds can be
defined and requests are sent only to providers who are currently meeting these
threshold requirements. This solution should eliminate many of the slow
response times customers are experiencing and help to improve customer
satisfaction while minimizing costs.

ESB Federation
JKHLE has a distributed structure that consists of a headquarters and many
smaller remote offices. This leads to an organization built from many domains. A
domain can be based on line of business, an organizational unit, or a
geographical location.

Sandy is concerned about maximizing connectivity options throughout these

domains. Each connectivity domain needs to be free to adopt the optimal ESB
implementation for them. Sandy is also concerned that future acquisitions will
bring additional ESB implementations to JKHLE. JKHLE needs a mechanism to
join potentially heterogeneous ESB implementations together.

Edmund has been tasked to define a solution that imposes standards for service
interaction but also offers freedom within a domain to makes changes to
providers and interfaces without impacting consumers.

Current environment
Figure 8 shows the current JKHLE environment.

JKHLE Remote Office JKHLE HQ

ESB

SOAP/HTTP
Application Service
Registry /
Repository

JKHLE Remote Office

JKHLE Remote Office
JKHLE Remote Office

Figure 8 Current environment: A direct connection

18 Case Study: Service Connectivity SOA Scenario

Each JKHLE remote office (RO) makes direct, point-to-point connections with the
services that are running in the headquarters (HQ) domain. For an application
running in the remote office to communicate with a service running at HQ, the
following interactions take place:
򐂰 The remote office application interacts with the remote office ESB.
򐂰 The ESB retrieves the location of the HQ service from a Registry and
Repository.
򐂰 The ESB interacts directly with the HQ service.

This solution works well for JKHLE, but it does not meet Sandy’s goal of being
able to adapt easily to changes in the HQ service. If the HQ service changes its
interface, every remote office ESB would need to be updated to take this change
into account.

Proposed solution
Edmund describes how the current JKHLE environment can be modified to meet
all of Sandy’s objectives. By introducing an ESB and a Registry in the HQ
domain, the JKHLE environment can support loosely coupled dynamic routing in
all domains (see Figure 9).

JKHLE HQ
JKHLE Remote Office

Any

ESB
ESB

SOAP/HTTP
Application Service

JKHLE Remote Office Registry /

Repository
JKHLE Remote Office
JKHLE Remote Office

Figure 9 Proposed solution: ESB federation

Case Study: Service Connectivity SOA Scenario 19

 This environment includes the following additional component:
򐂰 ESB in the HQ domain
Remote offices connect through the HQ ESB instead of connecting directly to
a service running in the HQ domain. Edmund recommends that the ESB in
the HQ domain is implemented by WebSphere Message Broker. This
maximizes the interfaces and bindings the ESB can work with.

Edmund explains the advantages of this federated ESB architecture:

򐂰 The HQ domain has the freedom to change services without impacting the
remote offices. New or multiple providers can be added, new bindings or
interfaces can be defined, and services can be versioned. The ESB in the HQ
domain keeps track of all the changes. Therefore, the changes are not
exposed to the remote offices.
򐂰 In the current environment, if a remote office ESB does not support the
binding or interface of an HQ service, it cannot connect to it. In this proposed
JKHLE environment, the HQ ESB acts as an adapter, transforming service
bindings and protocols and allowing remote offices to connect to these
previously inaccessible services.

WebSphere Message Broker and WebSphere Process Server

Interaction
The Account Open business process needs to interact with a broad range of
heterogeneous services for both inbound and outbound requests. These
requests will be made in significant volumes.

Sandy explains that the Account Open process has some significant connectivity
requirements:
򐂰 The Account Open business process needs to accept requests from multiple
channels that use different transport and data formats.
򐂰 The Account Open business process also needs to access an increasing
variety of JKHLE back-end applications, many of which do not support
standard service interfaces.

20 Case Study: Service Connectivity SOA Scenario

 Current environment
Edmund explains that an existing ESB architecture is already in place and meets
many of the requirements. This environment was constructed as part of “Expose
Existing Systems to Multiple Channels” on page 7. Edmund shows Sandy the
diagram that explains this architecture and, for emphasis, highlights that the
Account Open process is actually running in a Business Process Server (see
Figure 10).

SOAP/JMS
Intranet Portal

SOAP/HTTP
.NET Application Business Process
Applications

Applications
Consumer

Server

Provider
Enterprise
XML/HTTP SOAP/JMS
Internet Application Service
Bus
Fixed length/MQ Account
Rich Client Apps Open
Process
SOAP/HTTP
IVR Apps

Figure 10 Current environment: ESB interacting with a Business Process Server provider

Edmund reminds Sandy that WebSphere Message Broker was selected to

implement the ESB component and that WebSphere Process Server was
selected to implement the Business Process Server component.

Proposed solution
Edmund recalls to Sandy that one of the selling points of the Exposing Existing
Systems to Multiple Channels pattern is the straightforward ability to add
additional clients in the future. Sandy’s new requirements are the perfect
opportunity to demonstrate this solution.

The Account Open process can already receive requests from multiple channels,
through the use of the ESB component. Edmund explains that by making the
Account Open process a consumer (as well as a provider) of the ESB, it can also
access the variety of JKHLE back-end applications that Sandy is requesting.
Each back-end application is added as a provider to the ESB, and the Account
Open process is a consumer that uses the ESB to reach these applications.
Using this architecture the Account Open process does not have to access the
back-end systems in their native format.

Case Study: Service Connectivity SOA Scenario 21

 Edmund also recommends adding a Registry and Repository to this architecture
to store service metadata (see Figure 11).

SOAP/JMS
Intranet Portal Business Process
Server
SOAP/HTTP SOAP/JMS
.NET Application

XML/HTTP Account
Internet Application
Open
Process
Enterprise
Applications

Applications
Fixed length/MQ
Consumer

Rich Client Apps Service

Provider
COBOL CICS
Bus
SOAP/HTTP Copybook/MQ IMS
IVR Apps
SOAP/HTTP .NET
Business Process Provider
Server
SOAP/JMS XML/HTTP Perl
Provider
Account
Open
Process

Registry/
Repository

Figure 11 Proposed solution: Support for a Business Process Server consumer and a Registry added

In this proposed architecture:

򐂰 Instances of the Account Open business process (running in the Business
Process Server component implemented by WebSphere Process Server) are
initiated by requesting applications through WebSphere Message Broker.
򐂰 The Account Open business process (running in the Business Process
Server component implemented by WebSphere Process Server) connects to
service providers using WebSphere Message Broker.
򐂰 A Registry and Repository is used by WebSphere Message Broker to obtain
service information about the Business Process Server, consumer
applications, and provider applications. Edmund recommends this registry is
implemented in WebSphere Service Registry and Repository.

Edmund explains to Sandy that WebSphere Message Broker mediates multiple

transport protocols and data formats used by consumer applications and sends
them to the Business Process Server. Additionally the Account Open business
process can access a broad set of provider applications, both standards and

22 Case Study: Service Connectivity SOA Scenario

 non-standards based, by using WebSphere Message Broker’s advanced
transformation capabilities.

Consumer Side ESB

JKHLE wants to minimize the impact to its trading partners when changes are
made within the JKHLE organization.

External trading partners are an important part of JKHLE’s business, and Sandy
wants to ensure that changes to JKHLE services have minimal impact on the
service consumers of trading partners. Sandy emphasizes that partners should
experience minimal disruption and minimal development costs as the result of
changes to JKHLE services.

Current environment
Figure 12 shows the current architecture that trading partners use to access
JKHLE’s line of business service providers. The remote applications do not use
the multi-channel pattern (described in “Expose Existing Systems to Multiple
Channels” on page 7) because they want to retain control of how and where their
service requests are routed, represented, and processed.

.NET JKHLE LOB Providers

Application

SOAP/HTTP Service

WebLogic
(JAX-RPC)
Application

WAS 6.0 WAS 6.1 + WS FP SCA PHP

(JAX-RPC) (JAX-WS) Application Application
Application Application

Figure 12 Current environment: Direct connections

Case Study: Service Connectivity SOA Scenario 23

 This environment includes direct, point-to-point connectivity between service
consumers and providers within a line of business. The interaction between
consumers and providers is as follows:
򐂰 Partners are sent WSDL that describes how to connect to the JKHLE
providers. This WSDL includes a hard-coded address of the service and
protocol.
򐂰 Partners can only call the JKHLE providers using a single messaging
format—SOAP over HTTP.
򐂰 Security requirements are sent in a separate document.

Sandy explains that she wants a new architecture constructed to address the
following concerns:
򐂰 JKHLE needs the freedom to change the JKHLE providers physical location
without having to contact each of the trading partners to inform them of the
change.
򐂰 JKHLE also wants to add support for additional protocols. There is an
immediate request for SOAP over JMS support and a requirement for
Representational State Transfer (REST) support in the future.
򐂰 JKHLE wants to register service consumers and to track their use of JKHLE
services.

24 Case Study: Service Connectivity SOA Scenario

Proposed solution
Edmund explains that all of JKHLE’s requirements can be met by simply adding a
Registry and Repository into the JKHLE domain (see Figure 13).

.NET JKHLE LOB Providers

Application

Registry /
Repository
Service

WebLogic SOAP/HTTP
(JAX-RPC)
Application

WAS 6.0 WAS 6.1 + WS FP SCA PHP

(JAX-RPC) (JAX-WS) Application Application
Application Application

Figure 13 Proposed solution: Adding a Registry

This environment requires that all of the service consumers make a one-time
change to update service consumer applications to include a registry lookup
code module. This registry lookup module queries the JKHLE Registry and
Repository for information about the service provider that they want to invoke.
The Registry and Repository returns information about the service, including
service endpoint address, message format, and server configuration. The
service consumers use this information to make calls to the JKHLE providers.
This method replaces the current method of using hard-coded information in
each service consumer to locate JKHLE service providers.

Sandy is concerned about asking each trading partner to change the consumer
applications, but Edmund assures her this change will be a one-time change that
will save trading partners development costs and disruption in the long term. If
any JKHLE providers change (by supporting additional transport protocols or
change location) then the Registry and Repository will be updated with that
information and each service consumer will retrieve that new information at
runtime. The trading partners will not be required to change their consumer
applications to reflect these changes.

Edmund recommends that JKHLE implement the Registry and Repository with
WebSphere Service Registry and Repository.

Case Study: Service Connectivity SOA Scenario 25

Summary
Edmund has successfully used a set of ESB architecture patterns to give Sandy
the flexible, loosely coupled connectivity environment that she needs to provide
an agile business process to the JKHLE organization. As well as supporting the
Account Open Project, the ESB architecture provides a platform for current and
future business processes and applications of JKHLE and their trading partners.

JKHLE has standardized on a common set of tooling and middleware

infrastructure software, including:
򐂰 Model and Assemble:
– IBM WebSphere Integration Developer
– IBM WebSphere Message Brokers Toolkit
򐂰 Deploy:
– IBM WebSphere Enterprise Service Bus
– IBM WebSphere Message Broker
– IBM WebSphere DataPower XI50
– IBM WebSphere Process Server
򐂰 Manage:
– IBM Tivoli Composite Application Manager for SOA
– IBM Tivoli Access Manager
򐂰 Govern:
– IBM WebSphere Service Registry and Repository

References
This section includes reference information for further reading materials that are
related to the Service Connectivity SOA Scenario:
򐂰 IBM SOA Sandbox found at:
http://publib.boulder.ibm.com/infocenter/soasdbox/v1r0m0/index.jsp?t
opic=/com.ibm.soln.SOASandbox.nav.fw.doc/home_pages
򐂰 Patterns: SOA Foundation Service Connectivity Scenario, SG24-7228
򐂰 Case Study: SOA Account Open Project Overview, REDP-4376

26 Case Study: Service Connectivity SOA Scenario

The team that wrote this IBM Redpaper
This paper was produced by a team of specialists from around the world working
with the International Technical Support Organization (ITSO).

Martin Keen is a Senior IT Specialist for the IBM International Technical Support
Organization in Raleigh, NC, USA.

Stuart Jones is an Integration Solutions Architect, IBM Worldwide WebSphere

Technical Support in Chicago, IL, USA.

Thanks to the following people for their contributions to this project:

򐂰 Erica Carmel, IBM Program Director, SOA Platform Consumability, USA
򐂰 Cindy Macrafic, IBM Senior Project Manager, SOA Platform Consumability,
USA
򐂰 Rashmi Kaushik, IBM Product Manager, SOA Scenarios, USA
򐂰 Greg Flurry, Senior Technical Staff Member, IBM SOA Advanced Technology,
USA
򐂰 John Ganci, Architect / Specialist, Scenario Analysis Lab, Raleigh, NC, USA
򐂰 Linda Robinson, Graphics Artist, IBM ITSO, Raleigh, NC, USA

Case Study: Service Connectivity SOA Scenario 27

28 Case Study: Service Connectivity SOA Scenario
Notices

This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
© Copyright International Business Machines Corporation 2008. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by
GSA ADP Schedule Contract with IBM Corp. 29
This document REDP-4380-00 was created or updated on January 21, 2008.
Send us your comments in one of the following ways: ®
򐂰 Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
򐂰 Send your comments in an e-mail to:
redbook@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099, 2455 South Road
Poughkeepsie, NY 12601-5400 U.S.A.

Redpaper ™
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:

Redbooks (logo) ® IBM® Tivoli®

DataPower® SupportPac™ WebSphere®

The following terms are trademarks of other companies:

SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other
countries.
Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation
and/or its affiliates.
Java, J2EE, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States,
other countries, or both.
Microsoft, and the Windows logo are trademarks of Microsoft Corporation in the United States, other
countries, or both.
Other company, product, or service names may be trademarks or service marks of others.

30 Case Study: Service Connectivity SOA Scenario