Re: Separate concepts for "service" and "targetResource?" (was RE : /service/@targetResource ?)

> > > As far as I know, a "resource" is anything with identity that can
> > > meaningfully be accessed via the Web.  What the WSDL people call a
> > > targetResource has identity (it's a specific piece of code
> > that performs a
> > > well-defined operation) and it is accessed via the Web (or
> > at least by Web
> > > gateways).  For example, a specific printer attached to a
> > mainframe that
> > can
> > > be accessed by a HTTP/SOAP gateway is a "resource" with
> > identity, or at
> > > least the specific software agent that "drives" the printer
> > from the Web
> > > service point of view is a Web resource.
> >
> > It seems like "the printer", conceptually, is the resource, while
> > the driver software and even the hardware are kind of ephemeral.
> > The "software agent" view of that strikes me as a sort of 'techie'
> > way of trying to be conceptual, and not quite making it.  What if
> > there wasn't any software?
> >
>
> That's why there are 2 URIs.  One for the "target", and one for the
> "service".  A printer is a different concept than a printer service.  I
> don't know why this is so hard for people to understand.  There may be
many
> services associated with a printer.  Hence there may be many different
> service URIs, yet only one target URI.  And these services could be in
many
> different wsdl definitions.

Probably because it becomes many-to-many, as in many services
across many printers.  It should now be *obvious* that early binding
to the resource is a killer.  There will be so much work keeping up
the *DL specs, there won't be time for anything else.  Imagine a
Java or C++ program in which every instance of some class needed
its own class definition, because instance identity is represented at
that level.  Am I crazy, or is that where this is leading?

Walden

Received on Thursday, 22 May 2003 09:30:23 UTC