Re: should web services be strictly stateless accessible thru browser and RDFying HTML etc...

On Mon, May 06, 2002 at 12:59:19PM -0400, Christopher Ferris wrote:
> > Reading thru the requirements doc, I have few questions and one comment!
> > 
> > D-AC011.1.5 statelessness
> > 
> > which comes from design principles of the current web,
> > 
> > Does it indicate that web services can not contain state?.
> 
> 
> statelessness != no managed state. clearly there is state on the
> web. rather, statelessness refers to the characteristics of the
> underlying infrastructure, and its architecture, as having no
> direct dependency on the state of the resources with which it
> interacts.

In Web architecture, "stateless" refers to the notion that all the
information necessary to process a message is available in the message
itself.  This provides lots of benefits, primarily improved visibility
(intermediaries can understand what's going on as well as the end
points), and scalability (the server isn't required to remember anything
about the client, and consume resources doing it).

Note that cookies are stateful.

> > which states that user can use a browser to interact with a web service.
> > Does it mean that every web service shall have a UI part to it?.
> 
> 
> not necessarily. it says 'can', not MUST, which implies that as a CSF,
> access to a Web Service via a browser interface would be a
> "good thing(tm)". If the architecture precludes this, that might
> be considered an artificial separation of the web information space
> which some consider to be a "bad thing".

Agreed.

> > A Web service is a software application identified by a URI, whose
> > interfaces and binding are capable of being defined, described and
> > discovered by XML artifacts and supports direct interactions with other
> > software applications using XML based messages via internet-based protocols
> 
> 
> As it says in the WD, the definition is a work in progress which the WG will
> reconsider once we've gotten a better handle on what the requirements
> are.
> 
> 	"The Working Group has jointly come to agreement on the following
> 	working definition:"
>          ^^^^^^^

Also, having a URI and supporting GET is all that's needed for a browser
interface.  The resource/service need not support the UI, as the browser
could support that itself, or dispatch to a local app that supports it.
For example, a vCard is not a UI, it's a declaration of a virtual
business card.  But most browsers know how to display them.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Monday, 6 May 2002 16:54:41 UTC