WebSphere Message Broker Introduction

Application Connectivity
================
Application connectivity is about providing a way for application programs to interconnect, and allow information to flow between them, without requiring the applications to be aware of the details of the connection. Basic connectivity is the starting point for any integration solution. It provides the transport on which information will flow.

 

There are many characteristics that distinguish different transport options, but when integrating across heterogeneous environments and when dealing with applications that were not designed to intercommunicate, there are several mandatory functions needed for success: assured delivery (and persistence), once-only delivery, and asynchronous delivery. It is also essential that the transport be capable of delivering any type of data: Extensible Markup Language (XML), SOAP, and proprietary (when this makes the mostsense for a particular customer's situation).

 

These functions are delivered through WebSphere MQ, the defacto standard for messaging connectivity. WebSphere MQ can provide all an application needs provided the number of applications being interconnected is small, two or three for example. But as the number of applications being interconnected increases, additional application connectivity services are needed to implement a more efficient and effective solution.

Message Brokering
============
When you are working in a large environment, message brokering functions are required. Fundamentally, message brokers are used to centralize routing and transformation functions, and these functions are essentially handled by a message flow. A message flow is a sequence of operations performed on a message by a series of message processing nodes. The actions are defined in terms of the message format, its content, and the results of individual actions along the message flow.

 

Notice, however, that the flow is, as was the case with basic messaging, simply an extension of the path from the source application to the destination application. In other words, it is assumed that the destination wants, expects, and will handle all messages sent to it.

Basically, the Message Broker is a WebSphere MQ application that routes and transforms messages.

The WebSphere Message Broker consists of four components (Toolkit, configuration manager, broker, and User Name Server) that communicate with each other using WebSphere MQ messages. The format of this information is XML.

 

Message Broker ToolKit
===============
The WebSphere Message Brokers Toolkit is an integrated development environment (IDE) and graphical user interface (GUI) based on the open source Eclipse platform. Application developers work in separate instances of the Message Brokers Toolkit (also known as workbenches) to develop message sets and message flows.
Tasks that can be performed using ToolKit
• Definition of message flows
• Definition and import of message definitions
• Deployment of message flows and message sets to brokers
• Control of log entries written during deploy
• Start, stop, and trace of message flows running in brokers
• Registering brokers in the configuration domai
• Viewing and deleting subscriptions for publish/subscribe
• Setting topic-based access control for publish/subscribe

 

Broker
====
A broker is a system service on Windows platforms, a daemon process on UNIX platforms, or a started task on z/OS platforms. It controls processes that run message flows.

Applications often send messages to the broker using WebSphere MQ queues and connections. The broker routes each message using the rules defined in message flows and message sets, which also transforms the data into the structure required by the receiving applications.

 

Broker Domains
==========
A broker domain is one or more brokers that share a common configuration, together with the single configuration manager that controls them. The configuration manager maintains all configuration details about the brokers in its domain within its internal configuration repository.

 

Configuration Manager
===============
The configuration manager functions as the interface between toolkit instances, its internal configuration repository, and a set of brokers executing message flows.

The configuration manager provides brokers with their initial configuration, and updates them with any subsequent changes. It maintains the broker domain configuration. The configuration manager is the central runtime component that manages the components and resources that constitute the broker domain. Administrators typically install, create, and start a configuration manager for each broker domain.

 

User name server
===========
The User Name Server is an optional component, needed only when topic-based access control for publish/subscribe is desired or required.

 

Message Flows
==========
A message flow is really nothing more than a program created using graphical tools. The toolkit component provides both the environment and tools to accomplish this task.