[
Lists Home |
Date Index |
Thread Index
]
> From: Roger L. Costello [mailto:costello@mitre.org]
<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@ingr.com]
<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.
|
