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 examples.
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 component.
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 MDBs)) involved document processing and printing software with high licence costs. Hence has to be separated from core messaging.
· 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 MQ (WMQ)
(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 connection.
MQLink is perfect solution for these types of scenarios as it uses store and forward mechanism.
(2) WMQ server as bus member:
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 WMQ.