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

On Thu, 24 Apr 2003 16:00:08 -0400
Mark Baker <distobj@acm.org> wrote:
> 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).

I completely disagree with this.

Specific cases in point: any of the various J2EE services designed to be
retrieved via JNDI.

I am most familiar with JMS in this regard.  What it boils down to,
though, is that either you need a truly amazingly crufty,
easy-to-get-wrong, probably over-1024 chars, with-embedded-URLs style of
URI, or you need a structured way of accessing that information in a
more graceful fashion.

There is no jms: uri scheme (and in fact, there cannot easily be one,
because it represents an API rather than a protocol).

In order to retrieve a JMS Destination, one is required to have a URI
pointing at a directory, together with information on how to access the
directory, the classes to use, and so on.  A lot of this is stored in
jndi.properties or the jndi provider's properties, but if represented in
WSDL, probably needs to be made explicit.  In addition to this, one
needs a key (a string) to look up in the directory in order to find the
Destination (because a Destination is not a URL).  Moreover, a
Destination, by J2EE design, can't simply be instantiated, it must be
created (at some point) by a factory mechanism (this *may* be thereafter
stored as an opaque thingie in the directory, but isn't necessarily; it
may be created on the fly when requested).

In short, what you usually have in J2EE is a pointer to a pointer, a URI
that with some work will resolve to an address (which may or may not be
representable by a URI, but *probably* isn't or why do the whole
indirection bit in the first place?).

It is not at all accurate to say that the URI that points to the
location where the address may be retrieved, using this complex
structure to identify the address desired, is the same as the URI of the
address desired.

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Thursday, 24 April 2003 16:44:53 UTC