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.

Get Patterns: Extended Enterprise SOA and Web Services now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.