Scott Hanselman

Classic Web Services versus POX XML over MQ - are you really using XML?

February 07, 2006 Comment on this post [7] Posted in eFinance | XML | Web Services | Tools
Sponsored By

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.
  • If you embed a flat file within a CDATA section, you might not be using XML.

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.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
February 07, 2006 8:58
Hilarious. I love your redneck-esque "you might be"'s. I've totaly seen all of that in the services, and formats I have to deal with. I'm going to use "angle-bracket-delimited" from now on to refer to these abominations.
February 08, 2006 2:20

I'm not sure I'm getting what the encoding issue has to do with XML at all. This is a text encoding issue that could prevent you from processing flat files just as well. The truth is, text encodings are a PITA, and in most cases, unless you've agreed (implicitly or explicitly) on the encoding to use, or there's something *outside* the XML payload (for example, the HTTP headers, or some other out-of-band mechanism) that designates the encoding to use, it's a real troublemaker.

Besides, as far as I understand it, the whole encoding tag in the <?xml?> directive is purely information, because to be useful when you're using different encodings it requires that the content is mixed encoding (i.e. the <?xml?> declaration in a standard encoding like ascii or utf-7/8 and the rest of the document in the encoding specified with the encoding attribute. Not very nice, and at the very least somewhat unconfortable to work with in most platforms (including .NET)
Other than that, all good points :)
February 08, 2006 3:07
Tomas - I'm highlighting that the underlying assumptions around correct encoding is often ignored when dealing with XML using non-standard parsing tools. I'm saying that folks often push around XML they "say" is UTF-8 when it's just ASCII, then when you REALLY give them UTF-8, they bork.

I'm saying that before one starts using "XML 1.0" they should understand the encoding assumptions underneath.
February 08, 2006 18:39
Ahh, then we are totally in agreement :) I've had to battle that same thing quite a few times :)
February 09, 2006 20:31
I think this starts to get interesting when you start to think about MQ as in WebSphere MQ and not MSMQ. In a land far from St. Helens, let's call it work in downtown PDX, we have a big expensive 'slow a$$/400' and not a single http request/response to be found, but we do have a extensive MQ network between the 400, Windows and Unix. Given that a) we do have the big IBM box that assumes that there must be a ton on data on it that other systems could us and b) RPG is just now learning XML well then that might be an interesting alternative to the same ol' DB2 provider down the road sometime.
February 15, 2006 6:05

It's unclear to me why the choice is framed as SOAP/HTTP vs MQ. MSMQ beginning with v3 supports SRMP protocol, which IS SOAP/HTTP. So there's really no sacrifices to be made.
February 15, 2006 6:18
Eugene, sure, but MQ (not MSMQ) and other queues may not offer the HTTP envelope as an option.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.