<Quote>
My position is that we are describing IT Service-Oriented Architecture,
not, for instance, a more traditional Plumbing or Aerospace Plumbing
Service-Oriented Architecture.
</Quote>
Additional point: If, to carry out its mission and goals, an aerospace
plumbing operation* could function more efficiently by being supported
by systems and technologies that are architected according to
service-oriented principles, then I believe that such an aerospace
plumbing operation can benefit from the work that we are doing.
*using "operation" in business operation terms, not WSDL terms
Joe
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
> -----Original Message-----
> From: Rex Brooks [mailto:]
> Sent: Friday, April 08, 2005 10:49 AM
> To: Matthew MacKenzie; Gregory A. Kohring
> Cc:
> 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.
>
> 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
>