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"


Agreed. I suspect that it such would, indeed, be the case, and 
probably in many more domains as well.

Ciao,
Rex

At 3:40 PM -0400 4/10/05, Chiusano Joseph wrote:
><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:rexb@starbourne.com]
>>  Sent: Friday, April 08, 2005 10:49 AM
>>  To: Matthew MacKenzie; Gregory A. Kohring
>>  Cc: soa-rm@lists.oasis-open.org
>>  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
>>  >matt@mac-kenzie.net
>>  >* 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
>>


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