A follow up:
I agree that we don't want to go around defining ownership etc. It is
outside our remit.
However, there are several potential -ilities that we may need to
consider: security, manageability, privacy, etc. Most of these impinge
directly on the issue of control.
Frank
On Apr 1, 2005, at 9:46 AM, Duane Nickull wrote:
> Francis:
>
> I concur.
>
> I think that some of these concept map ideas were the start of the
> death spiral for the W3C Web Services Architecture. I was never
> convinced that the concept of an "owner" was relevant to a generic
> architecture like the WSA, and I am even less convinced that such a
> concept belongs in a reference model.
>
> In previous groups, we have been warned about adding anything of a
> legal nature in OASIS specs due to the pandora's box it opens.
>
> Duane
>
> Francis McCabe wrote:
>
>> We originally wanted to use the term *legal entity* to represent the
>> 'owner' of the agent(s) participating. However, we were advised by
>> W3C's legal whatever that this was not a good choice. (Too
>> politically charged apparently); there was also the possibility of an
>> un-owned agent participating (the mind boggles a bit at this).
>> However, in common usage, legal entity includes people and
>> corporations.
>>
>> This is a tricky area, on the one hand it seems blinkered to pretend
>> that we are not designing systems for and on behalf of people. On the
>> other hand, taking people fully into account seems to take us into
>> realms where our expertise is not appropriate.
>>
>> Frank
>>
>>
>>
>> On Mar 31, 2005, at 5:17 PM, Thomas Erl wrote:
>>
>>> It's probably a good time to think about which term we should use to
>>> represent the potential element responsible for invoking or
>>> initiating a
>>> conversation with a service acting as the service provider.
>>> Regardless of
>>> whether this becomes an "official" element within our reference
>>> model, we
>>> will likely need to reference such an element in our documentation.
>>>
>>> Below are some considerations we can take into account:
>>>
>>> - Both of the position papers submitted so far incorporate the term
>>> "consumer". This term is also used in the ebSOA specification.
>>>
>>> - The W3C Web Services Architecture document submitted by Frank
>>> McCabe uses
>>> the term "requester" and further qualifies it by suffixing it with
>>> "entity"
>>> or "agent" to represent the owner and software program respectively.
>>> (Prior
>>> to the current version of the W3C Working Note, this document used
>>> the term
>>> "service requester" instead of "requester agent".)
>>>
>>> - The W3C Web Services Glossary does not provide a definition for
>>> "consumer",
>>> but defines "requester agent" as follows: "A software agent that
>>> wishes to
>>> interact with a provider agent in order to request that a task be
>>> performed
>>> on behalf of its owner - the requester entity."
>>>
>>> - The term "requester agent" is used in the W3C WSDL 2.0
>>> specification,
>>> whereas "consumer" is used in the WSDL 1.1 version.
>>>
>>> - The definitions document submitted by Rebekah uses the term
>>> "requester",
>>> most likely because the initial set of definitions were provided by
>>> Frank.
>>>
>>> Given that we are seeking industry-wide acceptance of our reference
>>> model,
>>> there may be a benefit to keeping our terminology in alignment with
>>> terms
>>> already in use by established (albeit implementation-specific)
>>> specifications. I personally have no preference, but I do recommend
>>> we
>>> decide on one term and then consider adding a definition to our
>>> glossary. We
>>> may want to leverage some of the work performed by the W3C Working
>>> Group and
>>> decide whether we also need separate terms to distinguish owner from
>>> implementation.
>>>
>>> On a related note, we have not yet discussed the concept of a
>>> service or
>>> service agent assuming provider and requester/consumer roles. Such a
>>> concept
>>> would also affect our definitions.
>>>
>>> Thomas
>>
>>
>
> --
> ***********
> Senior Standards Strategist - Adobe Systems, Inc. -
> http://www.adobe.com
> Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
> Adobe Enterprise Developer Resources -
> http://www.adobe.com/enterprise/developer/main.html
> ***********
>