[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsia] Fwd: Re: [xml-dev] Categories of Web Service messages:data-oriented vs action-oriented
Hi All, I seldom cross post, or forward between lists unless I think some item is of particular interest to the group I am cross-posting to, and in this case, I think this particular message condenses a long thread that I have been watching for a while, and which bears on our work. Sometimes I wish xml-dev would close up shop and go on vacation for a year or so and let the rest of us catch up before they start changing things on us, and this case isn't all THAT crucial, but it could cause a bit of consternation down the line. Since a lot of our work is going to be concerned with how messages get wired together behind the scenes, this might prompt some of you to express an opinion to the xml-dev list. Ciao, Rex >X-From_: xml-dev-return-3996-rexb=starbourne.com@lists.xml.org Wed >Feb 6 06:24:29 2002 >Mailing-List: contact xml-dev-help@lists.xml.org; run by ezmlm >X-No-Archive: yes >List-Post: <mailto:xml-dev@lists.xml.org> >List-Help: <mailto:xml-dev-help@lists.xml.org> >List-Unsubscribe: <mailto:xml-dev-unsubscribe@lists.xml.org> >List-Subscribe: <mailto:xml-dev-subscribe@lists.xml.org> >Delivered-To: mailing list xml-dev@lists.xml.org >Date: Wed, 06 Feb 2002 09:29:48 -0500 >From: "Roger L. Costello" <costello@mitre.org> >Organization: The MITRE Corporation >X-Accept-Language: en >To: xml-dev@lists.xml.org >CC: costello@mitre.org >Subject: Re: [xml-dev] Categories of Web Service messages: data-oriented vs > action-oriented > >This thread has been most enlightening to me. I really appreciate >everyone's views. I'd like to recap one of the key issues: > >"Action" and "data" in an XML message: > - intertwine, or > - keep separate? > >Let's recap the pros/cons of each approach: > >------------------------------------------------------------------- >Approach 1: Intertwining action and data (i.e., colocating the >expression of the desired action with the the data that is to be acted >upon) > >To make things concrete let's revisit the Itinerary example. Suppose >that the action we want the (travel agent) service to perform is to >match up the Itinerary data with a list of flights >(action="flight-matchmaking"). Here's what the message might look like: > ><message> > <body> > <itinerary action="flight-matchmaking"> > <departureInfo> > <departingCity>Boston</departingCity> > <destination>Washington, D.C.</destination> > <departureDate>2002-2-4</departureDate> > <departureTime>late afternoon</departureTime> > <seatPreference>aisle</seatPreference> > </departureInfo> > <returnInfo> > <departingCity>Washington, D.C.</departingCity> > <destination>Boston</destination> > <departureDate>2002-2-10</departureDate> > <departureTime>mid morning</departureTime> > <seatPreference/> > </returnInfo> > </itinerary> > </body> ></message> > >Note the action attribute on the <Itinerary> element. Thus, the >indication of what action we want the service to take is colocated with >the data. > >Advantages: > >1) The same action/data message can be used for each transport protocol >(HTTP, SMTP, FTP, etc). > >2) You can have rich messages where actions apply to portions of a >message, rather than just one action for the entire message. > >Question: I am not convinced of 2). Yes, I can see that in acting upon >received data a service may want to launch other business process on >parts of the data. But, shouldn't this be transparent to the sender of >the message? Why would the "sender" want express actions on subtrees? >I guess that I need a good example to be convinced. > >Disadvantages: > >1) The actions are buried within the data. Thus a message dispatcher >must sniff the content of the message to discern its intent. > >2) Since the actions are mixed with the data it makes it hard to use >predefined vocabularies like RSS or some industry-specific one. > >------------------------------------------------------------------- >Approach 2: Separating the action from the data > >With this approach the Itinerary message looks like this: > ><message> > <header> > <action type="travel:flight-matchmaking" > xmlns:travel="http://www.travel.org/actions"/> > </header> > <body> > <itinerary xmlns:http://www.travel.org/data"> > <departureInfo> > <departingCity>Boston</departingCity> > <destination>Washington, D.C.</destination> > <departureDate>2002-2-4</departureDate> > <departureTime>late afternoon</departureTime> > <seatPreference>aisle</seatPreference> > </departureInfo> > <returnInfo> > <departingCity>Washington, D.C.</departingCity> > <destination>Boston</destination> > <departureDate>2002-2-10</departureDate> > <departureTime>mid morning</departureTime> > <seatPreference/> > </returnInfo> > </itinerary> > </body> ></message> > >Note that the action is completely separated from the data. > >Advantages: > >1) Clean separation of the data from the action on the data. > >2) The same data can be acted upon in many different ways, simply by >sending the data to a different service and specifying a different >action (assuming that the service supports that action) > >3) 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. > >4) New cottage industries will be developed to define actions (and their >semantics) for vertical industries, e.g., the travel industry will >define a travel namespace. Within that namespace they will define all >the action types on travel-formatted data, along with the semantics of >each action type. > >Disadvantages: > >1) It is difficult (impossible?) to specify different actions on >different parts of the data. > >Is this an accurate summary of the pros and cons of each approach? If >so, what's the "best practice" for designing XML messages? > >------------------------------------------------------------------- >On a related topic: One thing that Michael Brennan said I found to be >especially profound: > >> Where the distinction becomes important is when a web service is >> employed within the context of a business process. Then, an action has >> to mean something in the context of this process, and a client has to >> be able to rely upon the fact that the message will be processed >> according to its understanding of a verb. It is not useful in this >> context to view the verb as a method call; rather, it is useful to >> consider the verb as specifying a step in a workflow. > >I interpret this to mean that the "action": > - should not be the name of a procedure call, but rather it > - should be an indication of the business process that we desire > to have performed. > >Am I interpreting this correctly? /Roger > > >----------------------------------------------------------------- >The xml-dev list is sponsored by XML.org <http://www.xml.org>, an >initiative of OASIS <http://www.oasis-open.org> > >The list archives are at http://lists.xml.org/archives/xml-dev/ > >To subscribe or unsubscribe from this list use the subscription >manager: <http://lists.xml.org/ob/adm.pl> -- Rex Brooks GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth W3Address: http://www.starbourne.com Email: rexb@starbourne.com Tel: 510-849-2309 Fax: By Request
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC