W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2003

Re: targetResource wording

From: Sergey Beryozkin <sberyozkin@zandar.com>
Date: Sat, 21 Jun 2003 16:07:26 +0100
Message-ID: <008801c33806$ecf53d00$93a4a5c2@zandarpc>
To: <fred.carter@amberpoint.com>, <www-ws-desc@w3.org>

Hello Fred,
Thank you. When I read your message yesterday I thought  : now I do know
what @targetResource is for, in a Printer and PrinterManager case it just
says that both operate in their own way on the same resource or a set of
resources . It just another way to say this :
<service PrinterAll>

with this

<service Printer>

<service PrinterManager>

And this looks ok. And I thought that @targetResource in this case has no
any practical implication other then to tell to a client that PrinterManager
will be able to cancel a printer job, but it *does not identify a physical
resource*, unless there's only one physical resource available.
The only major practical implication @targetResource would have is to help
in selecting multiple endpoints and bindings, as Arthur Ryman explained
But this Saturday afternoon all collapsed :-), after I read another
excellent explanation by David Booth and related Savas's messages.
IMHO, it's not good at all to have potentially 3000 + 5000 wsdl descriptions
for just 2 sets of different functionality, that of printer and printer
manager, I agree with Savas.
If I understood you correctly, we'd just have 4 services descriptions if we
wanted to print for a fee or free of charge on the same printer resource.
And as Savas noted, a printer job jd would make it possible for a service to
print and manage effectively.

Sergey Beryozkin

----- Original Message -----
From: "Fred Carter" <fred.carter@amberpoint.com>
To: <www-ws-desc@w3.org>
Sent: Friday, June 20, 2003 7:23 PM
Subject: Re: targetResource wording

> Thus quoth Sergey Beryozkin (~ 20-Jun-03 5:19 AM ~)...
> > Sorry for asking what likely is a trivial question, but :
> >
> >
> >>>Can a client processing service d1 and d2 descriptions to avail of this
> >>>targetResource attribute in any way ?
> >>
> >>Sure- to realize that d1 and d2 both have something on common: they
> >>are both services that mess around with the same resource.
> >
> > So, for example,  a client sees a printer service which can print a
> > to a printer (identified by a targetResource), and also sees a printer
> > management service which can manage the same targetResource.
> > I can't see at the moment how the client can utilize this information.
> > a client now can set up a printer first before sending a document to
print ?
> > But wouldn't a client be able to do the same if there were  two services
> > descriptions available (printer and printer manager) but without a
> > @targetResource ?
> >
> > Thanks !
> > Sergey Beryozkin
> > [...]
> Suppose there are two interfaces, printing & printermgmt. Printing
> contains the operation "print" which returns a job id.  printermgmt
> contains, amongst others, the cancelJob operation.
> If I print to some print endpiing with a targetResource and later decide
> to cancel it, I need to know which thing on which to perform the
> cancelJob operation. In  this case, the 'targetResource' identifies the
> printing subsystem.  Depending upon the enterprise's choices, this may
> be a server, a printer, a farm of printers in some room with a common
> manager or spooler, whatever -- we don't know.  We just know that two
> endpoints employing these interfaces refer to the same 'collected stuff'
> -- that identified by the 'targetResource'.
> (Arguments about bad interface decisions are not terribly relevant.
> There will always be cases where there are different interfaces.)
> If, OTOH, one could put the 'printing' and 'printermgmt' interfaces into
> the same service, this wouldn't be a problem.  But it is in the current
> thinking.
> IMHO:  This issue exists ONLY because of the "service contains a single
> interface" decision.
> --
> Fred Carter / AmberPoint, Inc.
> mailto:fred.carter@amberpoint.com
> tel:+1.510.433.6525 fax:+1.510.663.6301
Received on Saturday, 21 June 2003 11:08:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:30 UTC