Introduction to WebSphere Message Broker IBM-CICS

WebSphere Message Broker (WMB) falls into the category of software known as Application Integration or sometimes called middleware. Its purpose is to integrate software components that may not otherwise communicate directly. An example might be a proprietary accounting package on one side and a CICS application on the other. WMB allows the reformatting of messages from one system to be used by the other. Business rules can be applied to the data that is flowing through the message broker in order to route, store, retrieve, transform, and enrich the information.

1. Capabilities of WebSphere Message Broker

The primary capabilities of WebSphere Message Broker are message routing, message transformation, message enrichment, and publish/subscribe. Together these capabilities make WebSphere Message Broker a powerful tool for business integration.

Message routing

WebSphere Message Broker provides connectivity for both standards based and non-standards based applications and services. The routing can be simple point-to-point routing or it can be based on matching the content of the message to business rules defined to the broker.

WebSphere Message Broker contains a choice of transports that enable secure business to be conducted at any time and any place, providing powerful integration using mobile, telemetry, and Internet technologies. WebSphere Message Broker is built upon WebSphere MQ and therefore supports the same transports. However, it also extends the capabilities of WebSphere MQ by adding support for other protocols, including real-time Internet, intranet, and multicast endpoints.

WebSphere Message Broker supports the following transports:

  • WebSphere MQ Enterprise Transport
  • WebSphere MQ Web Services Transport
  • WebSphere MQ Real-time Transport
  • WebSphere MQ Multicast Transport
  • WebSphere MQ Mobile Transport
  • WebSphere MQ Telemetry Transport
  • WebSphere Broker JMS Transport

In addition to the supplied transports, the facility exists for users to write their own input nodes to accept messages from other transports and formats as defined by the user.

Message transformation and enrichment

Transformation and enrichment of in-flight messages is an important capability of WebSphere Message Broker, and it allows for business integration without the need for any additional logic in the applications themselves.

Messages can be transformed between applications to use different formats, for example, transforming from a custom format in a traditional system to XML messages that can be used with a Web service. This provides a powerful mechanism to unify organizations because business information can now be distributed to applications that handle completely different message formats without a need to reprogram or add to the applications themselves.

Messages can also be transformed and enriched by integration with multiple sources of data such as databases, applications, and files. This allows for any type of data manipulation including logging, updating, and merging. For the messages that flow through the broker, business information can be stored in databases or can be extracted from databases and files and added to the message for processing in the target applications.

Complex manipulation of message data can be performed using the facilities provided in the Message Brokers Toolkit, such as ESQL and Java.

In WebSphere Message Broker, message transformation and enrichment depends on a broker understanding the structure and content of the incoming message. Self-defining messages, such as XML messages, contain information about their own structure and format. However, before other messages, such as custom format messages, can be transformed or enhanced, a message definition of their structure must exist. The Message Brokers Toolkit contains facilities for defining messages to the message broker. These facilities are discussed in more detail in the following sections.


The simplest way of routing messages is to use point-to-point messaging to send messages directly from one application to another. Publish/subscribe provides an alternative style of messaging in which messages are sent to all applications that have subscribed to a particular topic.

The broker handles the distribution of messages between publishing applications and subscribing applications. As well as applications publishing on or subscribing to many topics, more sophisticated filtering mechanisms can be applied.

An improved flow of information around the business is achieved through the use of publish/subscribe and the related technology of multicast. These flexible distribution mechanisms move away from hard-coded point-to-point links.

2. Components of WebSphere Message Broker

WebSphere Message Broker is comprised of the following two principle parts:

  1. A development environment for the creation of message flows, message sets, and other message flow application resources.
  2. A runtime environment, which contains the components for running those message flow applications that are created in the development environment.

Development environment

The development environment is where the message flow applications that provide the logic to the broker are developed. The broker uses the logic in the message flow applications to process messages from business applications at run time. In the Message Brokers Toolkit, you can develop both message flows and message sets for message flow applications.

Message flows

Message flows are programs that provide the logic that the broker uses to process messages from business applications. Message flows are created by connecting nodes together, with each node providing some basic logic. A selection of built-in nodes is provided with WebSphere Message Broker for performing particular tasks. These tasks can be combined to perform complex manipulations and transformations of messages.

A choice of methods is available for defining the logic in the message flows to transform data. Depending on the different types of data or the skills of the message flow application developer, the following options are available:

  • Extended Structured Query Language (ESQL)
  • Java
  • Extensible Style sheet Language for Transformations (XSLT)
  • Drag-and-drop mappings

The nodes in the message flows define the source and the target transports of the message, any transformations and manipulations based on the business data, and any interactions with other systems such as databases and files.

Message sets

A message set is a definition of the structure of the messages that are processed by the message flows in the broker. Message flow to be able to manipulate or transform a message, the broker must know the structure of the message. The definition of a message can be used to verify message structure and to assist with the construction of message flows and mappings in the Message Brokers Toolkit.

Message sets are compiled for deployment to a broker as a message dictionary, which provides a reference for the message flows to verify the structure of messages as they flow through the broker.

Broker Application Development perspective

The Broker Application Development perspective is the part of the Message Brokers Toolkit that is used to design and develop message flows and message sets. It contains editors that create message flows, create transformation code such as ESQL, and define messages.

Runtime environment

The runtime environment is the set of components that are required to deploy and run message flow applications in the broker.


The broker is a set of application processes that host and run message flows. When a message arrives at the broker from a business application, the broker processes the message before passing it on to one or more business applications. The broker routes, transforms, and manipulates messages according to the logic that is defined in their message flow applications.

A broker uses WebSphere MQ as the transport mechanism both to communicate with the Configuration Manager from which it receives configuration information and to communicate with any other brokers to which it is associated.

Each broker has a database in which it stores the information that it needs to process messages at run time.

Execution groups

Execution groups enable message flows within the broker to be grouped together. Each broker contains a default execution group. Additional execution groups can be created as long as they are given unique names within the broker. Each execution group is a separate operating system process; therefore, the contents of an execution group remain separate from the contents of other execution groups within the same broker. This can be useful for isolating pieces of information for security because the message flows execute in separate address spaces or as unique processes.

Message flow applications are deployed to a specific execution group. To enhance performance, the same message flows and message sets can be running in different execution groups.

Configuration Manager

The Configuration Manager is the interface between the Message Brokers Toolkit and the brokers in the broker domain. The Configuration Manager stores configuration details for the broker domain in an internal repository, providing a central store for resources in the broker domain.

The Configuration Manager is responsible for deploying message flow applications to the brokers. The Configuration Manager also reports back on the progress of the deployment and on the status of the broker. When the Message Brokers Toolkit connects to the Configuration Manager, the status of the brokers in the domain is derived from the configuration information stored in the Configuration Manager’s internal repository.

Broker domain

Brokers are grouped together in broker domains. The brokers in a single broker domain share a common configuration that is defined in the Configuration Manager. A broker domain contains one or more brokers and a single Configuration Manager. It can also contain a User Name Server. The components in a broker domain can exist on multiple machines and operating systems and are connected together with WebSphere MQ channels.

A broker belongs to only one broker domain.

User Name Server

A User Name Server is an optional component that is required only when publish/subscribe message flow applications are running and where extra security is required for applications to be able to publish or subscribe to topics. The User Name Server provides authentication for topic-level security for users and groups that are performing publish/subscribe operations.

Broker Administration perspective

The Broker Administration perspective is the part of the Message Brokers Toolkit that is used for the administration of any broker domains that are defined to the Message Brokers Toolkit. This perspective is also used for the deployment of message flows and message sets to brokers in the defined broker domains.

The Broker Administration perspective also contains tools for creating message broker archive (bar) files. Bar files deploy message flow application resources such as message flows and message sets.

The Broker Administration perspective also contains tools to help test message flows. These tools include Enqueue and Dequeue for putting and getting messages from WebSphere MQ queues.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status