As
Mark points out, the WS-A WG is making fantastic progress and by dropping
refProps leaves only refParams as the last irritant in the spec.
However I disagree with Mark's implicit assertion that resources should be
given addressable URIs. Web Services are about hiding resources and exposing
processes which operate on those resources (if you chose to think of a process
as a resource, then that's ok with me just remember I wouldn't call it that).
It's the same 404 argument again - if you expose a resource, I will bind to it.
If you remove that resource (which you are entitled to do) you will break me.
Now I'm not saying that services don't come and go, but they typically do so
with much less regularity than the resources they are composed from.
So, keeping the URI as the address of a service (not a resource) and in the
absence of refProps (and soon hopefully refParams), a typical message flowing to
an instance of a process fronted by a service looks pretty simple:
<soap:Envelope ...>
<soap:Header>
<wsa:To>soap.tcp://example.org/svc</wsa:To>
<!-- Can have WS-Context context, or proprietary context here -->
</soap:Header>
<soap:Body>
<ns:BusinessDocument>
<!-- Or can determine process context from business document -->
</ns:BusinessDocument>
<soap:Body>
</soap:Envelope> The delivery address happily lives in the wsa:To element and gets the
envelope to its intended destination. From there the context of the message can
be established and it can be routed to the correct back-end process. See how
much nicer it is that the recipient decides how to route the message? It means
the recipient has full flexibility in maintaining and evolving their backend
systems without the headache of maintaining the validity of all the
resource-identifying URIs (or worse still refProp/Param containing EPRs).
Now as for protocol independence, well Mark, you know we'll never agree there
:-) MEST allows for protocol independence because the application and message
transfer are decoupled. Nonetheless, I am also almost in WS-HappyPlace.