Before you can understand what a Service Integration Bus (SIB) is, it's helpful to see how data is transmitted without a Service Integration Bus. In this extremely simplified diagram, the sending system transmits data to the receiving system. In this scenario, the data would most probably be something like an email or an SMS message. While this is all fine and dandy, this type of design can produce problems. Most notably, if the receiving system is unable to receive the data (eg. the receving system is down or overwhelmed with requests), the sending system may not be able to move onto the next transmission or may continually try to send the data over and over again (which is a waste of the sending systems resources). A Service Integration Bus (SIB) resolves these issues.

A Service Integration Bus (SIB) sit's between the sending system and receiving system, as a sort of broker or proxy. In this way, if the receiving system is unavailable, the sending system does not get trapped in a situation where it cannot move onto it's next transmission or is bogged down trying to send the transmission over and over again. The sending system simply sends the data to the SIB and then moves on (fire and forget). In this way, the SIB makes it so that data tranmission is asynchronous.

You may encounter different terms used for the systems in a messaging heirarchy.

Technically speaking, a Service Integration Bus is a group of one or more WebSphere application servers (or a static cluster or dynamic cluster of application servers) or IBM MQ servers, known as bus members. The bus members contain a component called a messaging engine that is used to send and receive messages.

The messaging engine will store messages in what is known as a message store. Messages will remain in the message store until the consuming application is ready to receive the message. The store is simply nothing more than a file on the server or a SQL database.

Since the SIB is a very important component in the delivery of messages, you want to ensure the SIB has high availability. In other words, you don't want the SIB to be down for any period of time, if possible. For this reason, it's usually best for a cluster of application servers to be setup as SIB members, so that way if one member of the cluster does down, the other member(s) of the cluster can continue to process messages. Thus, you may want to first setup a static cluster or dynamic cluster before setting up the SIB.

Create Service Integration Bus (SIB)