[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. 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]