Re: [soa-rm] SOA RA

[Rex Brooks <rexb@starbourne.com>]

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


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309