Yes, but sessions can be supported by SOAP headers. This might require clear documentation and/or client libraries, but that should be no barrier. In the real world, solutions need to be implemented. The web service itself might be stateless but there will often be many ways, depending on the technologies used, to implement stateful sessions.

Tony

"THOMAS, JAI [AG-Contractor/1000]" <[EMAIL PROTECTED]> wrote on 23/12/2004 16:03:54:

> I don't believe having many clients is the real reason. All
> enterprise-level systems handle multiple clients and most of them
> deal with instance specific (session) state information. What makes
> a web service different is that it is platform independent and
> expected to be 100% interoperable. Now, interoperability is ensured
> by specifying your service using standard wsdl and there is no
> standard way to define state information in wsdl.  In other words,
> you cannot build a web service which is stateful and at the same
> time interoperable.

>  
> Also, many service implementations do not support state management.
>  
> Yet another point is, in an architectural view web services are
> mostly SOA implementations and they use stateless protocols such as
> http, jms etc. An ideal web service performs one or more business
> functions to accomplish a logical business 'service'. Client state
> does not come into the picture in any of these and it just doesn't
> look natural.

>  
> Jai
>  
>  
>  
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 23, 2004 5:50 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Web Service with state

>
> Each web service instance could, potentially, process requests from
> many different clients. I'm sure that this is the reason for the
> stateless requirement. Static state is not an issue, only instance
> state, where the service stores information from previous requests
> to process future requests, is prohibited. State can be stored in a
> session, if necessary.
>
> Tony
>
> "Rajdeep Dua" <[EMAIL PROTECTED]> wrote on 23/12/2004 10:08:03:
>
> > I had asked this question yesterday also.
> > Wanted to know why the J2EE and JAX-RPC specs talk
> > about web service to be represented using stateles
> > components when there can be several instances of
> > usage for a stateful usage
> > --- Merten Schumann <[EMAIL PROTECTED]> wrote:
> >
> > > Yes, in fact in J2EE 1.4 only stateless session
> > > beans (not statefull
> > > ones) can expose their interface as web service.
> > > But, the quotation was
> > > not that implementation specific, it was "web
> > > service has to be
> > > state-less" and this is not true IMHO. I do maintain
> > > "global state" in
> > > my web service (just static variables right now)
> > > which could be accessed
> > > by any SLSB instance within the same JVM. Works for
> > > EJB way (SLSB) and
> > > JAX-RPC way.
> > >  
> > > cu
> > >    Merten
> > >
> > >
> > > ________________________________
> > >
> > >    From: Peter Smith
> > > [mailto:[EMAIL PROTECTED]
> > >    Sent: Thursday, December 23, 2004 5:11 AM
> > >    To: [EMAIL PROTECTED]
> > >    Subject: Re: Web Service with state
> > >    
> > >    
> > >    
> > >    
> > >
> > >          Have read that web service has to be state-less.
> > > Why is that?
> > >              
> > >
> > >      
> > >       Where did you read that?
> > >       Maybe it's a hint which should be followed if
> > > possible,
> > > but nothing more
> > >       IMHO.
> > >        
> > >
> > >    
> > >    From J2EE1.4 web services point of view this is not
> > > a "hint" at
> > > all....
> > >    
> > >    See "Web Services for J2EE, Version 1.0" (aka
> > > JSR-109 for
> > > J2EE1.4) [ref
> > > http://www.jcp.org/en/jsr/detail?id=109]
> > >    
> > >    [section 5.3.2.1 EJB Container programming model] A
> > > Service
> > > implementation bean *must* be a stateless object
> > >    
> > >    [section 5.3.2.2 Web Container programming model] A
> > > Service
> > > implementation *must* be a stateless object
> > >    
> > >    and [section 1.4 document conventions] "MUST"
> > > meaning is from
> > > RFC 2119 [ref http://www.faqs.org/rfcs/rfc2119.html]
> > > meaning "absolute
> > > requirement of the specification"
> > >    
> > >    Peter.
> > >    
> > >      
> > >
> > >    This is an email from Fujitsu Australia Software
> > > Technology Pty
> > > Ltd, ABN 27 003 693 481. It is confidential to the
> > > ordinary user of the
> > > email address to which it was addressed and may
> > > contain copyright and/or
> > > legally privileged information. No one else may
> > > read, print, store, copy
> > > or forward all or any of it or its attachments. If
> > > you receive this
> > > email in error, please return to sender. Thank you.
> > >    
> > >    If you do not wish to receive commercial email
> > > messages from
> > > Fujitsu Australia Software Technology Pty Ltd,
> > > please email
> > > [EMAIL PROTECTED]
> > >    
> > >    
> > >
> > >
> >
> >
> >
> >      
> > __________________________________
> > Do you Yahoo!?
> > Send holiday email and support a worthy cause. Do good.
> > http://celebrity.mail.yahoo.com
> >

Reply via email to