I like your comparison of Web services with message queues. However, isn't it possible to implement Web services...
using message queues? Couldn't SOAP messages be transported via MQSeries persistent queues to gain their guaranteed message delivery? Since I have not worked yet with any of these scenarios, my posting is mere theory. I'd be curious to hear what you think. In terms of transactional support, I wouldn't say message queuing in and of itself provides transactionality. As you alluded, there needs to be a message server or broker involved. If SOAP messages are sent through a message queueing system, then the corresponding services can be orchestrated through a broker or process automation server as part of a transactional business process.
A. MQ Series works by having a queue manager on each system. The queue manager handles message delivery and things like data type translation. XML is a common format for the message because it is self-describing and can be written to a common DTD or schema. While you can send SOAP messages, I'm not sure what the specific advantages would be, since the queue managers handle all the cross-platform issues. Messages can also be sent synchronously or asynchronously. To do that with a Web service requires extra code (although .NET makes it relatively straightforward).
So then, why wouldn't you always use something like MQ Series?
1. It is non-trivial to implement. MQ has a lot of capability, but with that capability comes complexity. There are companies who do nothing but MQ implementations.
2. It is relatively expensive. In an enterprise environment, the cost of MQ Series can certainly be more than made up for through the benefits it offers. In a smaller application, that is not the case.
3. It provides much more than a simple way to connect two disparate systems. The fact that MQ connects systems is only a small part of the benefits it provides. It is overkill for many applications.
4. Typically, you must have an MQ client application on each system. That may not be possible or desirable.
Why use Web services?
1. They are relatively simple and straight forward to build and implement. The complexity level is fairly low.
2. It is inexpensive. There is nothing to buy. No extra software or hardware. Just code and go.
3. It uses standard protocols and transports. You do not need a special client application on each system. Just a simple proxy application which many development environments will create for you.
Dig Deeper on Enterprise Application Integration (EAI)
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.