Jacek Kopecky wrote:
On Thu, 2003-06-26 at 20:18, Michael Rowley wrote:
The use-case is very straight forward. Suppose you would like to
separate the service provided from the mechanism used to communicate
with the service (which I believe is a goal of WSDL). Client software
then needs to be able to refer to something that is specific to a single
service instance, has a single interface, but does not specify the binding.
Without the single interface restriction, it is not possible to specify
such a thing with a single URI. You can specify the service by
And you can specify the interface with:
but you cannot, with a single URI, refer to something that specifies
"any endpoint that presents the bar interface to service foo".
Why exactly do you want a single URI to be able to point to that? There
will always be things which are only identifiable indirectly...
Doesn't it make sense to allow service clients, at compile time or
deployment time, to be able to refer to services without having to
specify a binding, and then have the binding be negotiated with the
service provider at runtime? If every time someone had to do this they
had to specify both a service URI and an interface URI it would be
unwieldy. I'm talking about using this kind of reference pervasively.
Can you imagine how much more awkward it would be to write HTML pages
if every time you wanted to specify an href you had to specify two
closely related URI's instead of one?
One of the requirements for WSDL1.2 is that every semantically
meaningful thing in WSDL should be referenceable by URI. Well, in my
opinion, the _most_ important thing to be able to reference with a URI
is this, since these are the URI's that I expect would be used all over
an application. Requiring an application developer (or deployer or
administrator) specify endpoint URI's that imply a binding is wrong.
It too closely ties together the identity of the service with the
mechanism used to communicate with it. I thought WSDL was trying to