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

Well put, Eric.  It seems to me that you could dress this up just a bit
and come up with some candidate verbiage for the document ...  Hint,
hint ...

-----Original Message-----
From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] 
Sent: Sunday, June 22, 2003 12:21 PM
To: Assaf Arkin
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



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.

Eric

-----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:

>Hi,
>
>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

arkin

>Eric
>  
>

Received on Monday, 23 June 2003 11:44:03 UTC