3.6 Product mappings

---

3.6 Product mappings

The next step after choosing a Runtime pattern is to determine the actual products and platforms to be used. It is suggested that you make the final platform recommendation based on the following considerations:

• Existing systems and platform investments

• Customer and developer skills available

• Customer choice

The platform selected should fit into the customer's environment and ensure quality of service, such as availability and performance, so that the solution can grow along with the e-business.

This section introduces the major products used in the application and provides an overview of the products as they apply to the Direct Connection runtime patterns.

Our sample application, based on the Direct Connection application patterns, has been implemented using IBM WebSphere Application Server V5.0.2 on the Microsoft Windows 2000 platform.

Refer to 5.2, "Product descriptions" on page 101 for descriptions of the products used in these Product mappings.

Note 

Although we developed these product mappings from our sample scenarios on the Windows 2000 operating system, there are a number of other options because IBM WebSphere products run on a wide range of platforms (for example, Windows 2000, Linux, AIX®, OS/400®, z/OS®, and so forth).

3.6.1 Product mappings for Direct Connection: Message variation

This section presents Product mappings for the Message Connection variation of the Direct Connection pattern using:

• Web services

• Web Services Gateway

• Java Message Service

Web services

Figure 3-14 shows a Product mapping based on IBM WebSphere Application Server V5.0.2 and the Message Connection variation of the Direct Connection pattern that uses a one-way Web service invocation.

Figure 3-14: Direct Connection--Message Connection- Web services Product mapping

We use coupling adapter connectors to model Web services application integration. This emphasizes the use of adapter connectors to convert the request into the common SOAP/HTTP protocol.

In this case, the source application uses the JAX-RPC API to send a one-way request via the WebSphere V5.0.2 SOAP provider. The target application uses JAX-RPC API to receive the request from the source via its WebSphere V5.0.2 SOAP provider.

We used this combination of runtime nodes and products to implement the sample scenario described in Chapter 8, "Using RPC style Web services" on page 147 and Chapter 9, "Using document style Web services" on page 183.

As shown in Table 3-3, this Product mapping for the Message Connection variation of the Direct Connection pattern can use either of the SOAP messaging styles: RPC style or document style. Table 3-3 also shows that the Web service transmission style is generally one-way for the Message Connection variation; however, request-response may be needed when transport reliability is an issue.

Table 3-3: Direct Connection variation versus Web service type

	RPC style		Document style
	One-way	Request-response	One-way	Request-response
Message variation	ü		ü
Call variation		ü		ü

Note 

When integrating between J2EE application servers, RMI/IIOP is generally the preferred approach. The intention of this product mapping is to demonstrate that WebSphere V5.0.2 can be used to implement either a Web service requester or a Web service provider.

Web Services Gateway

Figure 3-15 shows another Product mapping based on IBM WebSphere Application Server V5.0.2 and the Message Connection variation of the Direct Connection application pattern that uses a one-way Web service invocation. This time we introduce the Web Services Gateway packaged with IBM WebSphere Application Server Network Deployment V5.0.2.

Figure 3-15: Direct Connection--Message Connection- Web Services Gateway Product mapping

This product mapping uses connection rules provided by the Web Services Gateway to allow greater control over the point to point connection between the source and target applications. The gateway provides access control and a common access point for internal Web services. It can also protect client applications from changes in the Web services they access.

We used this combination of runtime nodes and products to implement the sample scenario described in Chapter 10, "Using the Web Services Gateway" on page 215.

Java Message Service

Figure 3-16 shows a Product mapping based on the Message Connection variation of the Direct Connection application pattern that uses JMS to send a message from the source application and to receive the sent message at the target application.

Figure 3-16: Direct Connection--Message Connection- JMS Product mapping

This product mapping uses WebSphere MQ as the transport mechanism for JMS messages. The product mapping uses a WebSphere MQ queue manager on each server to transport the messages. The source application uses JMS to place messages on a local queue. WebSphere MQ is then responsible for ensured delivery of this message to the proper destination, in our case, the WebSphere MQ queue manager on the target application server.

We used this combination of runtime nodes and products to implement the sample scenario described in Chapter 13, "Using Java Message Service" on page 279.

3.6.2 Product mappings for Direct Connection: Call variation

This section presents Product mappings for the Call Connection variation of the Direct Connection pattern using:

• Web services

• Web services to .NET

• Web Services Gateway

• Web Services Gateway with protocol change

• J2EE Connector

• WebSphere Business Integration Adapters

Web services

Figure 3-17 shows a Product mapping based on IBM WebSphere Application Server V5.0.2 and the Call Connection variation of the Direct Connection pattern that uses a request-response Web service invocation.

Figure 3-17: Direct Connection--Call Connection- Web services Product mapping

We use coupling adapter connectors to model Web services application integration. This emphasizes the use of adapter connectors to convert the request and response into the common SOAP/HTTP protocol.

In this case, the source application uses the JAX-RPC API to initiate a request-response operation via the WebSphere V5.0.2 SOAP provider. The target application uses JAX-RPC API to receive the request from the source via its WebSphere V5.0.2 SOAP provider.

We used this combination of runtime nodes and products to implement the sample scenario described in Chapter 8, "Using RPC style Web services" on page 147 and Chapter 9, "Using document style Web services" on page 183.

As shown in Table 3-3 on page 59, this Product mapping for the Call Connection variation of the Direct Connection pattern can use either of the SOAP messaging styles: RPC style or document style. Table 3-3 on page 59 also shows that the Web service transmission style is generally request-response for the Call Connection variation.

Note 

When integrating between J2EE application servers, RMI/IIOP is generally the preferred approach. The intention of this product mapping is to demonstrate that WebSphere V5.0.2 can be used to implement either a Web service requester or a Web service provider.

Web services to .NET

Figure 3-18 shows a Product mapping providing connectivity between IBM WebSphere Application Server V5.0.2 and Microsoft .NET using the Call Connection variation of the Direct Connection pattern. The source and target applications communicate using a request-response Web service invocation.

Figure 3-18: Direct Connection--Call Connection- Web services to .NET Product mapping

We chose not to model the connection using coupling adapter connectors in this case. This product mapping focuses on the two platforms and the SOAP/HTTP connection between them.

We used this combination of runtime nodes and products to implement the sample scenario described in 9.5, "Integration with .NET-based Web services" on page 205.

Web Services Gateway

Figure 3-19 shows another Product mapping based on IBM WebSphere Application Server V5.0.2 and the Call Connection variation of the Direct Connection application pattern that uses a request-response Web service invocation. This time we introduce the Web Services Gateway packaged with IBM WebSphere Application Server Network Deployment V5.0.2.

Figure 3-19: Direct Connection--Call Connection- Web Services Gateway Product mapping 1

This product mapping uses connection rules provided by the Web Services Gateway to allow greater control over the point to point connection between the source and target applications. The gateway provides access control and a common access point for internal Web services. It can also protect client applications from changes in the Web services they access.

We used this combination of runtime nodes and products to implement the sample scenario described in Chapter 10, "Using the Web Services Gateway" on page 215.

Web Services Gateway with protocol change

Figure 3-20 shows a Product mapping based on IBM WebSphere Application Server V5.0.2 and the Call Connection variation of the Direct Connection application pattern that uses a request-response Web service invocation. In this product mapping the Web Services Gateway provides a protocol change between the source and target applications.

Figure 3-20: Direct Connection--Call Connection- Web Services Gateway Product mapping 2

In addition to the connection rules capabilities described in "Web Services Gateway" on page 62, the gateway provides adapter connector capabilities. This product mapping allows a Web service client application to invoke a CICS® target application using SOAP/HTTP. The gateway converts the SOAP/HTTP call to the CICS Transaction Gateway TCP protocol using the Web Services Invocation Framework and the CICS ECI J2EE Connector.

In addition to J2EE Connectors, the Web Services Gateway can be used to connect Web service client applications with target applications that are accessed via JMS or RMI/IIOP.

We used this combination of runtime nodes and products to implement the sample scenario described in Chapter 11, "Using the Web Services Gateway with J2EE Connectors" on page 237.

J2EE Connector

Figure 3-21 shows a Product mapping based on the Call Connection variation of the Direct Connection application pattern where the source application uses a J2EE Connector to call the target application.

Figure 3-21: Direct Connection--Call Connection- J2EE Connector Product mapping

This product mapping uses the CICS Transaction Gateway TCP protocol to communicate with the CICS Transaction Gateway on the zSeries® enterprise system. The source J2EE application uses the CICS ECI J2EE Connector to access the existing CICS enterprise application, via the CICS Transaction Gateway.

We used this combination of runtime nodes and products to implement the sample scenario described in Chapter 12, "Using J2EE Connectors" on page 263.

WebSphere Business Integration Adapters

Figure 3-22 shows a Product mapping based on IBM WebSphere Application Server Enterprise V5.0.2 and the Call Connection variation of the Direct Connection application pattern. In this product mapping the WebSphere Business Integration Adapter provides adapter connector capabilities between the source and target applications. This product mapping allows a WebSphere Enterprise application to invoke a target application using the Web Services Invocation Framework, JMS and IBM WebSphere MQ V5.3.1.

Figure 3-22: Direct Connection--Call Connection- WebSphere Business Integration Adapter Product mapping

The product mapping uses the WebSphere Business Integration Adapter JDBC adapter to access a DB2® V8.1 database. You can use a similar approach to integrate a WebSphere Enterprise application with a range of target applications, such as CICS, IMS™, PeopeSoft, SAP, and Siebel. For further details see Using Web Services for Business Integration, SG24-6583 (to be released late in 2003).

---