[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

REST, SOAP, Speech Acts and the mustUnderstand model of SOA communicatio

  • To: xml-dev@l...
  • Subject: REST, SOAP, Speech Acts and the mustUnderstand model of SOA communications(was: Re: What Does SOAP/WS Do that A REST System Can't?)
  • From: Sean McGrath <sean.mcgrath@p...>
  • Date: Fri, 01 Apr 2005 08:21:05 +0100
  • Organization: Propylon
  • Reply-to: sean.mcgrath@p...
  • User-agent: Mozilla Thunderbird 0.6 (Windows/20040502)

rest soap
Whatever about the pros and cons of REST versus SOAP, I think it is
abundantly clear that the mustUnderstand model [1] is a key concept in
developing loosely coupled systems that can evolve independently.

I would like to suggest that the mustUnderstand model is sufficiently
important that it should be added to the xml namespace alongside
xml:space and xml:lang.

I'm a big fan of conceptualising XML message exchange in terms of
Speech Acts[2]. To make the most of the power of this abstraction, I
think it is necessary to extend the coarse boolean mustUnderstand
model into a more fine grained model that matches the way speech acts
are used in the real world.

I would like to suggest that xml:mustUnderstand be an enumeration with
a number of positive integer values, the semantics of which, should be
part of the specification. I can think of five.

Additions/comments on these welcome:


xml:mustUnderstand="0" - It is permissable for the recipient to not
understand the message fragment. No specific directions about the
speech act semantics in this case.

xml:mustUnderstand="1" - The message fragment must be understood,
otherwise the conversation must fail.

xml:mustUnderstand="2" - reciever must claim to understand, even if it
does not. The sender should have not be able to tell whether or not
the receiver really understands or is simply claiming to
understand. This is particularly useful in the service industries.

xml:mustUnderstand="3" - receiver may at first issue one or more
failure responses indicating that it does not understand the message
fragment. Then, without any action from the sender other than retries,
the receiver begins to understand the message fragment. This has many
applications in the political arena.

xml:mustUnderstand="4" - reciever may claim to understand the message
fragment one or more times and then begin issuing failure
responses. The failure responses should indicate that the message was
never understood and assert that the receivers behavior has been
consistent in this regard all along. This has many applications in the
media and in academia.

xml:mustUnderstand="5" - reciever may claim not to understand but,
unknown to the sender, may act upon the message fragment. This has
many applications in e-commerce.


Thoughts?

Sean
seanmcgrath.blogspot.com

[1]
http://www.pacificspirit.com/blog/2004/07/27/dare%20versioning%20extensibility%20article%20comparison

[2]
http://www.manageability.org/blog/stuff/the-restfulness-of-speech-acts/view


 



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.