OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm] SOA RA


I am definitely interested in the RA, agree on the TOC and would
volunteer to take a section if we decide to proceed (2.2 would be my
first choice).

John Harby

On 6/11/05, Don Flinn <flinn@alum.mit.edu> 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
> 
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]