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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]