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: [soa-rm] Definition of "Service Consumer"

If by '"rigid" you mean UML, then, notwithstanding the implicit 
agreement in the positions of my last post and Matt's post, then I am 
in favor of a narrow definition within the scope and context of IT 
per se. And, I do think we need to either vote on or gain clear 
consensus for each our terms, no matter how few there are, but in 
respect of how few they should be and I definitely prefer the fewest 
possible to do the job on a necessary and sufficient basis. So far I 
think we are getting close to necessary, but remain quite a distance 
from sufficient. To put it in Einsteinian aphorism, we have it nearly 
as simple as possible, but I think that is too simple to satisfy the 
"simple enough" test. So far I think we are arriving at a necessary 
but insufficient level of definition.

My position is that we are describing IT Service-Oriented 
Architecture, not, for instance, a more traditional Plumbing or 
Aerospace Plumbing Service-Oriented Architecture. Nor are we 
describing a First Order Philosophical Principle.

In the information technology context, given the parameters of fluid 
dynamics within the temperature ranges that support human life as we 
know it, we would certainly have a welcome ontological (taxonomical 
actually, IMO) slot for such plumbing SOAs as the examples offered. 
Gowever, those taxonomies would only come into play one or two levels 
of abstraction below the Reference Model. However, semantically and 
ontologically, I think we need to make our work clearly applicable in 
an easily and clearly comprehensible way, exactly as expressed in the 
charter: for a non-technical audience.

I just want our work to be fully grounded as opposed to 
non-normatively tethered to the concrete. I don't see a hard and fast 
separation between abstract and concrete that doesn't flirt with 
irrelevance or court being dismissed out of hand by either the 
commercial or academic communities.


At 9:08 AM -0400 4/8/05, Matthew MacKenzie wrote:
>Personally, I'm not game for votes on individual definitions.  I 
>just want to reiterate my assertion that "invoke" is too narrow a 
>word here, given the discussion that took place originally over 
>"requester" vs. "consumer".  I'm still not convinced such a role is 
>even required to be defined in this document unless the consensus is 
>to model the RM in a "rigid" modeling language.
>On 8-Apr-05, at 2:34 AM, Gregory A. Kohring wrote:
>>Here is a summary of yesterdays proposals for defining
>>the term "Service Consumer":
>>1) Software that invokes an instance,
>>2) Software that uses a service instance,
>>3) An agent that wishes to interact with a service,
>>4) An agent that interacts with a service in order to
>>    achieve a goal,
>>5) An entity that binds with a service is playing the
>>    role of service consumer,
>>where the suggested definition of "agent" was:
>>1) An Agent is a software program acting on behalf of an owner.
>>(By substituting this definition in some of the above suggestions
>>you can come up with yet more definitions of service consumer.)
>>Now, just out of curiosity, how do we proceed from here?
>>Do we vote on one of the suggested definitions? (This implies we
>>should vote on the definitions of all the terms to be used in the
>>final document.) Or do we leave it up to the editors to pick the
>>definition which best fits the style of writing being used
>>within the final document?
>>-- Greg
>>G.A. Kohring
>>C&C Research Laboratories, NEC Europe Ltd.
>Matthew MacKenzie
>* Read my blog! http://blog.tekni.ca/

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309

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