Service Integration Bus
(SIBus) typically could be used in many topologies and different environments.
This blog details/lists some typical uses of SIBus, based on real customer
JMS application deployed in
The most obvious use of SIBus is by JMS applications running in WAS. In
this case customer does not have pre-existing messaging infrastructure, such as
WMQ. They can use the default messaging provider to construct a simple topology
with a single bus member and messaging engine. The applications could be
deployed to the bus member, or to another WAS server.
Connecting to bus from a thin client
Some times customers might have stand alone thin JMS client and needs
these application connect to SIBus.
WAS supports this environment from 6.0.2 onwards, the thin client jar is
shipped in runtimes directory.
In case thin JMS application use just JMS, then thin client jar is
sufficient. In case if JNDI lookups are needed, then JNDI jar is required, this
jar is packaged along with EJB client.
JMS application deployed in non-WAS
Some times customer JMS application running in 3rd party
application servers, such as Geronimo. WAS supports this environment using SIB thin JMS RA
Highly Available(HA) messaging
Single server bus member is replaced with cluster bus member to achieve
HA. The Messaging Engine(ME) will by default failover within the cluster. All
the cluster members who participate in HA have to possess access to the same
Message Store. If compared to single bus member topology, there is no change expect
that bus member now is a cluster.
A cluster with multiple MEs. In this case the destination is split
across the MEs and load is distributed among the MEs. How the load is distributed
depends on the configuration, and there are wide varieties of options available
on this end.
Scaling up other parts of the system
One customer has three core components in their messing system.
UI application for which lots of users connect
and has to be separated from core messaging because of huge load of users
Back end request processing (run on Message-driven beans(MDBs)) involved document processing and printing
software with high licence costs. Hence has to be separated from core
Messaging ( where MEs run)
So they have deployed three cluster architecture, one for UI processing,
second one for MEs and third one for MDB processing.
Multi-site, multi-cell (most preferred in Disaster Recovery (DR))
Many customers have a desire to avoid
a single point of failure (SPOF) and consider spreading their WAS
infrastructure across multiple data centers. The best solution for this is to
have messaging system spread across two cells.
A Disaster Recovery (DR)
solution could be created, by running one active cell and use the other as a
backup in case of a disaster. In this case the customer would create a mirror
image of the cell in the backup location.
Only one site would be
active at a time, and the configuration from the active site would be replicated
probably asynchronously by a storage replication solution.
Communicating with Websphere
(1)MQLink (store and
forward to a remote WMQ system):
This is achieved by having
WMQ has foreign bus in SIBus.
SIBus and WMQ queue manager
are connected by a pair of sender and receiver channels.
One of best real world example is geographically dispersed sites, such
as retail stores. The stores run WAS applications that need to (asynchronously)
send data to HQ. The backend systems at HQ are running on MQ.
To achieve continuity of retail operations, the application must be able
to continue to process work and send messages even if the store loses
connectivity with the HQ. The application has to persist the messages and sent
when connectivity is re-established. The store therefore needs an asynchronous
messaging capability on-site, rather than using a remote (synchronous) client
MQLink is perfect solution for these types of scenarios as it uses store
and forward mechanism.
(2) WMQ server as bus
This is achieved by adding WMQ
queue manager or queue sharing group as bus member. This allows convenient
access to WMQ queue from SIBus and allows closer integration between SIBus and
Messaging applications can directly produce
messages to, and consume messages from WMQ queues. MDBs can be configured to process messages as
soon as they arrive at the WMQ queue. Also, SIBus mediations can process messages as they arrive at a WMQ queue.
However there are two big disadvantages:
When WMQ queue is not
available applications can not send messages.
No support for Pub-Sub.
Disclaimer :The postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions.