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 Saturday, 21 June 2003 23:16:31 UTC