Re: [soa-rm] SOA RA

[Don Flinn <flinn@alum.mit.edu>]

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