A perspective is a collection of views and editors that you use to complete a specific task, or work with specific types of resource. The two significant perspectives in the WebSphere Message Broker Toolkit are the Broker Application Development perspective for application development, and the Debug perspective for debugging message flows. The first time that you start the WebSphere Message Broker Toolkit, the Broker Application Development perspective is displayed.
An additional stand-alone component, the WebSphere Message Broker Explorer, is supplied for advanced administrative users, and enables additional administration tasks that you cannot perform in the WebSphere Message Broker Toolkit.
Components of WebSphere Message Broker
WebSphere Message Broker is comprised of two principle parts, a development environment for the creation of message flows, message sets, and other message flow application resources; and 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. For an example message flow, see the simple ESQL message flow shown in below figure.
To build the ESQL_Simple message flow:
1. Make sure that the Selection button (at the top of the node palette) is highlighted so that you can select nodes from the node palette.
2. Click the MQInput node to select it from the node palette, then click
somewhere on the canvas (the white area to the right of the node palette) to start creating the message flow. The MQInput node is added to the canvas.
3. Add a Compute node and an MQOutput node to the message flow.
4. Rename each node as shown :
a. Right-click the MQInput node, then click Rename.... The Rename Node dialog opens.
b. Type ESQL_SIMPLE_IN then click OK (Figure Below). The node on the canvas is renamed to ESQL_SIMPLE_IN. ESQL_SIMPLE_IN is also the name of the queue from which the MQInput node will get messages. Using the same name for both the queue and the
node makes it easier for you to keep track of what queue to put the input
message on when you are testing the message flow.
c. Rename the Compute node and the MQOutput node.
5. Define the order in which the nodes process an input message by connecting them together as shown in Below:
a. Right-click the ESQL_SIMPLE_IN node, then click Create Connection.
The Select Terminal dialog opens.
b. In the Select Terminal dialog, click Out, then click OK. An arrow from the
ESQL_SIMPLE_IN node follows the mouse pointer when you move the mouse because you have not specified which node to connect to.
c. Click the Compute node. The arrow connects the ESQL_SIMPLE_IN node to the Compute node.
d. Connect the Out terminal of the Compute node to the ESQL_SIMPLE_OUT node. Ensure that you select the Out terminal on the Compute node and not, for example, Out1 or Out2.
Message sets
A message set is a definition of the structure of the messages that are processed by the message flows in the broker. As mentioned previously, in order for a 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.
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 other 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 and, 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 are used to 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.
Posts
No comments:
Post a Comment