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
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309
