1. WebSphere MQ Competitive Overview
Sonic Software
WebSphere MQ Competitive Overview
Purpose:
Show how although IBM has a good product, in many respects we are better…………
Bob Trabucchi

2. Agenda MQSeries 5.2 Competitive Postmortem WebSphereMQ 5.3
Competing against WebSphere MQ 5.3

3. IBM MQSeries 65+% market share Over 3,000 international customers
Integration for 35+ platforms
Considered ‘de facto’ standard for reliable messaging
Currently used by most fortune 500 companies
What we knew about IBM already…………

4. MQSeries 5.2 Released in January 2001
Claim improved performance for persistent messaging (factor of 5)
Not standards based (proprietary API’s)
JMS wrapper supplied with product
Pub/sub not supported on all platforms
Clustered servers, load balancing and ‘hot standby’
What we thought we are differentiators for 5.2……….

5. MQSeries 5.2 Landmines Slow performance High cost of ownership.
Limited Pub/Sub queue-based model
JMS wrapper – not integrated
Limited Internet usefulness
Mom product at core
Limited XML support
These are the product weaknesses that we have believed in the past would give us the most traction vs. MQSeries.
Mention:
High TOC – it’s obviously harder to use and deploy, TOC should be a big differentiaitor. However, we have No numbers
MOM product at the core – we had a new, optimized implementation

6. Reality Check MOM product at the core can be a plus!
Proven track record
Fortune 500 have MQSeries expertise
doesn’t matter if it’s bogus to use.
MQSeries site licenses hide costs from groups doing implementation.
Internet use to date is not a big differentiator.
Utlimately with shops that have MQSeries, they are used to doing things the hard way, so ease of use is not an issue.
The perception is: you can do everything with MQSeries, it’s just really hard, and hard to maintain sometimes.
FIDELITY EXAMPLE

7. Reality Check Performance is still king!
Security and guaranteed delivery are extremely important.
Performance is still largely the thing that gets us in the door, although security and guaranteed delivery are becoming more important.

8. Agenda MQSeries 5.2 Competitive Postmortem WebSphereMQ 5.3
Competing against Websphere MQ 5.3
Reality check – discuss the results of the North American sales calls were.

9. Scope of work Goals of 6 week effort: Work in progress!
Assume the role of customer and evaluate the WebSphere MQ 5.3 experience.
Develop test harness to exercise both products on a level playing field
Produce proof points that give sales force improved competitive traction
The goal of our efforts to date:
Experience the products first hand, and experience the joys and pains of the products
Assume the role of customer and evaluate the WebSphere MQ 5.3 experience.
Develop test harness to exercise both products on a level playing field
Produce proof points that give sales force improved competitive traction
Work in progress!

10. MQSeries 5.3 Beta released May 24th, 2002
Improved JMS specific performance
Improved security story
Allows SSL-based encryption vs. 3rd-party only
JMS fully integrated within product
Improved support for clustered queue managers
Workload balancing
Connection failover
Here is what IBM is claiming is new and improved in Websphere 5.3

11. WebSphere MQ OOBE
Building point-to-point, queue-based is equally easy in both SonicMQ and Websphere MQ products.
GUI Explorer tools
Create, start, stop queue managers
Create and manage queues
This gives the initial impression to the uneducated consumer that the products are equal, which they are not.

12. WebSphere MQ Explorer
For example, they both have a MMC-based, gui tool that makes using Ptp, queue-based apps easy to use and maintain………….

13. SonicMQ Explorer
Here is ours……….

14. WebSphere MQ 5.3 weakness
Pub/Sub is still not integrated and frustrating to use
No tutorials or documentation for Java
Supplemental download (uses same as 5.2)
Complete ‘add-on’ architecture
Not integrated with admin tools
Trouble shooting is cryptic
Using topics is problematic
No topic heirarchies
No cluster-wide topics
But there pub sub sucks to use, configure, and is problematic to use. Scalability of their pub/sub implementation is really questionable (see benchmark)
For example,
1. Topics cannot be shared among queue manangers. This means publishers and subscribers have to use the same queue manager.
2. Recent post on the ibm.software.websphere.mq.beta usenet news group:
We have an open call, PMR BR 004, reporting the issue where the Broker
doesn't refresh in ver 5.2 when subscribers stop subscribing or when new
subscribers join to listen on the same topic.
This can very easily be reproduced in ver 5.3 as well by running the sample
/opt/mqm/samp/java/jms/asf/TopicLoad, which publishes on a topic and by
running multiple subcriber samples, /opt/mqm/samp/java/jms/asf/ASFClient3.
Run say two copies of ASFClient3 then start the TopicLoad and once both
subscribers start to get the messages, stop and restart the ASFClient3. We
have seen the broker take upto 4 mins to recover.. which is unacceptable if
the publications are time sensitive.
In our own testing, we can into scalability problems using pub/sub that we didn’t encounter using ptp. 50 pub/ 50 sub/ 50 connection 10K tests caused broker failure.
Topic heirachies: nested levels of topics can be defined so that subscribers can refine the type of notifications they receive.
For example: Using topic heirarchies, a subscriber can subscribe to many subtopics by simply subscribing to a high level topic.

15. Java is an still and afterthought
Java is a second class citizen
Only two code samples
No Java-based tutorials
Sample Java pub/sub app doesn’t work in some cases (without JNDI)
MQSeries.net JMS newsgroup is useless.

16. WebSphere MQ 5.3 weakness We still have much better performance
We still have a better security story
We still have a better clustering story
Performance:
We will see later in this presentation.
Security:
They have now incorporated SSL into product with a limited number of cipher suites. User authentication and authorization still
Depend on third party products.
Clustering:
Clusters are statically defined. Meaning

17. MQSeries Terminology
Queue Manager – creates, manages and maintains queues
Clusters – grouping of queue managers that work cooperatively.
Participants exchange messages via named queues
Broker – a pub/sub server component that creates, manages, and maintains topics
Broker network – cluster of pub/sub brokers

18. WebSphere MQ PTP JMS Architecture
Sender
Receiver
Queue
Manager
Similar to our architecture

19. WebSphere MQ 5.3 Pub/Sub JMS Architecture
Publisher
Subscriber
Broker
Queue
Manager
WebSphere MQ utilizes a special support pack to implement pub/sub functions. The pack introduces the concept of the MQSeries Pub/Sub Broker.

20. WebSphere MQ 5.3 Pub/Sub JMS Architecture
Publisher
Subscriber
Broker
Subscribers send a special message to a control queue to tell it what topics it is interested in.
Publishers send a message that has info on
Topic to send to
Message to send to that topic
Broker does the work of sending.
Queue
Manager

21. Pub/Sub Broker responsibilities
Listen for publishers
Listen for subscribers
Maintain list of topics and subscribers
Maintain links with other brokers
Maintain links with queue manager

22. Pub/Sub Broker vs. Queue manager
Broker is a MQSeries application
Depends on Queue manager for all persistent storage and queue functions.
Massive Overhead !!!

23. WebSphere MQ Broker Network
Publisher
Subscriber
New York
Tokyo
Queue
Mgr 1
Broker
Queue
Mgr 2
Broker
To claim functionality similar to ours for Pub/Sub, IBM pushes the concept of the broker network. Again, because of limits no cluster wide topics, a failure in the New Yrok machine is catastrophic.
But communication is not done because the broker’s are aware of each other. They have a pub/sub relationship themselves that is itself a pub/sub application that must be built.

24. Agenda MQSeries 5.2 Competitive Postmortem WebSphereMQ 5.3
Competing against Websphere MQ 5.3
Reality check – discuss the results of the North American sales calls were.

25. Where do we win? Prospect needs:
Real-world publish/subscribe capabilities
Cares about high end performance
Worries about greater performance for secure applications.
Wants reliable, pub/sub cluster capabilities
Lower TCO

26. Performance: Where do we win?
High volume
Lots of concurrently connect clients
Lots of topics and queues
50+ is where the differences start to appear
The larger the message size, the better

27. Security: Where do we win?
Security topologies that must be highly performant
Variety of cipher suites
Flexible encryption options:
Per message, message-payload
Prospects with tight firewall restrictions

28. Clustering: Where do we win?
Pub/Sub environment
Broker network is no Queue Manager cluster!
Topics are not cluster wide.
No load balancing
No failover
Where administration resources are limited
Inflexible IP address hard coding required
Pub/Sub broker networks are lack competitive functionality: publishers and subscribers can be geographically dispersed through a broker network, but this requires hard-coded manual processes where brokers’s send ‘copies’ of their topics to other brokers.

29. Where do we lose? Prospect has: MQSeries experts in house
MQSeries site license
Unlimited coding resources
Queue-based point-to-point application requirements with small message sizes.
Total cost is of no concern

30. Where do we lose? SonicMQ performance is benchmarked using:
Connection time
Small numbers of messages
Small message sizes

31. SonicMQ vs. MQSeries win!
onStar is a actually a subsidiary of IBM, but they have been successful in going against the IBM bias in the past

32. OnStar Replaced 3rd party Primary use for pub/sub domain
Organization open to 3rd party products
Primary use for pub/sub domain
Clustering environment
topics need to be available cluster-wide
parallel load balanced queue processing
 C/C++ client

33. From the lab…….. Test Harness Test Configuration
Modified to run against standard WebSphere MQ 5.3 installation
Test Configuration
NT Server, 550 mhz, 4CPU
For QM, Broker’s etc.
2 NT 886 mhz, 2 CPU
1 to Receive/Subscribe
1 to Send/Publish
In order to backup the claims that I’ve just made, the current plan is to spend a lot more time in the lab, proving with quantified results these things that I’ve just gone over with you. Today we show you the first steps in that work and give you and idea about things to come.

34. SonicMQ V4.0 v MQ Series 5.3 Point-to-Point Persistent Non Persistent
1400
1500
1000
1000
Slide Purpose: Illustrate Sonics performance and scalability
Main message(s): There are two big reasons for these numbers: our optimized JMS implementation , and IBM’s poor JMS wrapper implementation
Script:
To measure how Sonic Software compares to other messaging products that have a good reputation, we conducted a recent benchmark comparing SonicMQ 4.0 to IBM MQSeries Although 5.3 did better than 5.2, we still were better for both 1K and 10 K message sizes. Significantly better.
From the big red bars you can clearly see that we significantly out perform IBM in every test in both a point-to-point and durable pub/sub configuration.
There are two reasons for this:
1. OUR DRA - Our patent pending Dynamic Routing Architecture which enables Sonic to Load balance and provide optimum performance
IBM = API WRAPPER. IBM’s JMS implementation is implemented by using a API wrapper layered upon it’s traditional MOM product. This adds extra
layers of complexity to their product that significantly slow down their performance.
600
500
200 1k
10k 1k
10k
Message Size
Message Size
SonicMQ 4.0
MQSeries 5.3
SonicMQ 4.0
MQSeries 5.3

35. SonicMQ V4.0 v MQ Series 5.3 Pub/Sub Persistent Non Persistent
8000
8000
6000
6000
Slide Purpose: Illustrate Sonics performance and scalability
Main message(s): There are two big reasons for these numbers: our optimized single broker implementation and IBM’s poor pub/sub JMS implementation
Script:
To measure how Sonic Software compares to other messaging products that have a good reputation, we conducted a recent benchmark comparing SonicMQ 4.0 to IBM MQSeries 5.2
From the big red bars you can clearly see that we significantly out perform IBM in every test in both a point-to-point and durable pub/sub configuration.
There are two reasons for this:
1. OUR DRA - Our patent pending Dynamic Routing Architecture which enables Sonic to Load balance and provide optimum performance
IBM = API WRAPPER. IBM’s JMS implementation is implemented by using a API wrapper layered upon it’s traditional MOM product. This adds extra
layers of complexity to their product that significantly slow down their performance.
4000
4000
2000
2000 1k
10k 1k
10k
Message Size
Message Size
SonicMQ 4.0
MQSeries 5.3
SonicMQ 4.0
MQSeries 5.3

36. Recap: Where we win……
Need highly performant pub/sub with real clustering capabilities
Performance critical architectures
Require security were there is currently none.
Require security with high performance
TCO matters
Where Cost matters.
Can’t afford admin, can’t afford lots of developers and lots of maintenance.

37. Still to come……..
Competitive info for Websphere MQ is a work in progress:
No durable subscription numbers
No reliability numbers/data
Need to test secure configurations
Need to test clustering capabilities
Work that still needs to be done!
To contact Bob for more info:

38. WebSphere MQ Competitive Overview
Sonic Software
WebSphere MQ Competitive Overview
Script:
I’m ____ from Sonic Software. Sonic Software is the world’s fastest growing Internet middleware company. I would like to introduce you to Sonic Software, and discuss how our products and solutions can maximize your IT investment, increase your competitive positioning, and increase customer satisfaction.
Now is also a great time to take some polls to get a feel for your audience. Your goal is to better understand 3 things, their familiarity with Sonic Software and its products, their knowledge of Messaging and Web Services, and what integration and development products they currently use.
Now you should have a better understanding of hot topics (i.e., competitive issues), messaging and web services familiarity (i.e., this determines your depth for discussing terms like SOAP, WSDL, Topics, Itineraries.).
Bob Trabucchi