Re: [soa-rm] RE: Consumer mechanism for "advertising" for a service

Part of the service description is the range of acceptable consumer 
profiles that the service will entertain invocation requests from.  I 
think the role of the potential consumer might be part of that however 
that may not be specific enough in some cases.

Interesting thoughts.

Duane

 wrote:

>A service consumer has a very distinct role from the service provider and in some scenarios provides the necessary context needed to clarify intent.
>
>Duane, as far as Service Consumers go,  they do not advertise their consumption context.
>
>Wes
>
> -----Original Message-----
>From: 	Chiusano Joseph [mailto:] 
>Sent:	June 10, 2005 3:47 PM
>To:	
>Subject:	RE: [soa-rm] RE: Consumer mechanism for "advertising" for a service
>
>I recently learned that a service consumer does not belong in a RM
>because it would require infrastructure to connect that service consumer
>with services (and the same holds for connecting services to each
>other). Once we begin representing infrastructure, it requires
>architecture - which is the territory of an RA not an RM.
>
>Which means that by definition of RM, it is impossible to create an RM
>for SOA - such a thing must be an RA.
>
>Joe
>
>Joseph Chiusano
>Booz Allen Hamilton
>Visit us online@ http://www.boozallen.com
> 
>
>  
>
>>-----Original Message-----
>>From:  
>>[mailto:] 
>>Sent: Friday, June 10, 2005 3:27 PM
>>To: ; 
>>Subject: [soa-rm] RE: Consumer mechanism for "advertising" 
>>for a service
>>
>>Nicely stated Peter.
>>
>>Based on your clarification, I would propose then that a 
>>consumer (should the RM have one) has a set of properties 
>>(one of which could be state) that is not defined by the RM 
>>but are defined by a reference architecture.
>>
>>Wes 
>>
>>
>>
>> -----Original Message-----
>>From: 	Peter F Brown [mailto:] 
>>Sent:	June 10, 2005 1:32 PM
>>To:	
>>Cc:	McGregor, Wesley
>>Subject:	RE: Consumer mechanism for "advertising" for a service
>>
>> << File: Consumer concept.png >> Wes:
>>We are back to the problem/issue of intent and context: from 
>>the moment an application/agent establishes an intention to 
>>be a service consumer then it
>>*is* a service consumer (at the very least in its context, 
>>even if nothing out there recognises it as such); in the same 
>>way that a service provider (and indeed a service) is a 
>>service provider (or a service) from the moment there is an 
>>intention for it to be so, irrespective of invocation, execution, etc.
>>
>>In an RA, I think it's more helpful to think of service 
>>consumer as one concept. The "variants" you propose are then 
>>properties of an association (eg "state=invoked", 
>>"state=run-time", etc) between the consumer "concept"
>>and the actual "real world" implementation (see attached 
>>diagram - I'm not sure what to call these different "aspects" 
>>or states of being a consumer tho'...ideas on a postcard please).
>>
>>There are practical and powerful reasons for making this 
>>conceptual separation, not least in the area of "semantic web 
>>service" implementations.
>>But I'll leave that stuff until Vancouver....
>>
>>-Peter
>>
>>
>>
>>    
>>
>
>
>
>  
>