[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] SOA RA
I understand, Don, honest. But Duane said we would settle this in the meeting, and I am abiding by that. Ciao, Rex At 5:59 PM -0400 6/11/05, Don Flinn wrote: >Hi Rex > >You have made a number of good points. Let me try to give my viewpoint, >which, I stress, is just my opinion. > >1) IMO the TC has expressed an opinion that we should have an RA in >addition to an RM. > >2) We are spending a lot of energy and time in debating whether this >concept or that concept should or shouldn't be in the RM. This is not >limited to the SC but covers the many items that I put in the straw-man >RA TOC. > >3) A number of the TC members feel strongly that the RM should abide >strictly with the reference model definition in the present RM >specification, but are amenably, I believe, to having a companion RA >document. > >Rather than continuously debate what should be where, lets develop the >text for these concepts in the RA. With the text we will have something >(excuse the term) concrete to use to potentially decide later if certain >text should be moved from the RA to the RM. > >I did not intend to carry out a straw poll, only to determine if there >were enough members that were willing to contribute to an RA. > >Lastly, I'm not trying to rush this - too much -:). However, if we are >to produce an RA for this specification we should begin the effort >before too long. I am sensitive to conflicting obligations on all our >time. > >Don > > > >On Sat, 2005-06-11 at 12:09 -0700, Rex Brooks wrote: >> Don, >> >> I really feel you are getting ahead of the TC here. We have not yet >> settled the issue of the SO/SOA RM yet. We were told we would >> entertain a motion on it in our meeting next week. So let's see how >> that turns out before we start making plans for an RA yet, okay? >> >> I appreciate your earnestness in wanting to get this behind us, but >> let's not assume a fait accompli where there is only an absence of >> continued voicings of opposition. I have kept relatively quiet on >> this because my views should be known by now, and it seemed like it >> was only polite to refrain from continuing to express it. I also >> suggested paths to avoid making an SOA out of S alone, because I will >> oppose that, but I suggest you not approach this as if it was a straw >> poll to be taken on the basis of a lack of opposition or even a lack >> of discussion. Some of us are very busy with the upcoming DRM Public >> Forum Monday. >> >> Please don't take this wrong way, but also please don't put words in >> my mouth when I am only allowing the dust to settle. >> >> Ciao, >> Rex >> >> P.S. I would support an RA, regardless of whether SC ends up in an >> SOA but we need to get that settled first before approaching the >> subject. >> >> At 12:38 PM -0400 6/11/05, Don Flinn 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 >> >> >-- >Don Flinn >President, Flint Security LLC >Tel: 781-856-7230 >Fax: 781-631-7693 >e-mail: flinn@alum.mit.edu >http://flintsecurity.com -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]