[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] SOA RA
I am definitely interested in the RA, agree on the TOC and would volunteer to take a section if we decide to proceed (2.2 would be my first choice). John Harby On 6/11/05, Don Flinn <flinn@alum.mit.edu> wrote: > Joe > > Last week I uploaded a straw-man Table of Contents, TOC, for a SOA > Reference Architecture to be used for the second document of the > specification at - http://www.oasis- > open.org/committees/download.php/13012/ReferenceArchitectureTOC_05-06.doc . > > Does this begin to meet your concerns? If so, please note acceptance or > suggest modifications to the proposed TOC. > > This is also a request to all who are interested in an SOA RA to comment > on the TOC, either yea, nay or needs mod so we may determine if there is > any interested in producing an RA. > > When the concerns of all those interested are satisfied, work can begin > on writing the RA, provided, of course, that there is an interest. > > Don > > On Fri, 2005-06-10 at 15:46 -0400, Chiusano Joseph wrote: > > 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 > > > > > > > > > > > > -- > Don Flinn > President, Flint Security LLC > Tel: 781-856-7230 > Fax: 781-631-7693 > e-mail: flinn@alum.mit.edu > http://flintsecurity.com > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]