WebSphere Event Broker technical overview

WebSphere® Event Broker enables information packaged as messages to flow between different business applications, ranging from large traditional systems through to unmanned devices such as sensors on pipelines.

This diagram shows the four main components of the WebSphere Event Broker (Message Brokers Toolkit, Configuration Manager, Broker, and User Name Server) and how they interact with each other.

Message routing

Messages can be routed from sender to recipient based on the content of the message.

The message flows that you design control message routing. A message flow describes the operations to be performed on the incoming message, and the sequence in which they are carried out.

Each message flow consists of:

IBM® supplies built-in nodes and samples for many common functions. If you require additional functions, you can deploy user-defined nodes that have been created and supplied by WebSphere Message Broker users or by independent software vendors and other companies; see User-defined nodes.

You create message flows in the Message Brokers Toolkit which is an integrated development environment and broker domain administration console.

Create the runtime environment

The work of routing messages takes place in a broker. Brokers contain a number of execution groups, which are processes in which message flows are run.

Brokers are grouped into broker domains. Each domain is coordinated by a Configuration Manager. Many brokers can exist in a single domain, and each can be running on a different system. Having multiple brokers helps you to provide protection against failure, and can separate work across different divisions in a business.

The system administrator creates the Configuration Manager with a command line instruction. The Configuration Manager uses an internal repository to store information relating to its broker domain.

The system administrator similarly creates one or more brokers, linking each to a particular Configuration Manager, therefore making them part of the domain controlled by that Configuration Manager. Each broker uses a database to store the information it needs to process messages at run time.

The Configuration Manager also displays the users and groups in the Access Control Lists (ACL) that you use to set user permissions; see Topic-based security. For more information about ACL, see Publish/Subscribe later in this topic.

Develop applications

After the system administrator has created and connected the components of the broker domain, an application developer creates and modifies message flows using the workbench.

Different perspectives in the workbench are used to develop message flows, and to administer broker domains; see Message Brokers Toolkit.

A repository can be used to provide access control and version control. A repository also allows multiple developers to work on the same resources in parallel; see Development repository.

You can use WebSphere MQ for communication between application and brokers; see WebSphere MQ Enterprise Transport. Other communication protocols you can use are:

Deploy applications to the runtime environment

When message flows have been created using the workbench, executable data can be deployed (transferred) to one or more brokers; see Deployment overview.

You can deploy data in the following ways:
  • From the workbench
  • Using a shell command
  • Using the Configuration Manager Proxy application programming interface

When you deploy message flows, they are compiled and enveloped in a broker archive (BAR) file, and sent to the Configuration Manager; see Deployment overview. The BAR file has configurable system properties. You can override properties such as queue names, without the need to change source files or redevelop the message flow. This configuration makes it easier to move definitions between systems.

The Configuration Manager opens the envelope, removes the contents, makes a record of the information that it has received, and routes the information to the appropriate brokers. (The envelope is discarded when the information it contains has been retrieved.) Each broker stores the information in its own local database. This local storage means that, when a broker has sufficient information, it can continue processing messages even if it is no longer connected to its Configuration Manager.

The Configuration Manager coordinates all activity between the workbench and brokers within its domain. WebSphere MQ messaging is used between the workbench, the Configuration Manager, and the brokers.

Publish/Subscribe

A publishing application sends a message about a named topic to a broker; see Topics. The broker passes the published message to those applications that have registered an interest in that topic. The publisher and the subscriber are unaware of the other's existence.

The broker handles the distribution of messages between publishing applications and subscribing applications. Applications can publish on, or subscribe to, many topics as well as apply more sophisticated filtering mechanisms.

An optional User Name Server in the broker domain controls who is authorized to publish or subscribe to topics. You set up and administer topic-based security from the workbench.

You set user permissions at individual or group level using Access Control Lists; see Topic-based security.

Further information

For a basic introduction to WebSphere Message Brokers, see the IBM Redbooks® publication WebSphere Message Broker Basics.

Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009. All Rights Reserved.
Last updated : 2009-01-07 15:39:35

ab20551_