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:
	&#x2022; 	 Specific instances of a stateful service need to be identified or 
its instance-specific configuration details need to be transmitted.
	&#x2022; 	 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.