[
Lists Home |
Date Index |
Thread Index
]
> From: Bill de hOra [mailto:dehora@eircom.net]
<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.
|
