[
Lists Home |
Date Index |
Thread Index
]
On Aug 12, 2004, at 8:10 AM, Mark Baker wrote:
>
> It's certainly good to see everybody working together, but it's
> unfortunate that it's on yet another WS-* spec with very few redeeming
> qualities. Ok, maybe parts of sections 3 and 4 have some value, but
> its
> raison d'etre, section 2, is IMO entirely unnecessary (and worse,
> actively harmful). URIs are perfectly adequate as message endpoint
> references; nothing more is needed.
>
I suspect that a more detailed critique will be necessary to persuade
the folks at W3C who will be weighing whether to invest resources in
this activity. [Thankfully for my sanity, I am no longer among them!]
How about a real analysis of the cases where the authors of the
proposal clearly do NOT think URIs are adequate, especially when
multiple (sometimes proprietary) transport protocols are in the mix?
This seems to be the relevant material in the proposal:
"In particular, this specification intends to facilitate the following
usage scenarios:
• Dynamic generation and customization of service endpoint
descriptions.
• Identification and description of specific service instances that
are created as the result of stateful interactions.
• Flexible and dynamic exchange of endpoint information in tightly
coupled environments where communicating parties share a set of common
assumptions about specific policies or protocols that are used during
the interaction.
To support these scenarios, we define a lightweight and extensible
mechanism to dynamically identify and describe service endpoints and
instances. Because of the current limits of the WSDL 1.1 extensibility
model, the WSDL 1.1 service and port elements cannot be used to cover
the use cases listed above. Endpoint references logically extend the
WSDL description model (e.g., portTypes, bindings, etc.), but do not
replace it. Endpoint references will be used instead of WSDL <service/>
elements in the following cases:
• Specific instances of a stateful service need to be identified or
its instance-specific configuration details need to be transmitted.
• A lightweight, self-contained description of a service endpoint
needs to be communicated. In particular, this may be necessary when the
details of the endpoint configuration are already shared by the
communicating parties, but specific policy information needs to be
added or updated, typically as a result of a dynamic configuration
process."
Note especially the bit about "dynamic generation" and "stateful
interactions." From my perspective, it's fine and dandy to preach the
gospel that services should be stateless and fully identified to
service consumers, but the folks who wrote that spec are probably
dealing with real-world customer situations where that doesn't work.
Perhaps they have real objects (or maybe COBOL programs!) that maintain
some state across operations exposed as services. The easiest way to
keep things straight [if I understand the intentions here] is to route
subsequence invocations of a service in that same context is to route
the message back to the same object / program / whatever that is
maintaining the state, and that can only be determined by the service
supplier at runtime.
I imagine that such a thing could be done within the URI framework,
but I would be surprised if it is any simpler or more portable than
what WS-Addressing proposes. But if a better solution TO THIS PROBLEM
can be proposed, I'd like to see it described in detail.
|
