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.
Ciao,
Rex
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.
>
>-matt
>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
