Our CTO, Chris Brooks, was asked recently about the pros and cons of using "classic" Web Services (SOAP over HTTP) versus XML over MQ (Message Queuing). This is a common question amongst folks with existing back ends. Often folks argue that SOAP incurs significant overhead versus POX (Plain Old XML). Here was his answer, reprinted without asking, but I'm pretty sure he won't mind.:
First, you need to draw a clear distinction between message format and transport.
For message format, you can go with "plain old XML" (aka POX) without a SOAP envelope, or with SOAP formatted messages. The primary difference will be that there will be a SOAP envelope on the SOAP message, and the message itself will occur within the body element. There isn't a significant amount of overhead for using SOAP over POX - you are really just talking about one nested element. When using SOAP, you retain the possibility of adding headers that might be used for a number of purposes including routing, security/encryption/signing, and transactions. Note that this choice is independent of the choice of HTTP vs. MQ Series - either transport can be used to carry either type of message. Our recommendation is to use SOAP - it will have a very small impact on bandwidth and processing time and buys you flexibility.
For the transport layer, it ultimately will come down to what you are most comfortable with in your enterprise. The advantage of sticking to SOAP over HTTP is that the tool support (both development and management) will be much stronger. While web services are in theory supposed to be transport-neutral, HTTP is certainly the "first among equals" choice. MQ is a good choice when you need to support guaranteed messaging or if your own testing has demonstrated that you have higher scalability and/or throughput for the volumes you are seeing.
My recommendation is to start with SOAP over HTTP and to consider alternatives only after measuring performance and planning for the sort of capacity you will need. - Chris Brooks
I think he's pretty much right on. One thing I would add about POX though that will often get you is that there's a big difference, IMHO, between true POX, whether you do it the REST way or not, and pushing what I call "angle-bracket-delimited files" around.
Here's a few (tongue in cheek) hints that you might be be moving angle-bracket-delimited files from place to place:
-
If you say <?xml encoding="UTF-8" version="1.0"> but your POX endpoint chokes on a
Unicode BOM, you might want to ask yourself, are we REALLY pushing XML around or are we just lying to ourselves?
-
If most of your XML parsing code consists of string.IndexOf() you might not using XML.
-
If you don't include an XML <?xml> prolog, you might not be using XML.
-
If you don't use any namespaces, but you include a schema, you might not be using XML effectively.
-
The Moral of the story is, if you are pushing XML around, regardless of how you're doing it, do try to use official, supported XML parsers, DOM implementations and SOAP stacks, rather than rolling your own. Do, try to use namespaces and strongly type your data.
As far as transport goes and the benefits of at least trying to get SOAP into your organization, Mike Champion said it well four years ago:
The beauty of SOAP, IMHO, is that it is both a transport-neutral [and I use the term advisedly!] application-level protocol and "just another XML format" that can be delivered using HTTP application semantics. RESTafarians can see the glass as being half-empty (because it is perfectly legal for SOAP to tunnel HTTP), but you could also see it as half-full (because SOAP lets XML and HTTP get a foot in the door, allowing users to move to more web-friendly scenarios once the knowledge and security infrastructure are in place].
Personally, it's not a glass half-full or half-empty situation, I think there's too much glass.
Hosting By
The TopDesk 1.4.1 task switching software I