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

[<McGregor.Wesley@tbs-sct.gc.ca>]

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:chiusano_joseph@bah.com] 
Sent:	June 10, 2005 3:47 PM
To:	soa-rm@lists.oasis-open.org
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: McGregor.Wesley@tbs-sct.gc.ca 
> [mailto:McGregor.Wesley@tbs-sct.gc.ca] 
> Sent: Friday, June 10, 2005 3:27 PM
> To: peter@justbrown.net; soa-rm@lists.oasis-open.org
> 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:peter@justbrown.net] 
> Sent:	June 10, 2005 1:32 PM
> To:	soa-rm@lists.oasis-open.org
> 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
> 
> 
>