Cart
|
[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 acti
 > From: Roger L. Costello [mailto:costello@m...] <snip/> > XML is well known for its separation of data (XML) from > presentation of > the data (XSLT), i.e., "one data but many views of the data". > > I would like to conjecture a similar design pattern for XML messages - > the separation of an XML message from the consumption of the message, > i.e., "one XML message but many consumers of the message". > > For example: > |--------| > | | > |------> | Logger | > | | | > |------------| | |--------| > | | | > | Intinerary | -----| |--------------| > | | | | | > |------------| |------> | Travel agent | > | | > |--------------| > > Here the Itinerary message is being consumed by 2 different > applications > - a Travel agent (which responds with an XML message > containing flights) > and a Logger application which logs all itineraries (and no > response is > generated). There are 2 important things to note: > > 1. The same message (data) is usable by a variety of > applications. This > is possible because the Itinerary message is just data, it is not tied > to any application. That is, there are no "action tags". > > 2. The application which consumes the data decides on the > purpose of the > data. The last point is untenable in many real world scenarios. If I send an itinerary to a travel agent with the intent of actually booking a flight, hotel room, etc., than it is not acceptable to let the consumer decide on the purpose of the data. There are plenty of scenarios where a publish-and-subscribe model works. In such scenarios, a system simply announces some information of interest and it is up to other systems to decide what to do with this information. But there are many scenarios where a message is produced with explicit expectation of some sort of business processing that will follow. I think in such a case, there is no reason why there couldn't be other listeners in the conversation that are interpreting this intent differently (such as a logger, to use your example). But in this scenario, there is some expressed intent that must be interpreted by an endpoint in a manner consistent with the expectation of the sender. Without this, web services are untenable. > From: Bullard, Claude L (Len) [mailto:clbullar@i...] <snip/> > We are about to walk straight back into the Doctype over PI > over attvalue in the root discussion. Well, since I am firmly in the camp of insisting there is no inherent doctype in a document, I should emphasize that the "intent" of a message is not something inherent in the syntax of a message viewed in isolation. However, a document has no notion of a corresponding response, either, yet web services need such a correlation. Web services need abstractions that go beyond the syntax of a document viewed in isolation, and when considered in this context, a message needs a way to convey an intent that is not simply up to the interpretation of any consumer. I don't think you can completely decouple the intent of a message at the web service layer from syntactic constructs used to convey that intent. One can certainly debate, though, over the mechanisms used to convey that intent. One could probably use constructs in the message that are not inherently coupled with that intent, and then use separate metadata to associate appropriate intent with syntactic constructs within the context of a particular web service. I think this makes the modelling of the message structure quite a bit more difficult, though, when you try to employ rich messages yet adhere to syntactic constructs that imply no particular intent. 
|
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
|
|||||||||
