Message Patterns and Interoperability

Messaging Patterns

Roger Costello has facilitated a number of interesting XML-DEV discussions on defining best practices for W3C XML Schemas (XSD). Costello's compilation of collected wisdom is quickly becoming a reference of choice for XSD users. This week Costello prompted a discussion on types of web services, of which he identified two alternatives depending on whether they are action or data oriented.

Costello defined action-oriented messaging as basically a procedure call, i.e. an action identifier that defined the intent of the message and a number of parameters. Data-oriented messages simply carry data, with the intent of the message being determined independently of the message. Costello invited comment on the pros and cons of each message type, explaining that the general approach adopted by web service designers would have "serious implications on the nature of Web services". Costello also offered his own opinion that data-oriented messaging was "intuitively...the right approach".

Noting that the message intent must be defined by some extraneous mechanism, Michael Kay stated a preference for identifying actions within the message.

If you send a data message, without any indication of why you are sending it, then there must be something extraneous to the message itself that indicates the purpose of the message and what you expect to happen to it. For example, this may be implied by the URL or other destination that you send the message to.

I prefer to have the action included as part of the message rather than being implied by context, so I have used techniques like including an attribute such as action="add|update|delete|find" on the outermost element.

Michael Brennan suggested that one advantage of action-oriented messaging is that it supports richer types of message that, for example, define multiple actions. Another advantage is that the message is self-contained, making it easier to use in other environments. Brennan suggested that the main disadvantage is that the message must be read before dispatching.

A message dispatcher must sniff the content of the message to discern its intent. A protocol-level indicator can help optimize some level of message dispatching, where dispatching can be done without having to parse the XML in the message.

It was for this reason that SOAP defined the mandatory SOAP-Action header. Paul Prescod observed that a further disadvantage of action-oriented messaging is that it becomes harder to reuse standardized vocabularies.

[Y]ou've mixed "protocol" (actions) with "data" (the content of the message). This makes it hard to use predefined vocabularies like RSS or some industry-specific one. I think that's a big problem. Using a model where the action is separate from the message, you can easily apply the same action to RSS, XHTML...

This prompted Costello to suggest applying the head-body pattern to messages in order to cleanly separate the actions (metadata) from the data being acted upon. Costello provided an example to illustrate the pattern, and he listed some potential benefits, particularly the ability to reuse existing vocabularies in new ways.

...We can capitalize on existing industry DTDs and XML Schemas. For example, the cellphone DTD defines how to structure cellphone data. There are lots of existing instance documents conforming to cellphone.dtd. Web services can be created to provide services for those instance documents. The data format has already been defined. All the service needs to do is define actions on that data format.

The discussion is reminiscent of the RPC versus asynchronous messaging debate which was reported in a recent XML-Deviant column. Roger Costello expressed his own fears over the rise of RPC systems.

Share your views about XML messaging and web services interoperability in our forums. Post your comments

I am very concerned that people will use web services simply as another way to do tightly coupled RPC, i.e., procedure name plus parameters. I think that XML-based web services should provide a new paradigm, where the focus is on the data and business processes. I think that this involves a rather large mental shift...

I am looking/searching for a paradigm which will FORCE developers to make that mental shift. I have a gut feeling that requiring the separation of the data from the action will be such a driving force.

Not everyone believed that messages which describe their intentions are necessarily RPC calls. Michael Brennan suggested that there is a finer-grain distinction to be made, with RPC being only one kind of action-oriented messaging.

The way I was interpreting this is data-oriented = one-way messaging. You fire off some information and you don't care what gets done with it. Very loose couplings between systems, very scalable. It's an ideal approach when you can get away with it. Action-oriented = request/response messaging, although the response does not necessarily need to be synchronous. There is simply an expectation on the part of the publisher of the message that there is an endpoint receiving this message that will fulfill the intent of the message, and will provide an appropriate response. RPC is just one narrow case of "action-oriented" in this view.

Brennan later argued that messaging at this level of abstraction "is aligned with business processes, not programming-level interfaces". According to Bill de Hora the distinction between data and action-oriented messaging was in the assumptions made by the sender of the data:

• data: the emitter doesn't assume how the message is to be processed.
• action: the emitter assumes the message will be processed according to its understanding of a verb.

It's likely that there are a number of different design trade-offs being discussed here that are being lumped under a single heading. The appropriate level of abstraction for messages and the interaction patterns for their exchange (e.g. publish-subscribe, request-response, etc.) seem to be two obvious topics. In addition to these there are several ways in which them messages themselves may be structured. Michael Brennan suggested drawing out the implications of different approaches is more likely to yield a pattern catalog rather than a single optimal design for web services. The REST architecture, described by Paul Prescod in last week's issue of XML.com, will be another good source of design patterns.

A key benefit of discovering patterns is that they provide a common terminology for communicating issues and trade-offs. The nascent state of web services means that this terminology has still to be refined. Indeed the term 'web service' itself seems to be used to describe a number of different types of applications from, at one end of the spectrum, an evolution beyond web interfaces which use URL encoded parameters through to complex, orchestrated business processes. While one doesn't preclude the other, the requirements for each are quite different.

Interoperability

Also in XML-Deviant

The More Things Change

Agile XML

Composition

Apple Watch

Life After Ajax?

There's been a flurry of press releases and news reports surrounding the announcement of the Web Services Interoperability Organization (WS-I) recently.

According to the limited material currently available on the web site, WS-I aims to foster interoperability in the web service community by carrying out tests of web service toolkits, runtimes, and individual services. Levels of interoperability will be badged using 'Profiles', which are a collection of relevant specifications deemed to be important by the WS-I members. The intention is that only a small number of profiles will be defined, but these will be updated as the specifications and the market matures. (Once could cynically add development of the members products as a third driver to this list). WS-I is pitching itself as a 'standards integrator'.

However, despite the intention stated in the WS-I Profiles introduction (PDF) to avoid requiring "some web service products to be forced to add unneeded features simply to conform to some Profile and assert interoperability", the WS-I Basic Profile includes far more than one reasonably needs to create web services. The Profile lists XML Schema, WSL 1.0, SOAP 1.0, and UDDI 2.0 as "providing the basic functionality provided for developing web services". This runs counter to efforts such as "DIY web services" which aim to make web services more amenable using less technology.

Some of the WS-I's work seems to overlap with existing grassroots efforts, e.g. SoapBuilders. Sam Ruby recently posted a message to the SoapBuilders list that suggests that "in addition to the SOAP standard, we need to document a set of best practices and a create classification of errors that identify potential interoperability issues." The WS-I will be defining best practices for each of its published standards Profiles.

Reaction to the announcement on XML-DEV was typically mixed. Several contributors believed that the organization has emerged due to the slow rate of progress at the W3C, and, as Michael Brennan suggested, the desire for vendors to acquire a standards compliant mark for their products.

...I get the distinct impression that web services specs are the hostage of a heated vendor war to be the first to really rake in bucks selling web service tools and servers. The vendors are thrashing about in a frenzy looking for that quick rubber stamp on a "standard compliant" label they can stick to their products.

It would probably be a good thing to keep this out of the W3C until things cool down.

Michael Champion was cautiously optimistic and suggested that a focus on interoperability was a good thing.

...Look at it on the bright side; 10 years ago everyone would be forming their own pet "standards" organization and not giving two cents about interoperability. Or perhaps issuing dueling press releases proclaiming that We implement the true standard and They don't. The Web (and we do have to give the W3C a lot of credit here) raised the bar considerably -- it's considered "standard" if it interoperates.

And it's hard to argue with that, although inevitably the WS-I is sure to draw flak because of it's 'Big Company' membership.