[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
> From: Bill de hOra [mailto:dehora@e...] <snip/> > The difference I can see is not that the root element has a different > name, that a human might reasonably interpret by default as a > verb. It > is that in the second case the _emitting_ software > understands the root > element as a verb, not a noun. Changing tags doesn't make data > action-oriented, invoking code with that data does. Yes. > The tightness in your examples are in any assumptions the *emitting* > software is making about what will be done to its data. i.e. how that > data will be acted on. Either way it's emitting data, passing > a message, > uttering, or whatever. Tight coupling comes from faking a > single thread > of execution on a network, not enough indirection, and hard coding > assumptions in software about what other software should be doing. > > The distinction I do see between action and data is this: > > -data: the emitter doesn't assume how the message > is to be processed. > > -action: the emitter assumes the message will > be processed according to its understanding of > a verb. Yes, although I would draw the distinction between "understanding of a verb" at a business process layer vs. "understanding of a verb" at an API layer. The latter is RPC, the former is semantics attached to the document within a context larger than the document itself. These distinctions are meaningless at the protocol layer; it is just XML over some sort of transport. The distinctions are relevant in the larger context. > (the latter sounds like hard-coding to me) Yes, if it is explicitly tying an element name to a method call. This is just an implementation issue, though. When a client sends off an XML message, it cannot really know how it will be processed by the recipient. So the distinction between RPC and message-oriented -- or between "data-" and "action-oriented" -- is totally artificial at this level, and there is no reason why one party in the conversation could not be viewing it as an RPC call, while the other is treating it as just an XML document. 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. So the question becomes not how to correlate message syntax with method calls or APIs, but how to correlate message syntax with workflow and business processes. The APIs are purely implementation details. Of course, if a client implements a web service with the expectation that a verb is invoking a specific API, rather than fulfilling a contract in terms of a business process, that is certainly creating a tight coupling and is not a particularly scalable or robust model.
|
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
|