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:
> >> >> > [mailto:]
> >> >> > Sent: Friday, June 10, 2005 3:27 PM
> >> >> > To: ;
> >> >> > 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:]
> >> >> > Sent: June 10, 2005 1:32 PM
> >> >> > To:
> >> >> > 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:
> >> >http://flintsecurity.com
> >>
> >>
> >--
> >Don Flinn
> >President, Flint Security LLC
> >Tel: 781-856-7230
> >Fax: 781-631-7693
> >e-mail:
> >http://flintsecurity.com
>
>
--
Don Flinn
President, Flint Security LLC
Tel: 781-856-7230
Fax: 781-631-7693
e-mail:
http://flintsecurity.com
