Patterns: Extended Enterprise SOA and Web Services

Chapter 13. Exposed Router runtime pattern: SOA profile 397

As shown in Figure 13-5 on page 396, the SOA profile is implemented by

introducing the ESB and the Exposed ESB Gateway component. The ESB

integrates all the service calls at an enterprise level and provides the mediation

logic built on business agreements and terms. Any interaction with an extended

enterprise is managed through the Exposed ESB Gateway component, which we

have implemented using WebSphere Partner Gateway V6.

13.4 Runtime guidelines

This section describes how to configure the runtime aspects of this scenario. It

uses the basic infrastructure of Chapter 11, “Exposed Direct Connection runtime

pattern: SOA profile” on page 237 as a starting point. In this section, you add a

WebSphere Partner Gateway configuration to act as the Exposed ESB Gateway,

and define new outbound services in the ESB to point to WebSphere Partner

Gateway configuration for each Manufacturer call.

13.4.1 Solution topology

As in the previous chapters, to represent the complete business scenario the

sample application is divided into four subapplications:

򐂰 ITSOGood contains the SCMSampleUI, Retailer, Warehouse, and

LoggingFacility services.

򐂰 Manufacturer, ManufacturerB, ManufacturerC are three individual services,

each packaged separately, and deployed to three different enterprises.

Calls to the three Manufacturer enterprise applications are sent to WebSphere

Partner Gateway V6. This application uses a SOAP pass-through to send SOAP

messages to an HTTP Server, which adds HTTP/S security to the SOAP

message and forwards the request on to the relevant Manufacturer. This is

shown in Figure 13-6 on page 398.

Note: The link between the ESB and Exposed ESB Gateway will be

configured using instructions in the Runtime guidelines section.

398 Patterns: Extended Enterprise SOA and Web Services

Figure 13-6 Solution topology

This section describes in detail how to configure WebSphere Partner Gateway to

communicate with ManufacturerA. Optionally, you can implement the

ManufacturerB and ManufacturerC applications as well. To do this you need

access to a Microsoft .NET server and a CICS Transaction Server V3.1 region.

Instructions for configuring the ManufacturerB and ManufacturerC servers are

described in:

򐂰 Appendix B, “Microsoft .NET Web services” on page 483

򐂰 Appendix C, “CICS Transaction Server Web services” on page 513

13.4.2 Creating the basic infrastructure

You need to have built the following infrastructure before you can continue with

this chapter:

Note: You do not need to configure the ManufacturerB and ManufacturerC

servers to build a working end-to-end sample application.

WebSphere

Application Server V6

ITSOGoodProfile - server1

ITSOGood

Application

ManufacturerProfile - server1

Manufacturer

Application

WebSphere

Application Server V6

ManufacturerB

Application

Microsoft .NET

ManufacturerC

Application

CICS Transaction

Server V3.1

IBM HTTP

Server V6

SSL

pass-through

rules

SOAP / HTTPS

Message

WebSphere

Partner Gateway V6

Document

Manager

itsogood.itso.ibm.com

itsogoodPGW.itso.ibm.com

manufacturera.itso.ibm.com

manufacturerb.itso.ibm.com

manufacturerc.itso.ibm.com

Chapter 13. Exposed Router runtime pattern: SOA profile 399

򐂰 Complete the steps in 11.4.2, “Creating the basic infrastructure” on page 254.

This describes how to build WebSphere Application Server server profiles

called ITSOGoodProfile and ManufacturerProfile, how to add a Network

Deployment manager, an HTTP Server, and install the necessary enterprise

applications.

򐂰 Complete the steps in 11.4.3, “Create and configure a service integration bus”

on page 257 to create a configure a service integration bus and an SDO

repository.

򐂰 You have installed and started a basic WebSphere Partner Gateway V6

Advanced or Enterprise Edition configuration.

13.4.3 Scenario implementation overview

In this scenario, you configure a WebSphere Partner Gateway Community

Manager and a Community Participant for each manufacturer. You add an HTTP

target, Gateways, and a Document Flow Definition for each manufacturer.

WebSphere Partner Gateway supports interactions between the Community

Manager and Community Participants through the use of targets. In the following

scenario, only the target representing a HTTP URI is setup. The HTTP target is

used to enable SOAP over HTTP pass through between the Manager and

Participants.

WebSphere Partner Gateway comprises three major runtime components:

Receiver, Document Manager, and Community Console. In our scenario the

service integration bus is configured to send SOAP documents over HTTP to the

Receiver service. The Receiver stores the documents in a file system for the

Document Manager to process. The Document Manager then polls the file

system for documents to process and then routes the document to predefined

destinations. The interactions in this scenario between the components are

shown in Figure 13-7 on page 400.