I would not view the JAX-RPC 1.0 spec as the definitive source of Web
(Bservices standards information. Particularly when it comes to advanced
(Bfeatures such as session management, security, reliability, etc. As Thomas
(Bsaid, the "right" way to implement stateful sessions is to use SOAP headers.
(BThat's how Systinet does it. That's how BEA's proposal suggests we do it.
(BBut no one has attempted to standardize it yet. (it's lower on the priority
(Blist than security and reliability)
(B
(BIf you dig, you'll find that a number of folks believe that stateful
(Bsessions are a "bad" thing. Quite a few folks even get religious about it.
(B
(BAnne
(B
(B> -----Original Message-----
(B> From: Toshiyuki Kimura [mailto:[EMAIL PROTECTED]]
(B> Sent: Wednesday, January 15, 2003 4:35 AM
(B> To: [EMAIL PROTECTED]
(B> Subject: Re: Stateful Web Services
(B>
(B>
(B> Hi Thomas,
(B>
(B> I believe that you refered to the JAX-RPC spec too, however, your
(B> suggestions below may be had misgivings about misunderstanding with
(B> the spec.
(B>
(B> The spec said as follows:
(B> .........*.........*.........*.........*.........*.........*.........*
(B> 13.2 Session Management
(B> :
(B> In the JAX-RPC 1.0 version, the session management mechanisms require
(B> use of HTTP as the transport in the protocol binding. This version of
(B> the JAX-RPC specification does not specify (or require) session
(B> management using SOAP headers given that there is no standard SOAP
(B> header representation for the session information. SOAP based session
(B> management may be considered in the future versions of the JAX-RPC
(B> specification.
(B>
(B> A JAX-RPC runtime system is required to use at least one of the
(B> following mechanisms to manage sessions:
(B>
(B> - Cookie based ...
(B> - URL rewriting ...
(B> - SSL session ...
(B> :
(B> .........*.........*.........*.........*.........*.........*.........*
(B>
(B> A develper (someone) wants to follow the spec regarding the session
(B> management (on SOAP over HTTP), he'd better use whichever way what is
(B> specified in the extract above.
(B> (Excluding, you are talking about the future spec of JAX-RPC or
(B> the other protocol bindings.)
(B>
(B> Regards,
(B>
(B> Toshiyuki Kimura <[EMAIL PROTECTED]>
(B> R&D Headquarters
(B> NTT DATA Corp.
(B>
(B> -----Original Message-----
(B> From: [EMAIL PROTECTED]
(B> Sent: Wednesday, January 15, 2003 2:39 PM
(B> To: [EMAIL PROTECTED]
(B> Subject: RE: Stateful Web Services
(B>
(B> As usual it is always a little bit more complicated than that .....
(B>
(B> There is not a lot of "standard" API interface to Web Services.
(B> Sun has a standard API called JAXRPC which can be used as a standard web
(B> service client API, where the notion of session is defined, but it is left
(B> to the person implementing this API to decide how to implement the session
(B> support.
(B>
(B> What is "well" defined in the web services area is the protocol/encoding
(B> used for exchanging request/response between the client and the
(B> server. The
(B> most used and well known encoding is SOAP (encode the response/request in
(B> XML a specific way) and the most used and well known protocol is HTTP.
(B>
(B> So, if you consider a web service using SOAP over HTTP, most of the
(B> reasonable web service package (server and/or client) supporting such web
(B> service will also support the handling of HTTP cookies and then support
(B> session handling.
(B>
(B> But everybody is trying to get away from this kind of solution as the
(B> session rely on a specific transport feature (HTTP cookie in that case).
(B> What happen if tomorrow you want to have your web service
(B> available over JMS
(B> or SMTP?
(B>
(B> The "right" way to do session handling in SOAP Web Services is to use SOAP
(B> headers. You define your own header and you take care of making sure that
(B> your client and server are both handling the session through this header.
(B> Automatic support of SOAP header is getting better and better in
(B> the current
(B> SOAP packages (for example, with Axis as the SOAP server and .NET
(B> C# as the
(B> client application, you can have a stateful web service with very little
(B> extra code compare to your regular client and server implementation if you
(B> configure all that properly).
(B>
(B> From your web service implementation, if you use a java based SOAP server
(B> engine, for sure you can connect to an EJB, regular Java Bean or JDBC
(B> session. After that, according to the SOAP engine you will use
(B> you will have
(B> to write a different amount of code to plug all that together and maintain
(B> the session. In general, it should be very similar (or sometimes even
(B> easier) to doing the same thing with a regular servlet.
(B>
(B> Thomas
(B>
(B> -----Original Message-----
(B> From: David Peterson [mailto:[EMAIL PROTECTED]]
(B> Sent: Tuesday, January 14, 2003 9:36 PM
(B> To: [EMAIL PROTECTED]
(B> Subject: Re: Stateful Web Services
(B>
(B> Anne,
(B>
(B> Thanks for the link and info.
(B>
(B> Do you know, can I still use an approach such as connecting a web
(B> service to a EJB, or regular Java Bean, or a JDBC session?
(B>
(B> It surprises me that the concept of a stateful web service has not been
(B> tackled by various web services standards bodies (e.g. OASIS for example)!
(B>
(B> Regards,
(B>
(B> David
(B>
(B> Anne Thomas Manes wrote:
(B>
(B> >It depends on the SOAP implementation you're using. Most products don't
(B> >support stateful services. Some do: Systinet WASP, Oracle SOAP, Apache
(B> >SOAP, maybe a few others. Interoperability is a big issue, though. BEA
(B> >published a proposed SOAP extension called SOAP Conversation
(B> >(http://dev2dev.bea.com/techtrack/SOAPConversation.jsp), but I don't
(B> >think it's getting much traction.
(B> >
(B> >Anne
(B> >
(B> >>-----Original Message-----
(B> >>From: David Peterson [mailto:[EMAIL PROTECTED]]
(B> >>Sent: Tuesday, January 14, 2003 5:25 PM
(B> >>To: [EMAIL PROTECTED]
(B> >>Subject: Stateful Web Services
(B> >>
(B> >>Hi All,
(B> >>
(B> >>I have a bit of a newbie question in relation to web services:
(B> >>
(B> >>Do SOAP-based web services support the concept of state and
(B> >>persistence? That is, can I easily create a web service where state is
(B> >>preserved between invocations?
(B> >>
(B> >>For example, can I create a "bank account" web service, which supports
(B> >>deposit(), withdrawl() and getBalance() operations, and have that web
(B> >>service preserve the current account balance between separate
(B> >>invocations?
(B> >>
(B> >>I imagine that I could achieve this with web services by using an
(B> >>external persistence component, eg an EJB, or a JDBC call to a
(B> >>database. What I want to know is whether I can preserve state
(B> >>internally (inside a web service component) by simply declaring an
(B> >>instance variable appopriately (e.g. "static" - though this might not
(B> >>be the right approach).
(B> >>
(B> >>On the other hand, is my only "stateful web service" option to use an
(B> >>external persistence layer (JDBC or EJB?)
(B> >>
(B> >>Thanks.
(B> >>
(B> >>David Peterson
(B>
