RE: Proposal for Describing Web Services that Refer to Other Web Services: R085

Mark,

I believe there is a problem with the approach to web services you are
advocating, because the same service may exist in several places without
either
(a) a 1:1 mapping between a URI and that service
(b) a fixed location or even port at which this service can be reached. 

You seem to be ignoring the fact that, for instance, absolutely
identical copies of services providing certain R/O data may be located
at more than one place for the purpose of reducing network latency
(Earth, together with its geostationary orbit is a big place, still) and
other problems related to the location of the service. Each of the host
locations of the service has a unique URI, because it must be possible
to talk to it indiviually. Virtualizing this service would require an
"abstract" URI which points to a logical location that will choose the
most appropriate place for you to talk to. So, in that case, each
service has indeed at least two URIs, even in the case of HTTP. One that
you bind to and one that you talk to. If you take additional protocols
into account (I hope you don't deny the fact that SMTP is around), a
service endpoint may even have more URIs.

The uniqueness of a URI requires a distriction between URI and URL
wheree you always define URI as a protocol independent entity
"urn:my-service" which has multiple URLs associated with it.

The approach to web services that you describe doesn't scale for a large
set of use cases.

Clemens



-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org] 
Sent: Freitag, 25. April 2003 00:00
To: www-ws-desc@w3.org
Subject: Re: Proposal for Describing Web Services that Refer to Other
Web Services: R085



Hi Arthur,

I want to focus on one very small statement in your proposal which I
believe is indicative of a much larger problem with the current approach
to Web services.  After doing that though, I'll offer a
counter-proposal.

You wrote;
"In some cases a URI is[sic] not sufficient to identify a Web service
endpoint."

When used properly, a URI is *always* sufficient, because there always
exists some finite amount of information which is required to use *any*
service.  URIs were designed to hold *all* that information, either
within the URI itself, or by deference to some other widely adopted
standard (e.g. HTTP's default port is 80, as registered with IANA).
Because of this, URIs already provide a means of bridging the gap
between a Web service endpoint, and the interface presented by that
endpoint; the URI scheme.  For example, if I see a "ftp:" URI, I know I
can access the resource with the application interface described in RFC
959, and, say, invoke the RETR application method to retrieve the
identified file.

As this relates to R085 and your proposal, I'd propose that instead of
using an approach such as wsdl:endpoint or wsa:EndpointReference, both
of which assume that this "gap" is inherrent, that a new URI scheme be
used instead;

  wsep://example.org/foo/bar

(where "wsep" stands for "Web service endpoint")

There's still lots more to be said, but I'll stop there for the moment.
You might be able to see where I'm going with this.

Thanks.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Saturday, 26 April 2003 02:01:24 UTC