IBM Message Queue Notes
Choosing a messaging system: WebSphere MQ vs. the WebSphere Application Server Service Integration Bus
Taken from here
If your organization does not have an existing messaging infrastructure, or is migrating from other messaging systems to either WebSphere MQ or an SIBus, then your choice of messaging system should be influenced by the considerations described below. The foremost consideration is to select the messaging system that has the operational characteristics you require. The choice of JMS provider will follow. After you have selected your messaging system, your options are similar to the ones described above. You would normally use the default messaging provider to connect to an SIBus, or use the WebSphere MQ JMS provider to connect directly to WebSphere MQ.
Runtime environment and platform
If your application is running in a WebSphere Application Server Java EE environment, then its integration with WebSphere Application Server makes an SIBus a natural fit. If your environment is heterogeneous (including WebSphere Application Server and other non-Java technologies) then use WebSphere MQ. For example, if you are using WebSphere Message Broker or CICS, then WebSphere MQ is a natural choice. The physical platform on which your applications are running is not generally a significant factor, as both the SIBus and WebSphere MQ support a broad range of platforms.
Programming language
WebSphere MQ supports a wide range of programming languages. SIBus programming support consists primarily of JMS, although the SIBus does support C, C++, and C# through the IBM Message Service Clients for C/C++ and .NET, known as XMS. For more information, see the developerWorks article Introducing XMS -- The IBM Message Service API.
Monitoring tools
WebSphere MQ is a well-established product with a huge install base and a wide range of tooling support, including many excellent monitoring and management tools from both IBM and third parties.
Integration vs. isolation
The SIBus uses the WebSphere Application Server runtime, console, and command interfaces, which may be a benefit due to the integration of configuration and administration between WebSphere Application Server and the messaging system. Alternatively, you may prefer to use WebSphere MQ, because it does not run in the WebSphere Application Server process. As a result, you can offload the message processing into a separate process group isolated from WebSphere Application Server, so that it does not affect the JVM heap or other resources that are important to the WebSphere Application Server process and its deployed applications. Isolation may also simplify tuning, and can reduce the startup time of the application server.
High availability (HA)
A key consideration for HA is the downtime experienced when a failure occurs. Either the SIBus or WebSphere MQ can start quickly from a quiesced state in which it has relatively empty queues, but WebSphere MQ will typically start more quickly when there is a high volume of stored messages.
The way that you detect failures and orchestrate restarts depends on which messaging system you use. Both SIBus and WebSphere MQ failover can be managed by an external HA cluster framework, such as High Availability Cluster Multi-Processing (HACMP) or Veritas Cluster Server (VCS). An external HA cluster can be a good solution when integrating the messaging system into the resource management in your production environment. Where you don't need that integration, both the SIBus and WebSphere MQ have additional HA support that avoids the need for external clustering.
An SIBus messaging engine automatically exploits the built-in HA support in a WebSphere Application Server Network Deployment (ND) cluster. HA is therefore very easy to set up, and is the default in a cluster bus member.
WebSphere MQ V7.0.1 or later has an integrated HA mechanism that enables two machines to cooperatively run instances of a queue manager and perform a seamless failover when needed.
At the edges of your environment, where your messaging system interacts with the messaging system in another organization such as a business partner, the remote queue managers or messaging engines will connect to yours using an IP address. It is important to maintain the correlation between that IP address and the WebSphere MQ queue manager or SIBus messaging engine with which it is associated. A simple addressing scheme helps to isolate your external partners from your network topology, because it prevents them from needing to configure and maintain channel exits or search lists that reflect your topology. Affinity can be maintained with an external HA cluster framework somewhat more easily with WebSphere MQ than with an SIBus.
Message traffic profile
If you are using large messages, then WebSphere MQ may be a better choice. WebSphere MQ has an architectural limit on message size of 100 MB, and WebSphere MQ owns and controls its memory and can be tuned according to the message profile. An SIBus has no architected limit, and the empirical maximum is 40 MB on 32-bit systems and 80 MB on 64-bit systems. Because there is no hard limit, an SIBus is not as well isolated from the demands placed on the JVM heap by applications or other services. For an SIBus, a build-up of large messages (such as when a link is down) will place a lot of stress on the JVM heap.
Performance and scalability
As of Sep. 2011, performance of WebSphere MQ persistent messages is approximately twice as fast as SIBus persistent messages. There is little difference for non-persistent messages.
WebSphere MQ supports clustering of queue managers for enhanced throughput and scalability of administration. There are many examples of production clusters containing thousands of queue managers. WebSphere MQ clustering is extremely flexible, supporting selective parallelism of cluster queues, enabling you to independently tailor the number of instances of each cluster queue. SIBus messaging engines can be clustered within a WebSphere Application Server cluster for throughput and administrative scalability. However, a WebSphere Application Server cluster has a much lower scalability limit than a WebSphere MQ cluster, and if a queue is assigned to a WebSphere Application Server cluster bus member, it is partitioned across all messaging engines in the cluster – you cannot selectively locate partitions.
Cost
The SIBus is a component of WebSphere Application Server and therefore does not incur any additional cost, while WebSphere MQ is a separately licensed product. As of Sep. 2011, both products are sold on a capacity-based pricing model, and to form a meaningful comparison you would need to calculate the approximate capacity you would need for each product. Performance reports available from IBM can help you with this comparison.
MQ Basics
/usr/mqm/bin
list queues and que manager - dspmq
strmqm WAS_ictpolling01_server1
WebSphere MQ queue manager 'WAS_ictpolling01_server1' started.
after starting connect to it
runmqsc WAS_ictpolling01_server1
(no prompt symbol will be shown)
dis ql('WQ_itim_*') CURDEPTH
If any of these returns a CURDEPTH value greater than zero then there are still messages being processed. If it is necessary to purge a queue/s of current messages you must stop WAS first. If you don't you will likely see a response like "AMQ8148: WebSphere MQ object in use." when you attempt clear the queue/s. The process of clearing the queues of existing messages will remove activities that have been generated by ITIM, so it is possible that complete requests may be removed and will need to be resubmitted. To clear a queue of existing messages type
clear ql('WQ_itim_wf')
at the mqsc prompt (where the "WQ_itim_wf" queue was the queue with message content in our example above). Use
dis ql('WQ_itim_*') CURDEPTH
command again to confirm the messages in the queue have been purged.
@TechnicalNotes @IBM
