RE: Stateful Web Services

Anne Thomas Manes Thu, 16 Jan 2003 04:58:34 -0800
(sorry, I'm no longer subscribed to the dev list, please forward my mail if
you deem appropriate)

My comment about JAX-RPC refers to the fact that the JCP isn't really in a
position to define Web services standards. It is defining standard Java
bindings to the Web services standards. (very useful to the Java community,
but not the same as creation of the basic standards.) The standards are
being defined at W3C and OASIS.

The JAX-RPC spec even implies as much when it says
> > This version of
> > the JAX-RPC specification does not specify (or require) session
> > management using SOAP headers given that there is no standard SOAP
> > header representation for the session information.

I agree with you. Once formal SOAP headers for session management have been
defined, SOAP implementers should build automatic support for them into
their products. Users should have a very simple mechanism to request
stateful sessions, and the SOAP platform should just handle it
automatically. Doing session management via standard SOAP headers will
ensure cross-vendor interoperability and support identical functionality
across any transport protocol.

Best regards,
Anne

> -----Original Message-----
> From: Toshiyuki Kimura [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 16, 2003 3:12 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Stateful Web Services
>
>
> Hi Thomas and Anne,
>
>   Do you mean "Whatever is unjust is not held to be a law
> (i.e. the spec)" ?  :-)
>
>   Usually, the first commited spec is used to having some
> problems; for example, The HTTP/1.0 has some issues in
> the security, and performance. And the SOAP/1.1 also has
> some interoperability problems in the cause of the spec's
> indetermination like as the current situation.
> Please note that I don't want to deny your thought.
>
>   Just I want to say is ...
>
>   This matter should be discussed after separating two
> layers. One is user group like as axis-user they just use
> the WebService Runtime platform (i.e. AXIS). The other is
> developer group like as axis-dev they develop (or optimize)
> to their own WebService Runtime.
>   Because your opinion seems to be the develper group point
> of view. If someone wants to session mechanism, basically he
> has to do is just "session.maintain = true".  The cookies,
> any SOAP Header fields, or the protocol binding should not
> be cared by the user level.  It'll be handled some vendors
> (may be in developer gropups) in the near future.
>
> That's all I'd like to notify.
>
> Regards,
>
>     Toshiyuki Kimura <[EMAIL PROTECTED]>
>     R&D Headquarters
>     NTT DATA Corp.
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 16, 2003 12:01 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Stateful Web Services
>
> I agree with Anne comments for sure. JAX-RPC is even representing only one
> specific type of Web Service interface (SOAP/HTTP). When you look at the
> different activities around Web Services (SOAP over JMS, WSIF with native
> binding to EJB/JCA/JMS/....) you realize quickly that the scope is bigger
> than that, and it still needs to mature a little bit before definitive
> position on how to handle session (for example) must be done.
>
> On the religious attitude of stateful sessions being a bad thing, I am not
> so convinced, but it is probably a very subjective matter :-)
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 15, 2003 8:47 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Stateful Web Services
>
> I would not view the JAX-RPC 1.0 spec as the definitive source of Web
> services standards information. Particularly when it comes to advanced
> features such as session management, security, reliability, etc. As Thomas
> said, the "right" way to implement stateful sessions is to use
> SOAP headers.
> That's how Systinet does it. That's how BEA's proposal suggests we do it.
> But no one has attempted to standardize it yet. (it's lower on
> the priority
> list than security and reliability)
>
> If you dig, you'll find that a number of folks believe that stateful
> sessions are a "bad" thing. Quite a few folks even get religious about it.
>
> Anne
> > -----Original Message-----
> > From: Toshiyuki Kimura [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, January 15, 2003 4:35 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Stateful Web Services
> >
> > Hi Thomas,
> >
> >   I believe that you refered to the JAX-RPC spec too, however, your
> > suggestions below may be had misgivings about misunderstanding with
> > the spec.
> >
> > The spec said as follows:
> > .........*.........*.........*.........*.........*.........*.........*
> > 13.2 Session Management
> >          :
> > In the JAX-RPC 1.0 version, the session management mechanisms require
> > use of HTTP as the transport in the protocol binding. This version of
> > the JAX-RPC specification does not specify (or require) session
> > management using SOAP headers given that there is no standard SOAP
> > header representation for the session information. SOAP based session
> > management may be considered in the future versions of the JAX-RPC
> > specification.
> >
> > A JAX-RPC runtime system is required to use at least one of the
> > following mechanisms to manage sessions:
> >
> >  - Cookie based  ...
> >  - URL rewriting ...
> >  - SSL session   ...
> >          :
> > .........*.........*.........*.........*.........*.........*.........*
> >
> >   A develper (someone) wants to follow the spec regarding the session
> > management (on SOAP over HTTP), he'd better use whichever way what is
> > specified in the extract above.  (Excluding, you are talking about the
> > future spec of JAX-RPC or the other protocol bindings.)
> >
> > Regards,
> >
> >     Toshiyuki Kimura <[EMAIL PROTECTED]>
> >     R&D Headquarters
> >     NTT DATA Corp.
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > Sent: Wednesday, January 15, 2003 2:39 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: Stateful Web Services
> >
> > As usual it is always a little bit more complicated than that .....
> >
> > There is not a lot of "standard" API interface to Web Services. Sun
> > has a standard API called JAXRPC which can be used as a standard web
> > service client API, where the notion of session is defined, but it is
> > left to the person implementing this API to decide how to implement
> > the session support.
> >
> > What is "well" defined in the web services area is the
> > protocol/encoding used for exchanging request/response between the
> > client and the server. The most used and well known encoding is SOAP
> > (encode the response/request in XML a specific way) and the most used
> > and well known protocol is HTTP.
> >
> > So, if you consider a web service using SOAP over HTTP, most of the
> > reasonable web service package (server and/or client) supporting such
> > web service will also support the handling of HTTP cookies and then
> > support session handling.
> >
> > But everybody is trying to get away from this kind of solution as the
> > session rely on a specific transport feature (HTTP cookie in that
> > case). What happen if tomorrow you want to have your web service
> > available over JMS or SMTP?
> >
> > The "right" way to do session handling in SOAP Web Services is to use
> > SOAP headers. You define your own header and you take care of making
> > sure that your client and server are both handling the session through
> > this header. Automatic support of SOAP header is getting better and
> > better in the current SOAP packages (for example, with Axis as the
> > SOAP server and .NET C# as the
> > client application, you can have a stateful web service with very little
> > extra code compare to your regular client and server
> implementation if you
> > configure all that properly).
> >
> > From your web service implementation, if you use a java based SOAP
> > server engine, for sure you can connect to an EJB, regular Java Bean
> > or JDBC session. After that, according to the SOAP engine you will use
> > you will have to write a different amount of code to plug all that
> > together and maintain the session. In general, it should be very
> > similar (or sometimes even
> > easier) to doing the same thing with a regular servlet.
> >
> > Thomas
> > -----Original Message-----
> > From: David Peterson [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, January 14, 2003 9:36 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Stateful Web Services
> >
> > Anne,
> >
> > Thanks for the link and info.
> >
> > Do you know, can I still use an approach such as connecting a web
> > service to a EJB, or regular Java Bean, or a JDBC session?
> >
> > It surprises me that the concept of a stateful web service has not
> > been tackled by various web services standards bodies (e.g. OASIS for
> > example)!
> >
> > Regards,
> >
> > David
> >
> > Anne Thomas Manes wrote:
> >
> > >It depends on the SOAP implementation you're using. Most products
> > >don't support stateful services. Some do: Systinet WASP, Oracle SOAP,
> > >Apache SOAP, maybe a few others. Interoperability is a big issue,
> > >though. BEA published a proposed SOAP extension called SOAP
> > >Conversation (http://dev2dev.bea.com/techtrack/SOAPConversation.jsp),
> > >but I don't think it's getting much traction.
> > >
> > >Anne
> > >
> > >>-----Original Message-----
> > >>From: David Peterson [mailto:[EMAIL PROTECTED]]
> > >>Sent: Tuesday, January 14, 2003 5:25 PM
> > >>To: [EMAIL PROTECTED]
> > >>Subject: Stateful Web Services
> > >>
> > >>Hi All,
> > >>
> > >>I have a bit of a newbie question in relation to web services:
> > >>
> > >>Do SOAP-based web services support the concept of state and
> > >>persistence? That is, can I easily create a web service where state
> > >>is preserved between invocations?
> > >>
> > >>For example, can I create a "bank account" web service, which
> > >>supports deposit(), withdrawl() and getBalance() operations, and
> > >>have that web service preserve the current account balance between
> > >>separate invocations?
> > >>
> > >>I imagine that I could achieve this with web services by using an
> > >>external persistence component, eg an EJB, or a JDBC call to a
> > >>database. What I want to know is whether I can preserve state
> > >>internally (inside a web service component) by simply declaring an
> > >>instance variable appopriately (e.g. "static" - though this might
> > >>not be the right approach).
> > >>
> > >>On the other hand, is my only "stateful web service" option to use
> > >>an external persistence layer (JDBC or EJB?)
> > >>
> > >>Thanks.
> > >>
> > >>David Peterson
>
RE: Stateful Web Services

Reply via email to
