[
Lists Home |
Date Index |
Thread Index
]
After some reflection I agree that an XML message must contain, along
with the data, an indication of how the sender wants the data acted
upon. What I do not agree with is that the data and the
action-indication must be inextricably married.
I feel that there is great utility in separating the two. Let's consider
the Itinerary example again. There are 2 components that must be sent
to the travel agent service:
1. Data: Itinerary
2. Action type: flight-matchmaking (i.e., match up the Itinerary with
a list of flights)
Here's what the XML message looks like:
<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>
Notice that the data (Itinerary) is cleanly separated from the
specification of the action (flight-matchmaking), and both reside in
different namespaces.
The advantages of separating the action from the data:
a. Clean separation of the data from the action on the data.
b. 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)
c. 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.
d. 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.
The disadvantage of this approach:
a. It may be difficult to specify different actions on different parts
of the data. Any suggestions on how to do this?
This approach of separating the data from the action on the data has
implications on how a service is specified. A service must specify 2
things:
- the type of data it can process, e.g., Itinerary data, or
cellphone data, etc
- the types of actions it can perform on the data,
e.g., flight-matchmaking action, logger action, etc
Comments? /Roger
|
