Page 2 of 3   « previous page   next page »

Foreign Buses: A SIB bus can connect to and exchange messages with other message networks such as other SIB buses, WebSphere MQ, etc. The concept of a foreign bus is used to represent these message networks on the local bus.

Put the concepts together into Figure 2. It shows the basic architecture of the SIBus. It provides built-in QoS such as assured, secure, transactional, and manageable delivery, delivery replay, and modifiable qualities of transport. It supports event detection, triggering, distribution and complex event processing (CEP) as well.

As we discussed the essential services that an ESB provides are transport, quality-of-service-based routing, mediation, and services gateway. The reliable messaging service of the SIBus fulfills part of the ESB transportation requirement. The quality-of-service-based routing and mediation can be covered by the mediation runtime framework of the SIBus. What's missing is how the service providers and consumers using different protocols connect to the bus.

Fortunately IBM ships SIBWS (Web Service enablement) applications (and other needed artifacts) with WAS for z/OS 6. The SIBWS applications enable Web Services represented as destinations on the bus. The WSDL import creates the necessary "service" destinations. An existing destination can be exported as a Web Service provider.

The SIBWS applications have to be installed separately before the SIBWS features can be used. Currently the SIBWS supports SOAP over HTTP and SOAP over JMS. The architecture of the SIBWS enabling is shown in Figure 3. A similar architecture can be used to support protocols other than SOAP by adding other protocol supports in the endpoint listeners and outbound ports.

Detailed information on how to install the SIBWS applications can be found in the Resources. It explains the planning considerations for the endpoint listener, outbound port, and service destinations.

ESB Implementation Topologies
To make the topology discussion more understandable, let's detour to the runtime component in the CRA. Shown in Figure 4, the SIB service is the component that manages the lifecycle of any messaging-related transport chains that have been defined in the application server and handles inbound connection requests from external messaging applications.

The SIB service and any messaging engine make use of a variety of transport chains to communicate with each other and with client applications. If the application server is created using a default template, the four defined inbound transport chains are: InboundBasicMessaging, InboundSecureMessaging, InboundBasicMQLink, and InboundSecureMQLink.

JMS clients obtain connections to a service integration bus using a suitably configured JMS connection factory defined for the default messaging JMS provider. The connection represents an endpoint to a messaging engine through a proper transport chain. The programming model follows the JMS 1.1 standard.

MDBs are connected to the bus through a resource adapter. The resource adapter always attempts to connect an MDB to a messaging engine in the same server, if one is defined there. This is different from previous versions of WAS for z/OS in which a listener port mechanism was used for MDBs connecting to the messaging provider.

The endpoint listeners in Figure 3 are actually implemented as JMS clients. The outbound service invokers are implemented as MDBs.

The simplest topology is known in Figure 5. A standalone application server is added to a bus as a bus member. Since there's only one application server, the reliability and availability of the ESB depends on the z/OS LPAR and the application server. A single WAS for z/OS server scales up based on workloads by kicking off multiple servant regions. So does the ESB. This nice feature only exists on the z/OS platform. As you can guess, this topology is normally used for development and testing purpose.

Figure 6 shows the topology that has a server cluster added as the bus member. A messaging engine is automatically created and associated with each cluster member. However, only one of these messaging engines can be active at any given time. The others act as standby instances for failover. Following WAS for z/OS best practices, each cluster member runs on a different LPAR. Only the JMS clients on the server with the active messaging engine can access the destinations locally. All the others only have remote access. Since the JMS connection factory hides all the messaging engine locating details, there's no changes for the JMS programs. The JMS clients scale both out (by adding more servers to the cluster) and up (by increasing the servant region number in a server). The story for MDBs is a little different. You can install MDBs on all the servers. The MDBs all start but only the MDBs on the server with the active messaging engine get messages for processing. The MDBs only scale up.

The topology depicted in Figure 6 offers better availability, more reliability, and better scalability than that of Figure 5. The drawbacks are: some JMS clients have to access the bus remotely and MDBs couldn't scale horizontally. A messaging engine cluster can be created as shown in Figure 7 to overcome the drawbacks. Since each server has a messaging engine, JMS clients access the bus locally and all MDBs get messages for processing now. The workload balance is handled by the zWLM. Note: The green messaging engine is active.

It's possible to use other topologies to implement more sophisticated messaging solutions with SIBus. These topologies are more complicated and require more servers. Considering the implementation cost, the topology in Figure 7 should be the best choice for your ESB unless you have very special requirements.

Note: The green messaging engines are active.

To architect more advanced solutions, you have to consider the queue partition concept and messaging engine selection rules. A queue destination in SIBus is partitioned automatically when it's assigned to a cluster bus member. Every messaging engine in the cluster owns a partition of that queue and is responsible for managing messages assigned to the partition. Every message sent to the queue is assigned to exactly one of the partitions. The detail for messaging engine selection could be found in the Resources.

So far only single bus topologies have been discussed. In reality each department might have its own bus and all these department buses federated together to form the company-level ESB. A bus can connect other buses known as foreign buses. A gateway link from a ME in the local bus to an ME in the foreign bus can be created. Furthermore, a SIBus bus can join a WebSphere MQ network through an MQ link.

Inbound and Outbound Services
Now we'll explore the details of inbound and outbound services using a real-world ESB scenario. Imagine a fictional mortgage bank MortStreet that adopts a SOA. The bank's next-generation risk control system (RCS) is composed of a series of services. One of the services is the property data service (PDS). The bank contracts with two vendors. Vendor A provides the residential property data service. Vendor B provides a small business property data service. RCS accesses PDSA and PDSB through the ESB that handles transport, service request/response transformation, and message routing.

To simplify the discussion, we'll ignore the possible service gateway in the real-world implementation.

An inbound service accepts a SOAP message sent from a SOAP requestor into the bus. It can be called just like any other Web Service from a variety of platforms. To define an inbound service, you run an inbound service creation wizard in the WebSphere administration console and provide a WSDL file and an existing destination. Each inbound service corresponds to a service element in a WSDL document. In the inbound service wizard, you specify which endpoint listeners the service will use. An inbound port will be created for each endpoint listener selected. The inbound port equates to the port element in a WSDL document.

Page 2 of 3   « previous page   next page »