Re: targetResource wording

+1

Putting printer URIs in WSDL files will be a maintenance nightmare, and
it seems a clear case of conflating interface and implementation to me.
Even the alternative I was talking about earlier, of having the URIs
identify "software", or simply a logical grouping of interfaces, would
have similar maintenance problems I think.

IMO, the simplest way to address this is to permit multiple interfaces
per service.

MB

On Sat, Jun 21, 2003 at 04:07:26PM +0100, Sergey Beryozkin wrote:
> 
> 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

Received on Sunday, 22 June 2003 07:13:07 UTC