[
Lists Home |
Date Index |
Thread Index
]
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
|
