Mailing-List: contact axis-user-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-user@xml.apache.org
Message-ID: <001901c2be2a$abe1a1b0$3989080a@rd.nttdata.co.jp>
From: "Toshiyuki Kimura" <kimuratsy@nttdata.co.jp>
To: <axis-user@xml.apache.org>, <axis-dev@xml.apache.org>
Subject: Re: Stateful Web Services
Date: Fri, 17 Jan 2003 22:16:33 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit

Hi Thomas,

  I'm delighted that you show me understanding in my thought.

  Anyway, I think if an AXIS user (or whoever) wants to know
anything detailed, that should be welcomed, independent of
the reason.
  In this case, it's very important to the learner that
the well-informed person gives know-how with "how-to"
(use it) and "actual/potential risk".

  In my definition, an AIXS user who wants to implement NON-
http bindings (ex. JMS, SMTP, FTP ...) is not a "user group"
but a "developer group" any more.  If the developer use an
original SOAP header field, it has to solve as his own risks
when he encounters with some troubles (until spec cover it).
I believe it's too hard to do so for "user group" people.

  Finally, I apologise for my unrecommended cross-post in
this thread, and I hope this will be the final message from
me on the same discussion.

Regards,

    Toshiyuki Kimura <kimuratsy@nttdata.co.jp>
    R&D Headquarters
    NTT DATA Corp.

-----Original Message-----
From: thomas.cherel@ascentialsoftware.com
Sent: Thursday, January 16, 2003 11:31 PM
To: axis-dev@xml.apache.org; axis-user@xml.apache.org
Subject: RE: Stateful Web Services

I understand your point of view, but for an Axis user I think it is
also important to understand what is behind "session.maintain=true".
The user can choose this way and the day he has a requirement to support
SOAP over JMS for example, he needs to have a different way to maintain
the session. If he starts to use SOAP headers directly, then as long as
it stays SOAP, whatever the transport protocol is, the session handling
will be the same and it is important information to have as a user,
I believe.

Thomas

-----Original Message-----
From: Toshiyuki Kimura [mailto:kimuratsy@nttdata.co.jp]
Sent: Thursday, January 16, 2003 3:12 AM
To: axis-user@xml.apache.org; axis-dev@xml.apache.org
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 <kimuratsy@nttdata.co.jp>
    R&D Headquarters
    NTT DATA Corp.

-----Original Message-----
From: thomas.cherel@ascentialsoftware.com
[mailto:thomas.cherel@ascentialsoftware.com]
Sent: Thursday, January 16, 2003 12:01 AM
To: axis-user@xml.apache.org
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:anne@manes.net]
Sent: Wednesday, January 15, 2003 8:47 AM
To: axis-user@xml.apache.org
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:kimuratsy@nttdata.co.jp]
> Sent: Wednesday, January 15, 2003 4:35 AM
> To: axis-user@xml.apache.org
> 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 <kimuratsy@nttdata.co.jp>
>     R&D Headquarters
>     NTT DATA Corp.
>
> -----Original Message-----
> From: thomas.cherel@ascentialsoftware.com
> Sent: Wednesday, January 15, 2003 2:39 PM
> To: axis-user@xml.apache.org
> 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:peterson@ee.usyd.edu.au]
> Sent: Tuesday, January 14, 2003 9:36 PM
> To: axis-user@xml.apache.org
> 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:peterson@ee.usyd.edu.au]
> >>Sent: Tuesday, January 14, 2003 5:25 PM
> >>To: axis-user@xml.apache.org
> >>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