Re: targetResource wording

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>
   printerPort
   printerManagerPort
 </service>

with this

<service Printer>
   printerPort
</service>

<service PrinterManager>
   printerManagerPort
</service>

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
(thanks).
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.

Cheers
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
document
> > 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.
Say,
> > 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