[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] SOA RA
This is a little late because I am catching up on random threads but may I
suggest a way forward:
We seem to have general agreement that we will also write a RA document so
I think it is less critical to have a rigid RM/RA line. Whatever we write
is likely to have a home in one of the documents. Let's allow some
latitude in what initially makes it into the RM because we can draw the
line later and move something to the RA document. An editor can even
identify something as likely RA material. What we gain is the ability to
capture our thoughts without debating whether they are the right thoughts
at the moment.
My belated $0.02.
Ken
At 12:50 AM 6/12/2005, Don Flinn wrote:
>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
--
---------------------------------------------------------------------------------
/ Ken
Laskey \
| MITRE Corporation, M/S H305 phone: 703-983-7934 |
| 7515 Colshire Drive fax: 703-983-1379 |
\ McLean VA 22102-7508 /
----------------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]