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.
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:
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:
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 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:
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.
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.
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 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.
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.
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.
IBM-CICS Related Interview Questions
|VSAM Interview Questions||IBM - VSAM Interview Questions|
|IBM-REXX Interview Questions||JCL Interview Questions|
|IBM DB2 Interview Questions||COBOL Interview Questions|
|IBM-JCL Interview Questions||DB2 Using SQL Interview Questions|
|IBM-JCL&VSAM Interview Questions||IBM Mainframe Interview Questions|
|Mainframe DB2 Interview Questions|
Service-oriented Architecture And Cics
Cics As A Service Provider And Requester
Modern Web Services Development Tools
Development Of The Change Of Address Cics Application
Exposing Our Application As A Web Service
Developing Web Service Clients
Tracing The Change Of Address Scenario
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.