8.3 Applying patterns

---

8.3 Applying patterns

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.

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.

  For the same Web service, Wholesale1 offers a SOAP/HTTP implementation, while Wholesale2 offers a SOAP/JMS implementation. Although the Retail system will initially use SOAP/HTTP as an interface, future requirements will include the need to access the services using SOAP/JMS.

8.3.1 Application patterns

A Router node provides the multi-protocol transformation and intelligent request routing required for the solution, therefore ABC Electronics decided to use the Application Integration Router pattern to design the solution.

To phase in the solution, they decided to implement it in stages.

Stage 1: Basic integration

In the first stage, the Retail system requests either the service of the Wholesale1 or Wholesale2 department. This assumes that the Retail system knows which Wholesale department is the supplier for a particular part number. This solution requires simple router functions, which will be supplied by Web Services Gateway.

The request is directed to the Router node, which invokes the Web service from the requested Wholesale department. The Router presents a unified interface for the Retail system and transforms the message to the appropriate transport protocol for the target. It also performs logging of the event.

The solution implemented in this stage by ABC Electronics is shown in Figure 8-3.

Figure 8-3: Basic Router implementation

Stage 2: Enhanced integration

In the second stage, ABC Electronics will enhance the solution so the Retail system no longer needs to know which Wholesale department supplies the part. The Retail system can simply send the request to the Router, which will determine the appropriate Wholesale system and invoke the Web service. This places a requirement on the Router that it provide content-based routing.

The solution implemented in this stage by ABC Electronics is shown in Figure 8-4.

Figure 8-4: Enhanced Router implementation

Stage 3: Extended enterprise

In the third stage, ABC Electronics will enhance the solution so that external Retail systems can request delivery dates from the Wholesale departments. The implementation does not change, but the Web Services Gateway is opened up to the externals and protected with a firewall; and additional security concerns are addressed.

The solution implemented in this stage by ABC Electronics is shown in Figure 8-5.

Figure 8-5: Extended enterprise implementation

Similarly, the solution could provide the Retail systems in ABC Electronics could access external Wholesale companies.

Figure 8-6: Extended enterprise implementation

In either case, the Router node can be placed on the secure internal network behind the DMZ. The advantage of this configuration is that the gateway can provide access to services using protocols that are not as firewall-friendly as HTTP. For example, the Router node can enable Web service clients to access EJB, JMS, and JavaBean applications.

The Router node could also be located in the DMZ. All the firewalls in our example are configured for network address translation, so SOAP over HTTP can be used to pass through the firewalls. This may not work if the gateway is using RMI to access an EJB on the secure network, for example.

8.3.2 Runtime Patterns and Product mappings

The Product mapping chosen by ABC Electronics is shown in Figure 8-7, and is valid for intra-enterprise environments.

Figure 8-7: Product mapping for Router (using WebSphere Web Services Gateway)

Note 

The 5.0.2.1 fix level is required for SOAP/JMS.

The only addition to the product mapping for extended enterprise is the firewall system. However, note that even in intra-enterprise environments, a firewall system has added benefit, so you may want to consider the following product mappings for both intra and inter-enterprise.

There are actually two variations to consider. One is that the ABC Electronics wants to get delivery dates from external Wholesale suppliers. Figure 8-8 shows the Runtime pattern and product mapping that makes external Wholesale services available to the ABC Retail systems.

Figure 8-8: Exposed Broker--Router variation Runtime pattern and product mapping

The second possibility is that external Retail systems want to get delivery dates from ABC Wholesale departments. Figure 8-9 shows the Runtime pattern and product mapping that exposes the ABC Wholesale services to external Retail systems.

Figure 8-9: Exposed Broker--Router variation Runtime pattern and product mapping

Why use the Web Services Gateway?

In a solution that integrates multiple independent applications, key concerns include interoperability, compatibility, and security. While this is important in an intranet environment, it is even more important in an extended enterprise environment because of the diversity of applications, environments, and users who will be interacting with the exposed service.

The Web Services Gateway was selected for this solution for the following reasons:

• The gateway provides a common access point for internal client and external partner applications needing access to internal services. The gateway intercepts and routes requests to the applications providing the service. A change in the location of the service is handled once at the gateway, versus at each potential service requester site.

• The gateway provides a single point for controlling access to external services and hides changes to the external Web services from your internal client applications.

• The gateway secures your Web services, supporting authentication and authorization of Web service requesters. In an inter-enterprise environment, it can act as a reverse proxy, providing indirect access to your internal Web services.

• Filters can be used to validate or manipulate messages traveling to and from the Web service. In this case, a filter is used to determine the proper Web service to use based on the request. There are some built-in filters supplied with the Web Services Gateway, but you can also create your own.

• Requesters using one protocol can invoke Web services from back-end systems using a different protocol. For example, the Web Services Gateway provides the protocol transformation required to allow an HTTP/SOAP client to access a JMS/SOAP service.

Important: 

The Web Services Gateway is supplied with the Network Deployment package in both IBM WebSphere Application Server Network Deployment and WebSphere Application Server Enterprise. However, the underlying application server makes the difference in whether certain features are supported or not. In order to support the full functionality of the Web Services Gateway, including filter programming, you will need the WebSphere Application Server Enterprise product.

Why use a UDDI registry?

AUDDI registry is used by the Router node to obtain the interface description and the implementation description of the Web services provided by the Wholesale systems.

Although it may be easier in the short term to simply put the WSDL files of the Web services on a Web site than to implement a solution using a public or a private registry, consider the following trade-offs:

• Web sites don't have a discovery protocol that allows an application to search for and download WSDL files.

• As the use of Web services becomes more popular, consumers are increasingly likely to use a UDDI registry to find Web services.

• UDDI registries allow a fine degree of classification for Web services that allows consumers to quickly find the Web services to fit their needs.

---