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
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
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
Note: You do not need to configure the ManufacturerB and ManufacturerC
servers to build a working end-to-end sample application.
Application Server V6
ITSOGoodProfile - server1
ManufacturerProfile - server1
Application Server V6
SOAP / HTTPS
Partner Gateway V6
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
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
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
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.