[
Lists Home |
Date Index |
Thread Index
]
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.
With a data-only message, how would you send a delete request?
Michael Kay
Software AG
home: Michael.H.Kay@ntlworld.com
work: Michael.Kay@softwareag.com
> -----Original Message-----
> From: Roger L. Costello [mailto:costello@mitre.org]
> Sent: 04 February 2002 19:45
> To: xml-dev@lists.xml.org
> Cc: costello@mitre.org
> Subject: [xml-dev] Categories of Web Service messages:
> data-oriented vs
> action-oriented
>
>
>
> Subject: Approaches to designing XML messages
>
> I have convinced myself that there are two fundamentally different
> approaches to designing Web service XML messages. They are:
>
> 1. The data-oriented approach
>
> 2. The action-oriented approach
>
> I believe that which approach a person takes will have serious
> implications on the nature of Web services.
>
> Below I elaborate upon each approach. Before doing so, however, I
> present the 3 questions that I have:
>
> a. Has someone already articulated the two approaches?
>
> b. What are the pros/cons of the two approaches, especially as applied
> to Web services?
>
> c. Intuitively, I think that the data-oriented approach is the right
> approach. I believe that XML messages should not be simply procedure
> calls disguished in XML (which is how I see the action-oriented
> approach). Data-oriented XML messages requires a different
> mindset, and
> will result in a different way of building Web services.
> However, I do
> not have clarity on how to create services that are data-oriented.
> After all, isn't the purpose of a service is to "do some action"? Can
> you provide clarity?
>
>
> 1. The data-oriented XML message approach
>
> With this approach a message is simply comprised of data. The tags
> denote data, not actions. For example, below is an XML
> message that is
> to be sent to a travel agent service:
>
> <itinerary>
> <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>
>
> Notice that this XML message just contains data about a person's
> itinerary. Since this is simply data, not targeted to any particular
> application, I can imagine that it could be used by a variety of Web
> services, not just a travel agent service.
>
> 2. The action-oriented XML message approach
>
> With this approach a message is basically a procedure call
> disguised in
> XML:
>
> <getFlights>
> <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>
> </getFlights>
>
> This XML message is identical to the earlier XML message
> except for the
> root element. The root element implies action. The root element is
> directly correlated to a method name. Its child elements are the
> parameters.
>
> I contend that this action-oriented root element gives the message a
> very different feel. I contend that it tightly couples the
> message to a
> particular kind of service - one that returns flight information. The
> data-oriented approach, on the other hand, is not coupled to any
> service, so it could be used by a variety of services.
>
> I appreciate any clarity you can bring to this topic. /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>
>
|
