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

["Chiusano Joseph" <chiusano_joseph@bah.com>]

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
> 
> 
>