OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]