W3C home > Mailing lists > Public > www-ws-arch@w3.org > June 2003

RE: Web Service Description and stateful services - (on the 'www-ws@w3.org' list) Debating on a) Stateful Web Service Instances b) Stateful Interaction - OGSI

From: Newcomer, Eric <Eric.Newcomer@iona.com>
Date: Sun, 22 Jun 2003 13:20:37 -0400
Message-ID: <DCF6EF589A22A14F93DFB949FD8C4AB20138E10D@amereast-ems1.IONAGLOBAL.COM>
To: "Assaf Arkin" <arkin@intalio.com>
Cc: "Ugo Corda" <UCorda@SeeBeyond.com>, <www-ws-arch@w3.org>

As Roger pointed out, we are often talking on this list about the same things using different terms, and about different things using the same terms.  The normal case, I guess, without an agreed architecture...

Anyway, I wanted to clarify a point in the discussion.  There are at least two kinds of state mentioned in this thread - application state and transport state.  

It's very true that a majority of Web sites manage some application state.  But HTTP does not include stateful sessions - meaning HTTP does not define a way to maintain a connection beyond what's necessary to execute a single HTTP method.  Many other communication protocols do support the notion of connections that live beyond a single method invocation (including those used in TP monitors whose applications are stateless), but of course that type of connection state requires resources impractical if not impossible to allocate over the WAN which is the Web.

So all we have to work with is application state, and there are no standards for that yet.  But I think we should include this concept anyway in the WSA since as so many replies on this thread point out, it's something that will be necessary for many use cases.


-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Saturday, June 21, 2003 9:18 PM
To: Newcomer, Eric
Cc: Ugo Corda; www-ws-arch@w3.org
Subject: Re: Web Service Description and stateful services - (on the
'www-ws@w3.org' list) Debating on a) Stateful Web Service Instances b)
Stateful Interaction - OGSI

Newcomer, Eric wrote:

>I think semantics and state are different things.  You can have either without the other.  I think of state management as a generic mechanism that's currently missing from Web services since it's also missing from HTTP.  
>So we probably need a new mechanism, perhaps something from BPEL, that just focuses on state management for shared information.
>I do not see an analogy with EJBs since they are designed to reflect the classic three-tier model of TP monitors, which basically exists for the purpose of multiplexing clients or user connections into a smaller number of database connections.  There's a large bit of science on this, but the reason for separating the tiers is basically that you want to be able to size your system based on the number of concurrent transactions rather than the number of concurrent users.  This all does relate to sessions and state management, but Web services are architecturally more like CORBA, n-tiered, and probably a generic state management service is the way to go.
I'm not really advocating that we try and do EJBs in the Web service 
space. As you said, a lot of the solutions there are geared towards 
three-tier model and TP monitors, they were also designed around 
session-based protocols like IIOP. But if you look at the world of TP 
monitors then generally speaking components tend to be stateless so they 
can be pooled and monitored efficiently. EJB tries to simplify some 
programing chores by giving you two additional frameworks to work with. 
I just wonder whether there's a lesson to be learned here and applied to 
the Web service world.

>I'd say the architecture should reflect the fact that state management is necessary for certain use cases of Web services, such as security (i.e. multiple Web services sharing the same security context) or reliable messaging (i.e. multiple parties in a communcation sharing state about the communication), but not cite specific technology yet since there isn't any.
When I sit down and think of it, most of the Web sites I use involve 
state management for one reason or another. Amazon needs at least one 
form of state management to get around the fact that there are not a lot 
of things you can order and get delivered within a single HTTP 
request/reponse cycle. The W3C's Web site has state management to let me 
edit my membership, or just approve their right to log this e-mail. 
Google has state managment to let me change my preferences. Not to 
mention all the service I subscribe to (they better know who I am), 
bloggers and online banking.

So the case for me is that most of the Web sites I access have some form 
of state management, not always involving security or reliable 
messaging, and I'm going to go out on a limb and say that in the 
business space state management may in fact be an overwhelming majority.

What I don't know yet is, do I need specific technology to use all of 
these, and what kind of technology would it be? At least as far as 
processes go, I'm thinking in terms of addressing and coordination. 
Security and reliable messaging, at least as far as I understand it, is 
concerned with the transport protocol and not directly the service


Received on Sunday, 22 June 2003 13:20:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:07 UTC