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: SOA RA


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]