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

Ugo Corda wrote:

>>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.
>>    
>>
>
>Yes, the problem seems to be very specific. I think I know how all this originated. Initially a WSDL service could include various entry points representing different interfaces. The latest draft redefined service to only represent a single interface. Hence the need some people felt to have a way to represent the type of service aggregation that was possible in the old draft.
>  
>
I also prefer if the service was associated with a single interface and 
if all the end-points are equivalent. I see the aggregation problem, but 
I think it's much easier to restrict the service definition and then 
propose some solution to that problem.

>I think that the idea of achieving such an aggregation via the concept of a resource is ill conceived. As already discussed, resource is too vague an idea for that. And the aggregation concept, as it was discussed during the F2F, belongs more in the application domain than the WSDL domain. (Different criteria for service aggregation can be devised given the same set of WSD services, depending on the application).
>  
>
I can see two types of aggregation here.

One is multi-reference. The service can be referenced from multiple 
collections of services. It could be a collection of all the services I 
have to manage on a daily basis, all the services that are specific to 
order fulfillment, all the services that relate to some physical 
resource like a printer. The best strategy in my opinion is to have 
different ways to create these collections - outside the scope of WSDL - 
and then some way to reference services unambigously, and I think the 
service name would suffice.

The other is single-reference. In this case there is exactly one 
collection of services and the easiest way to express that is by having 
them all associated with some common name, whether it's the 
targetResource or even just the targetNamespace. I think the concept you 
need here is service provider. If these are not all services belonging 
to the same service provider, there's no point in collecting them in 
that particular way.

The printer example is just bad, because the printer may be listed in 
different directories, one for the printers on my floor, one for the 
PostScript printers and one for printers that collate and staple and 
wash my coffee mug (anyone knows where I can get one of those?) On the 
other hand if I wanted to retrieve all the service definitions for that 
printer because the service provider supports multiple interfaces, I can 
see where the common name helps.

>If I had to make a suggestion, I would say WSD should provide some (optional) syntax to specify the old type of aggregation, and leave it at that. That syntax would simply collect a bunch of "new" services together under the same XML element. No need to base that syntax on any concept of common URIs identifying resources or other things.
>  
>
I prefer using a common name than a new element for the simple reason 
that I can add more things to that collection without having to modify 
some document. So when I add another service definition to the 
collection, instead of having to push a new collection definition out 
there, I simply let people find it by doing a new query.

arkin

>Ugo
>  
>

Received on Wednesday, 21 May 2003 22:40:59 UTC