RE: SOA RA

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Don,

So sorry that I have not been able to reply to your Saturday e-mail
prior to this - I am one of those people that Rex referred to who was in
crunch mode for yesterday's Data Reference Model (DRM) Public Forum
(which went very well).

At this point, I will look forward to discussing this on tomorrow's
call. I appreciate your efforts very much, and know that you have only
the best intentions.

Thanks,
Joe

Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 

> -----Original Message-----
> From: Don Flinn [mailto:flinn@alum.mit.edu] 
> Sent: Saturday, June 11, 2005 12:38 PM
> To: Chiusano Joseph
> Cc: soa-rm@lists.oasis-open.org
> 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/ReferenceArchitectureTO
> C_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
> 
>