2-ibm- Case - Service Connectivity Soa Scenario

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 Consumer

ESB

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

.NET Application Internet Application Rich Client Apps IVR Apps

SOAP/JMS SOAP/HTTP XML/HTTP Fixed length/MQ

Enterprise Service Bus

SOAP/JMS Account Open Process

Provider Applications

Consumer Applications

Intranet Portal

SOAP/HTTP

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 Process

Integration Appliance

SOAP/HTTP Credit Verification Service

Registry/ Repository

Security Manager

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

SOAP/HTTP Account Open Process

Enterprise Service Bus

SAP Adapter

IDOC SAP

Siebel Adapter

XML Siebel

Registry/ 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 HQ

JKHLE Remote Office XML/JMS

ESB

Application 1 SOAP/JMS

SOAP/HTTP Service Registry / Repository

Application 2 SOA Management Agent

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

CVCo

SOAP/HTTP Account Open Process

ESB Gateway

JKHLE

SOAP/HTTP Credit Verification 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).

CVCo

Account Open Process Registry / Repository

ESB Gateway

SOAP/HTTP

ESB

JKHLE

Credit Verification Service

Verity System Management

Figure 7 Proposed solution: Dynamic routing using an ESB

16

SOAP/HTTP

Case Study: Service Connectivity SOA Scenario

SOAP/HTTP Credit Verification Service

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 Service

Application 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 ESB

ESB

SOAP/HTTP

Any

Application

Service

Registry / Repository

JKHLE Remote Office 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).

.NET Application Internet Application Rich Client Apps IVR Apps

SOAP/JMS SOAP/HTTP XML/HTTP Fixed length/MQ

Enterprise Service Bus

Business Process Server SOAP/JMS Account Open Process

Provider Applications

Consumer Applications

Intranet Portal

SOAP/HTTP

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 SOAP/HTTP

.NET Application Internet Application Consumer Applications

Business Process Server SOAP/JMS

XML/HTTP Fixed length/MQ

Rich Client Apps

SOAP/HTTP

IVR Apps

Enterprise Service Bus

Business Process Server SOAP/JMS

Account Open Process COBOL Copybook/MQ

CICS IMS

SOAP/HTTP

.NET Provider

XML/HTTP

Perl Provider

Provider Applications

Intranet Portal

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 Application

JKHLE LOB Providers

SOAP/HTTP

Service

WebLogic (JAX-RPC) Application

WAS 6.0 (JAX-RPC) Application

WAS 6.1 + WS FP (JAX-WS) Application

SCA Application

PHP 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 Application

JKHLE LOB Providers

Registry / Repository WebLogic (JAX-RPC) Application

WAS 6.0 (JAX-RPC) Application

Service

SOAP/HTTP

WAS 6.1 + WS FP (JAX-WS) Application

SCA Application

PHP 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: [email protected] 򐂰 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) 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.

30

Case Study: Service Connectivity SOA Scenario