2-ibm- case - service connectivity soa scenario

Redpaper

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.

Martin KeenStuart Jones

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

http://www.redbooks.ibm.com/


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.

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.

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

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 requirementsJKHLE 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 accessSandy 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 wayThe Account Open process must access external services in a secure, reliable way, without exposing the JKHLE infrastructure to external access.

REQ-03: Access existing back-end systemsThe Account Open process must access existing back-end applications seamlessly, although there is no current mechanism to accomplish this easily.

REQ-04: Enable multiple internal clients to access Web servicesThe 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.

Phase two requirementsAfter 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 availabilityThe 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 “Gateway - Securely Connect to External Third Parties and Trading Partners” on page 8.

Note: For solution details, refer to “Adapting Enterprise Applications to Web Services” on page 10.

Note: For solution details, refer to “Internal connectivity based on open standards” on page 12.

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


REQ-06: Flexible communication between connectivity domainsEach 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.

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.

REQ-08: Minimize impact of changes to partner service consumersAs JKHLE moves environments and services, they want to ensure that the service consumers of trading partners are disrupted minimally.

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.

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

Note: For solution details, refer to “WebSphere Message Broker and WebSphere Process Server Interaction” on page 20.

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


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.

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

ServiceProvider

ServiceConsumer ESB


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 solutionEdmund 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.

Figure 2 Proposed solution: An ESB

SOAP/JMS

SOAP/JMS

SOAP/HTTP

XML/HTTP

Fixed length/MQ

SOAP/HTTP

AccountOpen

Process

Intranet Portal

.NET Application

Internet Application

Rich Client Apps

IVR Apps

EnterpriseService

BusCon

sum

erA

pplic

atio

ns

Prov

ider

App

licat

ions


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.


Proposed solutionEdmund 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.

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

Partner

CreditVerification

ServiceRegistry/Repository

SOAP/HTTP

SOAManagement

SecurityManager

AccountOpen

ProcessIntegrationAppliance


� 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.


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

Figure 4 Proposed solution: An ESB with adapters


� 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.

SOAP/HTTP

Registry/Repository

Service Monitoring

IDOC

XMLAccountOpen

Process

SAP

Siebel

SAPAdapter

SiebelAdapter

EnterpriseService

Bus


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.


Proposed solutionEdmund proposes the solution shown in Figure 5.

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.

JKHLE Remote Office JKHLE HQ

SOAP/HTTP

ESB

Registry / Repository

JKHLE Remote OfficeJKHLE Remote Office

JKHLE Remote Office

Service

SOAManagement Agent

SOAManagement

Application 1

XML/JMS

Application 2

SOAP/JMS


The JKHLE headquarters include the following components:


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.


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

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.

JKHLE

AccountOpen

Process

ESB

Gat

eway

CVCo

SOAP/HTTP SOAP/HTTPCredit

VerificationService


Proposed solutionEdmund 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).

Figure 7 Proposed solution: Dynamic routing using an ESB

JKHLE

AccountOpen

Process

ES

B

CVCo

SOAP/HTTP

SOAP/HTTPCredit

VerificationService


System Management

Verity

SOAP/HTTPCredit

VerificationService

ES

B G

atew

ay



� 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.


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).


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 environmentFigure 8 shows the current JKHLE environment.

Figure 8 Current environment: A direct connection

JKHLE Remote Office

Application

JKHLE HQ

SOAP/HTTPService

ESB



JKHLE Remote Office


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 solutionEdmund 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).

Figure 9 Proposed solution: ESB federation

JKHLE Remote Office

Application

JKHLE HQ

Any

Service

ESB


SOAP/HTTP

ESB


JKHLE Remote Office


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.


Current environmentEdmund 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).

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 solutionEdmund 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.

SOAP/JMS

SOAP/HTTP

XML/HTTP

Fixed length/MQ

SOAP/HTTP

Intranet Portal

.NET Application


Rich Client Apps

IVR Apps

EnterpriseService

BusCon

sum

erA

pplic

atio

ns

Prov

ider

App

licat

ions

Business ProcessServer

SOAP/JMS

AccountOpen

Process


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

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

SOAP/JMS

SOAP/HTTP

XML/HTTP

Fixed length/MQ

SOAP/HTTP

Intranet Portal

.NET Application


Rich Client Apps

IVR AppsCon

sum

erA

pplic

atio

ns

Prov

ider

App

licat

ions


SOAP/JMS

AccountOpen

Process

Registry/Repository


AccountOpen

Process

SOAP/JMS

COBOL CICSIMS

SOAP/HTTP .NETProvider

XML/HTTP PerlProvider

EnterpriseService

BusCopybook/MQ


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 environmentFigure 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.

Figure 12 Current environment: Direct connections

WAS 6.1 + WS FP(JAX-WS)Application

.NETApplication

WebLogic(JAX-RPC)Application

WAS 6.0(JAX-RPC)Application

SCAApplication

PHPApplication

JKHLE LOB Providers

ServiceSOAP/HTTP


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.


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

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.

PHPApplication

WAS 6.1 + WS FP(JAX-WS)Application

.NETApplication

WebLogic(JAX-RPC)Application

WAS 6.0(JAX-RPC)Application

SCAApplication

JKHLE LOB Providers

Service

Registry /Repository

SOAP/HTTP


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?topic=/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


http://publib.boulder.ibm.com/infocenter/soasdbox/v1r0m0/index.jsp?topic=/com.ibm.soln.SOASandbox.nav.fw.doc/home_pages

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


© Copyright International Business Machines Corporation 2008. All rights reserved.

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.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. 29

®

Redpaper™

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:

[email protected]� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. HYTD Mail Station P099, 2455 South RoadPoughkeepsie, NY 12601-5400 U.S.A.

Trademarks

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

Redbooks (logo) ®DataPower®

IBM®SupportPac™

Tivoli®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.



http://www.ibm.com/redbooks/

http://www.ibm.com/redbooks/

http://www.redbooks.ibm.com/contacts.html

2-ibm- case - service connectivity soa scenario

Documents