[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] SOA RA
Rex "Fear not" Nothing will be agreed upon until some time after the telecom. Sorry, I went to a play tonight with some Shakespearian scenes. Don On Sat, 2005-06-11 at 16:23 -0700, Rex Brooks wrote: > 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 > > -- 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]