WebSphere

More and more companies are starting to adopt Service Oriented Architecture (SOA) - a framework for integrating business processes and supporting IT infrastructure as secure standardized components or services that can be reused and combined to address changing business priorities.

Enterprise Services Bus is an important architectural element in a SOA. This article will discuss how to implement an ESB with WAS for z/OS V6.

The ESB Concept
We all know that SOA is an approach to define integration architectures based on the concept of a service. When you enable service interactions using existing Internet and intranet infrastructure between systems in an architecture, you can create massive point-to-point connections, which are very difficult to manage.

It's necessary to have an infrastructure act as the intelligent, distributed, transactional, and messaging layer for connecting diverse services and data. Therefore, the concerns between service consumers and providers can be completely decoupled. The business functions in components, regardless of API, protocol, and location, can be invoked or used as services defined by a standard interface description based on WSDL. This type of infrastructure is Enterprise Service Bus (ESB). Figure 1 depicts the ESB concept. Per IBM, the essential services that an ESB provides are transport, quality-of-service based routing, mediation, and services gateway.

The transport services should support connections using nearly all communication protocols such as SOAP over HTTP, SOAP over HTTPS, SOAP over JMS, RMI, RMI over IIOP, CORBA, JCA, SNA, TCP/IP, etc. Hence, various types of service consumers and providers can connect to ESB.

The quality-of-service support in ESB enables delivery of service according to a defined service level agreement. The quality-of-service based routing basically handles the requirement of selecting the "best" service provider while also routing to locations across several and varied transports.

Mediation in an ESB enables the intelligent processing of service requests and responses, events, and messages. Mediator works as the intermediary components that operate the messages between the service consumers and providers. Mediation capabilities include: message transformation, logging, monitoring validation, content based routing, and content based quality-of-service related behaviors.

A services gateway works a B2B façade for ESB access for external partners.

An ESB is very similar to a traditional EAI integration broker. But ESB is standard-based. Virtually all ESB solutions are based on Web Service standards. There was no standard for the old integration broker products. Unlike the integration broker products having build-in business process orchestration engine, service process engines outside of ESB do the service orchestration. Service orchestration is exposed as a composite service that can be accessed from the ESB. In a word, everything is a service to the ESB. This architecture supplies more flexibility and scalability. An ESB can be implemented using platform-specific technologies such as the service integration bus (SIBus) in WebSphere Application Server (WAS) besides the classical messaging, EAI, and brokering technologies.

Why ESB on z/OS?
Virtually all ESB solutions are in distributed environments. Why do we need to implement an ESB on z/OS? The answer is Quality of Service (QoS). An ESB built on z/OS can exploit the zSeries eServer's QoS features such as high scalability, reliability, availability provided by the Parallel Sysplex clustering, unmatched workload management by zWLM, and better security.

In reality most composite services in an SOA architecture are composed of services exposed from the existing components in CICS and IMS. Implementing ESB on z/OS provides the composite services the same QoS as basic building blocks in CICS and IMS. Also the composite services' performance is better because of less network traffic (and leveraging the HiperSocket technology on zSeries eServers).

IBM introduced SIBus technology in WAS for z/OS V6. It could be used as the foundation to build an ESB. Here we'll elaborate on the SIBus concept, the ESB topologies, Web Services support, and mediation, but not UDDI and security. They will be discussed in separate articles in the future.

SIBus in WAS for z/OS V6
The SIBus in WAS for z/OS V6 provides a highly-flexible messaging fabric that supports a SOA with a wide spectrum of QoS options, supported protocols, and messaging patterns. It supports both messaging-oriented and service-oriented applications. SIBus concepts and architecture include:

Buses: The SIBus appears as the WAS for z/OS default JMS messaging provider out of the box. The "bus" concept is introduced so the administrator can group the messaging resources together into a single entity without having to expose all the details to the applications connecting to the bus. So the bus is just a logic concept like any other message bus.

Bus Members: Both a standalone application server and a cluster of application servers can be added to a bus by becoming a member of the bus. The scope of the bus is limited to the cell. Becoming a bus member means a number of messaging resources are automatically enabled. In WAS for z/OS, the Control Region Adjunct (CRA) is activated in every bus member application server. The CRA is a new address space introduced in WAS for z/OS V6. It's the special servant region in which a messaging engine of the SIBus runs.

Messaging Engines: The messaging engine is the component providing the core messaging functionality inside the application server. As mentioned above, it runs in the CRA. Conceptually the messaging engine is equivalent to a queue manager in WebSphere MQ. Messaging engines can communicate with each other. But the intercommunication is different from WebSphere MQ's. Once the messaging engines are defined in a bus, the intercommunication is implicit without explicit configuration.

Data Stores: Each message engine has its own data store with a set of tables in a database (most likely DB2 on z/OS). These tables are used to hold durable data by a messaging engine. For example, a persistent message is stored in the data store.

Destinations: The logic addresses in a bus to which applications can attach as message producers or consumers are called destinations. There are four types of destinations:

• Queue destination used for point-to-point messaging.
• Topic space destination used for pub/sub messaging.
• Alias destination used to refer to another destination.
• Foreign destination used to refer a destination on another bus.

Queue Point and Publication Point: A queue point is the physical message point for a queue destination. If the bus member is an application server, a single queue point will be created and associated with the messaging engine on that application server. If the bus member is a cluster of application servers, a queue point is created and associated with each messaging engine defined in the bus member. The queue destination is partitioned across the available messaging engines in the cluster.

A publication point is the physical message point for a topic space. Creating a topic space destination automatically defines a publication point on each messaging engine in the bus.

Mediations: Mediation is used to process in-flight messages. The types of processing mediation can perform include:

• Modifying or transforming a message.
• Routing messages (or cloned messages) to other or additional destinations.
• Allowing or disallowing a message to be delivered based on some conditional logic in the mediation. Mediation is associated with a destination on a bus. The SIBus provides a mediation framework runtime that lets you mediate messages.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...