[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] SOA RA
Joe,
By all means, separate when the separation is obvious. OTOH, I have often
developed specific/concrete concepts and later figured out how to
generalized while using the specific version as an example. Usually, the
refactoring is straightforward. Where it is not, the concepts tend to need
better definition, i.e. the problem isn't with the refactoring process but
the source content.
Just a suggestion for minimizing the RM/RA debates.
Ken
At 02:32 PM 6/21/2005, Chiusano Joseph wrote:
>Thanks for your thoughts Ken.
>
>I wonder if it may be best to draw the RM/RA line sooner rather than
>later, as it will enable folks to think in terms of each of those (as we
>know, RM=abstract, RA=concrete) rather than creating a mish mosh of
>things and then sorting it out later. The latter approach may
>potentially lead to information not being included in either or both,
>because folks were not thinking in terms of the specific context (RM or
>RA).
>
>Just an alternate suggestion for us to perhaps consider as well.
>
>Joe
>
>Joseph Chiusano
>Booz Allen Hamilton
>Visit us online@ http://www.boozallen.com
>
>
> > -----Original Message-----
> > From: Ken Laskey [mailto:klaskey@mitre.org]
> > Sent: Tuesday, June 21, 2005 2:18 PM
> > To: Don Flinn; Rex Brooks
> > Cc: Chiusano Joseph; soa-rm@lists.oasis-open.org
> > 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/ReferenceArchitectureT
> > OC_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
> > /
> >
> > --------------------------------------------------------------
> > --------------------
> >
> >
> >
> >
--
---------------------------------------------------------------------------------
/ 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]