This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Things you can do with an XML message

Stefan Tilkov,

In a very interesting comment thread over at Steve Vinoski’s, Michi Henning writes (with regards to XML messaging):

So, as far as I can see, the difference is one of syntax. With IIOP, we encode the data as binary, so it’s not possible for me to interpret the data without a priori knowledge of its encoding. With XML, we encode the data in a universal syntax, but it is also not possible for me to interpret the data without a priori knowledge; not of its encoding, but of its semantics. What I am getting at here is that the ability to get an XML message off the wire without type-specific knowledge doesn’t fundamentally alter the core issue, namely, that the receiver must have knowledge of the semantics of the data in order to do something useful with it; whether the data is encoded as binary or XML seems to be a second-order issue. In other words, the agreement you mention goes way beyond mere syntax.

I disagree. Here’s just a few things I can think of that you can do with the XML, but not with the IIOP

  1. look at and read it
  2. store it
  3. hand it over to any of the gazillion XML-processing tools
  4. check it for well-formedness
  5. run an XSLT transform on it
  6. perform XPath expressions on it
  7. validate it against one or more schema
  8. run XQuery on it
  9. select parts of at that you do understand (e.g. via XPath) and process them
  10. encrypt or decrypt it, partially or completely
  11. sign or check the signature on parts of it

I can do all of this without knowing any of the message’s business semantics. (Some of the examples like the XSL transform will usually have to know something about the message, but that does not mean my message handler has to.)

Sure you can do all of this using CORBA. All you have to do is standardize on some variant of a tree/key-value structure and create an ecosystem around it :-)

On October 19, 2005 12:54 AM, diego sevilla said:

Interesting post, Stefan. However, take into account that you’re considering XML for message exchange in the context of an application. In this context, what does all the points you introduce have interest? Why, for example, process using XSLT a message exchanged between two parties? I could go number by number, but, for example, you can store the IIOP message the same you can store the XML message. It’s just a blob of data. As for processing it using other tools like XQuery and such, take into account that the purpose of XML messages (as IIOP ones) is to ask an application for something.

From your response I can see in which contexts XML is good: all the processing you’re mentioning is really nice in other contexts. But in the context of message exchange (call it RPC, MOM, SOM), XQuerying it or being able to search it is of no value.

Note that I am talking about the message itself, not the payload. If you want to send structured information, you can send XML, of course. But you can include text messages including XML bits into IIOP too!! :)

Best regards, diego.

On October 19, 2005 6:53 PM, grumpY! said:

IIOP??? haha yes i have a great setup. i have some lisp-machines talking to each other via IIOP over an OSI-compliant frame-relay network. if i concentrate hard enough i hope to get everyone to go back to 1997 with me.

On October 19, 2005 8:53 PM, Stefan Tilkov said:

@Diego — I think you have hit the nail on the head without even noticing :-)

If none of the things I mentioned are useful for you, you shouldn’t be using XML messaging in the first place. You may be better off using CORBA.

I do, of course, believe that these things make sense when you do message exchange between applications. You can XSLT for message transformation, e.g. adapting a new format to an older application or vice versa. You can do XPath to build change-resilient processing nodes, or introduce intermediaries that perform some processing using XQuery. You can do content-based routing by applying configurable XPath expressions to the content.

Again, my point is: There’s lots of things you can do with XML that you can’t do when you use IIOP. If you use XML as CORBA with angle brackets, you’re obviously going to be disappointed. If you decide to use XML, do so for a reason and don’t treat it as an implementation detail.

@grumpY!: Don’t be so … grumpy ;-)

On October 21, 2005 12:05 PM, Lou said:

I can do all of this without knowing any of the message’s business semantics.

And achieve what purpose ? Credit to an account when it is to be debited from ?

select parts of at that you do understand (e.g. via XPath) and process them

This is a meritless achievement. How could you possibly conclude that the pieces you can understand are completely independent of that part of the context you don’t understand ?

On October 21, 2005 3:14 PM, Stefan Tilkov said:

The real world works based on partial understanding. Work is distributed based on address information or a glance at a topic; while one “processing node” takes care about the business details, another will manage the technical aspects. Ignoring this, and demanding complete understanding for everyone involved — even if they don’t use and don’t care about large parts — is what creates tightly and inflexibily coupled systems.

As an example of a useful intermediary that I can built without understanding the message’s semantics (or even knowing them before-hand) is content-based routing: an engine runs (externally configured) XPath expressions against the messages and dispatches according to (externally configured) destinations.