IBM Integration Bus processes messages in two ways: message routing and message transformation.
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.
- A series of steps used to process a message; see Message flow nodes.
- Connections between the nodes, defining routes through the processing; see Message flow connections.
IBM supplies built-in nodes and samples for many common functions. If you require additional functions, you can write your own user-defined nodes; see User-defined extensions overview.
You create message flows in the IBM Integration Toolkit.
Message transformation
- They can be transformed from one format to another, perhaps to accommodate the different requirements of the sender and the recipient.
- They can be transformed by modifying, combining, adding, or removing data fields, perhaps involving the use of information stored in a database. Information can be mapped between messages and databases. More complex manipulation of message data can be achieved by writing code, for example in Extended SQL (ESQL) or Java™, within configurable nodes.
- Some messages contain a definition of their own structure and format. These messages are known as self-defining messages, which you can handle without the need for additional information about structure and format; see Self-defining elements and messages.
- Other messages do not contain information about their structure and format. To process them, you must create a model of their structure; see The message model.
- The logical structure: the abstract arrangement and characteristics of the data, represented as a tree structure; see The message model.
- One or more physical formats: the way the data is represented and delimited in the physical bit stream; see Message Sets: Physical formats in the MRM domain.
Create the broker environment
The work of routing and transforming messages takes place in a broker. Within the broker, you can define one or more integration servers, which are processes in which message flows run.
The mode in which your broker is working can affect the number of integration servers and message flows that you can deploy, and the types of node that you can use. See Restrictions that apply in each operation mode.
You can install and create one or more brokers on one or more computers that are running a supported operating system. If you create multiple brokers, you can configure your environment to provide protection against failure, and you can separate work across different divisions in a business.
You administer the broker by using product commands, the IBM Integration Explorer, the IBM Integration API within the Integration Nodes view, or the IBM Integration API (also known as the CMP) in your own applications.
Develop applications
After your system administrator has created your brokers, your application developers can create and modify message flows and message definitions by using the IBM Integration Toolkit.
Different perspectives in the IBM Integration Toolkit are used to develop message flows, message model schema files, and other related resources; see IBM Integration Toolkit.
You can use a repository to provide access control and version control of your development resources. A repository also allows multiple developers to work on the same resources in parallel; see Development repository.
Your applications can communicate with the broker by using a range of protocols that includes WebSphere® MQ, JMS 1.1, HTTP and HTTPS, Web Services (SOAP and REST), File, Enterprise Information Systems (including SAP and Siebel), and TCP/IP. For more information about connecting applications, see Nodes for connectivity.
Deploy applications to the runtime environment
When you have created and configured your message flows, message model schema files, and associated resources by using the Integration Development perspective of the IBM Integration Toolkit, you can deploy the executable data to one or more brokers; see Packaging and deployment overview.
- From the Integration Nodes view of the IBM Integration Toolkit
- From the stand-alone administrative interface, the IBM Integration Explorer
- From the Test Client environment in the IBM Integration Toolkit
- By using a command
- By creating applications that use the IBM Integration API application programming interface
When you deploy message flows and message model schema files, they are compiled and enveloped in a broker archive (BAR) file, and sent to the target broker; see Packaging and deployment overview. The BAR file has configurable system properties. You can override properties such as queue and database names, without the need to change source files or redevelop the message flow. This configuration makes it easier to move definitions between systems.
The broker opens the BAR file, removes the contents, makes a record of the information that it has received, and discards the envelope. It retains the information in its local storage area within the computer file system, so that it can restore the application resources and restart messages flows if and when required.
Publish/Subscribe
Publish/subscribe is a style of messaging for which IBM Integration Bus provides limited support; in WebSphere Message Broker Version 7.0 this support was transferred to WebSphere MQ. If you have been connecting publish/subscribe applications to brokers in previous versions, see Migrating publish/subscribe information to WebSphere MQ.
Last updated Friday, 21 July 2017