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
>
>
>
