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

Champion, Mike wrote:

>>Or the URI is just a name and the "printer 
>>service" directory has an association between buildings and floors to 
>>printers (and hopefully also knows which floor I'm on). But 
>>then, could 
>>that directory just reference the service by it's QName?
>>    
>>
>
>This is what I have in mind.  WSA would not, of course, specify all the
>properties associated with a targetResource, just assert that a discovery
>service could maintain such an association.
>  
>
That's good because it gives you the level of flexibility you want. So 
let's say the resource URI is just some UUID with no meaning of 
reference to anything physical (or even logical). But I can still say a 
lot of things about it. I can have some specification about the 
capability of that printer. I can reference it from different places in 
the directory, whether because I was looking for a PostScript printer, 
or some printer on my floor, or a 20ppm+ printer.

Am I understanding this correctly?

In the case would it be fair to say that this is nothing than some 
common name that correlates multiple service definitions together? 
Something like a service set.

An alternative would be to have some collection element to do that, for 
example:

<serviceSet name="uri">
  <service/> +
</serviceSet>

But that would require the serviceSet to be rewritten each time a new 
service is added. So I would definitely prefer to see some common name 
used in independent service definition that ties them together, assuming 
anything I said so far makes any sense ;-)


>>So trying to understand the value proposition of 
>>targetResource and best 
>>practice, it seems to me that it tries to solve a very 
>>specific problem: 
>>how to define multiple <service> definitions that are independently 
>>managed, yet all relate to the same service 
>>agent/provider/resource. 
>>    
>>
>
>Yup.  That's the scenario we discussed in Rennes.  Think of a WSDL service
>that has a "print job interface" and another service that has a "management
>interface".  Both may be bound to the same physical printer, or not.  
>
> 
>  
>
>>I see the value in associating them all to the same entity, but 
>>would it 
>>not make more sense to pick a more applicable term, perhaps agent or 
>>provider?
>>    
>>
>
>agree.  
>  
>
I like the idea. But what I'm reading in your e-mail is different from 
what I read in all the other e-mails on this thread, and I think the 
choice of the term resource or the unclarification of what exactly it 
means has a lot to do with it. I think defining what that resource is, 
as opposed to the actual printer resource or bank account resouce, is 
going to be as elusive as defining what a Web service is.

I'm going to duck and run for cover, hoping that someone would pick a 
different name or better clarify it before we end up swimming in another 
trout pond ;-)

arkin

Received on Wednesday, 21 May 2003 22:18:35 UTC