Hi Thomas,
(B
(B I believe that you refered to the JAX-RPC spec too, however, your
(Bsuggestions below may be had misgivings about misunderstanding with
(Bthe spec.
(B
(BThe spec said as follows:
(B.........*.........*.........*.........*.........*.........*.........*
(B13.2 Session Management
(B :
(BIn the JAX-RPC 1.0 version, the session management mechanisms require
(Buse of HTTP as the transport in the protocol binding. This version of
(Bthe JAX-RPC specification does not specify (or require) session
(Bmanagement using SOAP headers given that there is no standard SOAP
(Bheader representation for the session information. SOAP based session
(Bmanagement may be considered in the future versions of the JAX-RPC
(Bspecification.
(B
(BA JAX-RPC runtime system is required to use at least one of the
(Bfollowing 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
(Bmanagement (on SOAP over HTTP), he'd better use whichever way what is
(Bspecified in the extract above.
(B (Excluding, you are talking about the future spec of JAX-RPC or
(Bthe other protocol bindings.)
(B
(BRegards,
(B
(B Toshiyuki Kimura <[EMAIL PROTECTED]>
(B R&D Headquarters
(B NTT DATA Corp.
(B
(B-----Original Message-----
(BFrom: [EMAIL PROTECTED]
(BSent: Wednesday, January 15, 2003 2:39 PM
(BTo: [EMAIL PROTECTED]
(BSubject: RE: Stateful Web Services
(B
(BAs usual it is always a little bit more complicated than that .....
(B
(BThere is not a lot of "standard" API interface to Web Services.
(BSun has a standard API called JAXRPC which can be used as a standard web
(Bservice client API, where the notion of session is defined, but it is left
(Bto the person implementing this API to decide how to implement the session
(Bsupport.
(B
(BWhat is "well" defined in the web services area is the protocol/encoding
(Bused for exchanging request/response between the client and the server. The
(Bmost used and well known encoding is SOAP (encode the response/request in
(BXML a specific way) and the most used and well known protocol is HTTP.
(B
(BSo, if you consider a web service using SOAP over HTTP, most of the
(Breasonable web service package (server and/or client) supporting such web
(Bservice will also support the handling of HTTP cookies and then support
(Bsession handling.
(B
(BBut everybody is trying to get away from this kind of solution as the
(Bsession rely on a specific transport feature (HTTP cookie in that case).
(BWhat happen if tomorrow you want to have your web service available over JMS
(Bor SMTP?
(B
(BThe "right" way to do session handling in SOAP Web Services is to use SOAP
(Bheaders. You define your own header and you take care of making sure that
(Byour client and server are both handling the session through this header.
(BAutomatic support of SOAP header is getting better and better in the current
(BSOAP packages (for example, with Axis as the SOAP server and .NET C# as the
(Bclient application, you can have a stateful web service with very little
(Bextra code compare to your regular client and server implementation if you
(Bconfigure all that properly).
(B
(B>From your web service implementation, if you use a java based SOAP server
(Bengine, for sure you can connect to an EJB, regular Java Bean or JDBC
(Bsession. After that, according to the SOAP engine you will use you will have
(Bto write a different amount of code to plug all that together and maintain
(Bthe session. In general, it should be very similar (or sometimes even
(Beasier) to doing the same thing with a regular servlet.
(B
(BThomas
(B
(B-----Original Message-----
(BFrom: David Peterson [mailto:[EMAIL PROTECTED]]
(BSent: Tuesday, January 14, 2003 9:36 PM
(BTo: [EMAIL PROTECTED]
(BSubject: Re: Stateful Web Services
(B
(BAnne,
(B
(BThanks for the link and info.
(B
(BDo you know, can I still use an approach such as connecting a web
(Bservice to a EJB, or regular Java Bean, or a JDBC session?
(B
(BIt surprises me that the concept of a stateful web service has not been
(Btackled by various web services standards bodies (e.g. OASIS for example)!
(B
(BRegards,
(B
(BDavid
(B
(BAnne 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
