Re: [oslc-core] Consumer/provider vs Client/server

[Steve K Speicher <sspeiche@us.ibm.com>]

> From: Martin P Pain <martinpain@uk.ibm.com>
> To: oslc-core@lists.oasis-open.org
> Date: 05/15/2014 06:01 AM
> Subject: [oslc-core] Consumer/provider vs Client/server
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> Two more arguments for consumer/provider over client/server: 
> 
> 1. Consumer/provider allows verb forms "to consume [OSLC/domain]"
and "to 
> provide [OSLC/domain]". Client/server does not have matching
verbs. At least
> not for client side, and "to serve" doesn't necessarily
imply the same as 
> "to provide". 
> 

The proposal isn't to rule out verbs, it is to limit
our terminology to well-defined already agreed upon terminology used by
the specs we are based on and not create new normative terminology.  As
you read the HTTP and LDP specs, they are structured as send or handle
request, or send response, etc.  It gets confusing if we have various
terms that mean the same or near the same thing.

I think if we look at the definitions side-by-side
and in context you'll see it makes things much easier for those implementers
and other readers of HTTP and LDP specs to quickly jump into OSLC.

Client
A program that establishes connections for the purpose
of sending requests [HTTP11].
Server
An application program that accepts connections in order
to service requests by sending back responses.

Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request [HTTP11].

Interesting enough, OSLC Core 2.0 doesn't define what an "OSLC Consumer" is at all.

We don't have "OSLC Provider" either, though we have:
OSLC Service Provider: a product or online service offering that provides an implementation of one or more OSLC Services, which may themselves implement different OSLC Domain specifications.


Perhaps you could propose definitions of these that differ from what is given from HTTP11 and why it is needed.

> 2. Registries. In the case where a provider is adding resources to a
> registry, rather than acting as the server itself (so the provider PUTs or
> POSTs resources to a registry, and the consumer GETs them from the registry)
> then the "provider" is a "client" to the registry, and the "consumer" is a
> "client" to the registry - the "registry" is a server to both, but may or
> may not be seen as the "provider". (The client hopefully doesn't need to
> know the difference, but the provider is the one responsible for fulfilling
> the requirements of the domain spec(s), not the registry.)
> I don't know how well we support this scenario, but I believe it has been
> mentioned a couple of times before in the Automation WG.
>
I find this description a bit confusing, if a provider is a client, then it is a an application program capable of sending requests and receiving requests.  Which falls into the definitions from HTTP11 for client and server.


> So then "client" and "server" (in their HTTP sense) would refer to the two
> parties involved in any given HTTP request/response (we wouldn't have to use
> these often)
> And "consumer" and "provider" would refer to the roles and responsibilities
> within the OSLC core and domain specs.
>

Well in the sense of within OSLC core and domain specs, interaction is accomplished through requests and responses from a client to a server.  Perhaps we can sketch out some spec text on a wiki or a current spec to see what the problems are.  Discussing consumers and providers might be useful in enablement material or other educational material to get concepts across within given user stories.  I'm not sure it improves the normative ways we write clauses in specs.  Though I'd need more examples to understand more.

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> http://open-services.net



>
> Martin Pain
> Software Developer - Green Hat
> Rational Test Virtualization Server, Rational Test Control Panel
> OASIS Open Services for Lifecycle Collaboration - Automation technical committee chair
>
> E-mail: martinpain@uk.ibm.com
> Find me on: [image removed]  and within IBM on: [image removed]  
>
> [image removed]
>
>
>
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU