Messaging is a way to exchange data between different applications. Several applications deployed over WAS can exchange information. The Service Integration Bus (SIBus, or just the bus) provides a transport mechanism for WebSphere Application Server. The bus serves as the main transport mechanism for messages. Consumers consume messages form some Destination in Bus. Producer produces and sends messages to some destination in Bus. Bus might be distribued, but applications act if they are interacting with single Bus. Applications are using Bus to exchange mesages, and thus integrating with each other. I would like to mention that WAS BUS is different from WebSphere ESB, which is a separate product. And contains several more features. WebSphere ESB is built on WebSphere Application Server. WebSphere ESB also includes additional functions not supplied with WebSphere Application Server.
BUS contains a list of destinations. Incoming messags are routed to destination. Message Consumers consume messages from Destination. Most Important, a message can also be routed from one destination to another before being consumed by a receiver.
A mediation is a piece of code which is always associated with a destination. Mediation code operates on a message as it traverses that destination.
Following figure would explain the collaboration between producer, consumer, destination and mediation -
Ref. - http://www.ibm.com/developerworks/websphere/techjournal/0501_reinitz/0501_reinitz.html
A bus is defined at the cell level. In a standard configuration, no more than one bus is normally required within a cell.
(taken from Red book) In above figure we have one Bus(HR Department Bus) for one cell. And two Nodes federated. Each Node have on Node Agent. Each node has two application servers. Only one application server is part of the bus. Application Server 2 is Bus Member of HR Department Bus. When a bus member is added, a messaging engine is created in that WebSphere instance, which has its own data store for messages.
For most development activity, you will create and assign a single bus member to the bus.
The Messenging Engine (ME) is a component of WebSphere Application Server. It communicates messages to destinations, in cooperation with the other MEs of other bus members. All of the messages that are sent to the destination will be handled by this messaging engine.
(Ref. - ibm.com/developerworks/websphere/library/techarticles/0504_barcia/0504_barcia.html
Multiple application servers can become part one bus. A messaging engine is associated with a bus member. When an application server is added as a member of a bus, a messaging engine is automatically created and associated with this application server. Messaging Engines wont be shared among Application Servers.
However, a cell can contain any number of buses. Multiple application servers can become part of different Bus. If an application server is added as a member of multiple buses, that application server is associated with multiple messaging engines, one messaging engine for each bus of which it is a member. For example, if cell has 4 aplication servers, AS1, AS2, AS3, and AS4. AS1 and AS4 can be member of one bus. AS2 and AS3 can be member of another bus. And As1 can be member of a third bus. And all bus belong to same cell. Below picture depicts above scenario (picture taken from Red Book) -
A message point is the location on a messaging engine where messages are held for a bus destination. A message point can be a queue point, a publication point, or a mediation point (this is a specialized message point) for eg., A queue point is the message point for a queue destination. If the bus member is an application server, a single queue point will be created and associated with the messaging engine on that application server.
When one is browsing the Application Server Console for messages, s/he has to peek into the message point. for example, in below figure I have created two destinations inside the BUS ( by default there is one more – System.Exception.Destination), and we can see the Queue Depth against the Queue Points -
Messages can also be viewed, by going deep into the Queue Points -
JMS - Java Messaging Service (JMS) is the standard API for accessing enterprise messaging systems from Java-based applications. Java Enterprise Edition (Java EE) applications (producers and consumers) access the SIBus and the bus members through the JMS API. We can create JMS Connection factory, JMS destinations in WAS console. Generally we create a Bus, make J2EE(which needs to send or receive messages to BUS) as BUS member. We also create destinations within the BUS, destinations which would hold messages produced by J2EE applications or which are going to be consumed by J2EE applications. J2EE applications use JMS API to connect to destinations, send and receive mesages. We need to create JMS Connection Factory and JMS Destination for that. We associate the JMS connection factory and JMS destination to our BUS. JMS destination is associated to SIBUS destination. Session Enterprise JavaBeans (EJBs)use a JMS connection factory to connect to the JMS provider. J2EE component Message Driven Beans are EJB’s which listen to any JMS destination, and consume messages. (MDBs) use a JMS activation specification to connect to the JMS provider. The interface between an MDB and its destination is the JMS activation specification.
A JMS activation specification is a group of messaging configuration properties, it cannot be manually started and stopped. It is possible to share a single JMS activation specification with multiple MDBs. This simplifies administration because it is only necessary to provide a single set of messaging configuration properties. Activation specifications are simple to configure, because they only require two objects: the activation specification and a message destination.
Below picture depicts how one EJB sends messages to a JMS Destination(associated to a SIBUS destination), and mesages are consumed by a MDB from the same JMS destination (taken from Redbook)-
http://www.youtube.com/watch?v=uCaly04a_lk&feature=plcp&context=C37a70fcUDOEgsToPDskI0v3O4Yifj6K61aKcNwG6n