[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Categories of Web Service messages: data-oriented vs actio
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|