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
