9.3 Applying patterns

< Day Day Up >

The Retail system needs to get delivery dates based on a part or system number from the appropriate Wholesale supplier. Each Wholesale supplier has its own unique implementation that returns the delivery date to requesters but has basically the same input and output formats for incoming requests and outgoing responses. Each Wholesale system does not necessarily support the same protocol for transmission of the requests and responses.

The Retail system knows the part number it wants a delivery date for, but doesn't know which Wholesale suppliers can deliver the part. In the event that there are multiple Wholesale suppliers for the part, the Retail system wants to know the earliest possible delivery date.

From this, ABC determined the following requirements:

Each Wholesale department must expose its services as Web services.

The actual implementation on the Wholesale systems must be transparent to the Retail system. The request for a delivery date will be done as a Web service invocation, relieving the Retail system from having to know how the request is fulfilled.
The design must be able to support multiple protocols and perform protocol transformation.
The design must be able to decompose the incoming request into multiple Web service requests, then must be able to recompose the responses into a reply. For this, a broker will be used.
The broker must be able to inspect the incoming request and determine which Wholesale system it needs responses from in order to create a complete reply for the Retail system. It must be able to send simultaneous requests to the Wholesale systems, and manipulate the responses so the earliest delivery date returned (and not all delivery dates) can be sent as a response.

9.3.1 Application patterns

ABC Electronics will address the solution in three stages:

In the first stage, they will integrate the internal Retail and Wholesale systems, allowing the Retail systems to get a delivery date based on a part number.
In the second stage, they will implement a solution that allows the Retail systems to publish sales information to internal Wholesale systems.
In the third stage, they will extend the solution from stage 1 to integrate the internal Retail systems with external wholesale partners. This will allow the Retail systems to get delivery dates for parts supplied by external Wholesale suppliers.

Stage 1: Internal delivery date

In stage 1, the solution will address the internal Retail and Wholesale systems. The use of a broker provides the ability to:

Perform any protocol transformation required between the Retail and Wholesale systems.
Perform intelligent routing of incoming messages, relieving the Retail systems from knowing which Wholesale systems can supply the part.
Route the request from the Retail system to multiple Wholesale systems simultaneously. In the event that multiple Wholesale systems can supply the part, the incoming message can be decomposed into multiple requests. The responses from the Wholesale suppliers can be recomposed into a single response which can then be manipulated to return only the earliest delivery date to the Retail system.

Because the applications to be integrated are all internal to ABC Electronics, they decided to use the Application Integration::Broker application pattern to design the solution.

The design implemented in this stage by ABC Electronics is shown in Figure 9-2 and Figure 9-3.

click to expand
Figure 9-2: Basic Broker implementation

click to expand
Figure 9-3: Extended enterprise implementation

Stage 2: Publish sales forecast

Stage 3: Extended enterprise

In this stage, ABC Electronics will enhance the solution so that ABC Retail systems can request delivery dates from external Wholesale companies. Because external partners will be targeted, the Extended Enterprise::Exposed Broker application pattern is selected for the solution. A gateway will be used to make the external processes available to the internal Retail system process.

The design implemented in this stage by ABC Electronics is shown in Figure 9-4.

click to expand
Figure 9-4: Extended enterprise implementation

9.3.2 Product mappings

The product mappings for the three stages are all based on WebSphere Business Integration Message Broker as the broker. In the Extended Enterprise mapping, the broker will access external Web services through the Web Services Gateway.

Application Integration

In stage 1, the need for a broker has been identified. The WebSphere Business Integration Message Broker will be used to provide the broker functionality in this solution (Figure 9-5).

click to expand
Figure 9-5: Product mapping for Application Integration--Broker

The source application is the Retail system. The target applications are the Wholesale inventory systems.

Extended Enterprise

In the previous product mapping, the Broker node is an internal asset with access to internal resources. In order to gain access to external resources communication has to pass through the servers in the DMZ and the corporate firewall.

The Web Services Gateway is a run-time component that can be used to provide access to external Web services by representing them as internal Web services. The mapping between the external resource and the internal representation is done based on WSDL files. It can also perform the reverse service by making internal Web services available externally.

In this product mapping, the message flows within the Message Broker will access external Web services using the Web Services Gateway.

Figure 9-6 shows the product mapping for the Exposed Broker.

click to expand
Figure 9-6: Exposed Broker Runtime pattern and product mapping

The Web Services Gateway provides a standard, secure interface to external processes. A UDDI registry is not required, but provides an additional layer of protection against the disruptions cause by changes in the external services. A private or public UDDI registry could be used.

< Day Day Up >