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:]
> Sent: Saturday, June 11, 2005 12:38 PM
> To: Chiusano Joseph
> Cc:
> 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:
> > > [mailto:]
> > > Sent: Friday, June 10, 2005 3:27 PM
> > > To: ;
> > > 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:]
> > > Sent: June 10, 2005 1:32 PM
> > > To:
> > > 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:
> http://flintsecurity.com
>
>
