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] Requesters vs. Consumers


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.


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

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