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

I see the service provider as being different from the service 
implementation. The implementation may indeed provide a variety of 
services including mortgage, car loan and personal loan. It contains 
multiple service providers, one for mortgage, one for personal loan, etc.

But this does raise an interesting question regarding the usability of 
the service provider URI.

Let's say I have a single loan service management interface. I also have 
three different load services: mortgage, car, personal. Since they are 
unrelated conceptually these are three separate service providers, or 
resources, or agents. All of them can be managed using the same 
interface, so the provider/resource/agent for each one would encapsulate 
two services: the management one and the specific client service.

If these services were aggregated using some container XML element as 
you suggest than I could define one management service to be used in 
three different collections. On the other hand, if they are aggregated 
using a common name, then you need three different management services 
that would use different targetResource URIs. Although, if you are 
following the WS-Addressing approach you can still use the same 
end-point for all three management services by passing different 
properties in the request.

Hmmm...

arkin

Ugo Corda wrote:

>>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. 
>>    
>>
>
>I can understand that. But a "service provider" is different than the concept of "resource" as intuitively understood. 
>
>To give an example, a service provider might make available as services a mortgage processor, a car loan processor, a personal loan processor, and a management module to manage all of them. Each of these services has its own "resource" (the specific loan processor, in the loan cases, or the management module).
>
>Now, if I wanted to specify the relationship between the management service and one of the loan services via one shared URI, the "service provider" URI would do, but not the "resource" URIs (which are different between the two services).
>
>As I said before, it seems to me that the "resource" concepts only helps in some particular cases. The "service provider" concept helps in other cases. In yet other cases a different concept might be needed to express services aggregation. My question is: do we have to go through the trouble of identifying all these concepts, clarify their meaning, assign them URIs, etc, just for the purpose of expressing aggregations that in many cases are just application-specific?
>
>Ugo
>  
>

Received on Thursday, 22 May 2003 15:55:03 UTC