, April 03, 2003 5:44 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Stateful web services.
See directions for patches at
http://nagoya.apache.org/wiki/apachewiki.cgi?AxisProjectPages/SubmitPatc
hes
--- Clay Graham <[EMAIL PROTECTED]> wrote:
> Absolutely.
>
> I am not real fa
com/
>
>
>
> -Original Message-
> From: Tom Jordahl [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 03, 2003 1:50 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Stateful web services.
>
>
>
> Clay,
>
> This is great. Do you think you
.
making the mobile-world-office
http://www.newobjectivity.com/
-Original Message-
From: Tom Jordahl [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 1:50 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Stateful web services.
Clay,
This is great. Do you think you could che
Tom Jordahl wrote:
Clay,
This is great. Do you think you could check out the current Axis HTML docs and see if you can put together a patch that would integrate this in to it?
Your code could just be new files in the samples directory.
what about adding it to the wiki?
http://nagoya.apache.org/
increase the
chances that someone (me) would check it in to the tree for others.
--
Tom Jordahl
Macromedia Server Development
-Original Message-
From: Clay Graham [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 3:22 PM
To: [EMAIL PROTECTED]
Subject: RE: Stateful web services
ean) call.invoke( new Object[] {
protocol, username, password, hostname, to, cc, bcc, subject, body } );
if(ret.booleanValue())
System.out.println(username+" has successfully sent the
message:"+subject);
else
Hello Axis Users,
I am having a hard time finding out how to create a stateful web
service. For example, if you wanted a mail service you would want to be
able to login to a mail session, hold that session in state, and then
perform multiple actions on that session, like send message, get
messages
Hi,
I am trying to maintain session state between an AXIS client and a C# Web Service. I produced the Java stubs on the client side and tried to set the session state with the setMaintainSession method in the stub, but the data isnt persistent. Did anyone work on this? If so could you kindly p
6, 2003 11:31 PM
(BTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]
(BSubject: RE: Stateful Web Services
(B
(BI understand your point of view, but for an Axis user I think it is
(Balso important to understand what is behind "session.maintain=true".
(BThe user can choose this way and the
Steve Loughran wrote:
think about this for a moment. How are you going to specify bank account and
auth info? If it goes with every request, then you could be stateless.
Otherwise the caller needs to first 'bind' to an account, then make requests
on it. We call that 'state', no matter how it is a
[EMAIL PROTECTED]>
om> cc:
Subject: Re:
Title: 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
ntical functionality
(Bacross any transport protocol.
(B
(BBest regards,
(BAnne
(B
(B> -Original Message-
(B> From: Toshiyuki Kimura [mailto:[EMAIL PROTECTED]]
(B> Sent: Thursday, January 16, 2003 3:12 AM
(B> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
(B> Subject: Re: Statef
s all I'd like to notify.
(B
(BRegards,
(B
(BToshiyuki Kimura <[EMAIL PROTECTED]>
(BR&D Headquarters
(BNTT DATA Corp.
(B
(B-Original Message-
(BFrom: [EMAIL PROTECTED]
(B[mailto:[EMAIL PROTECTED]]
(BSent: Thursday, January 16, 2003 12:01 AM
(BTo: [EMA
> So instead of using an "explicit" session id to represent the session, I
> like better the idea that the "session" can be derived from the message
> itself. In the previous example David gave, that means I look for the
> "bank account number" from the message to identify a session, regardless
Hi Steve,
(B
(B> -Original Message-
(B> From: Steve Loughran [mailto:[EMAIL PROTECTED]]
(B> Sent: Thursday, January 16, 2003 8:12 AM
(B> To: [EMAIL PROTECTED]
(B> Subject: Re: Stateful Web Services
(B :
(B> The weakness of cookies is they are transport
- Original Message -
From: "Ricky Ho" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, January 15, 2003 16:35
Subject: Re: Stateful Web Services
> I think reinventing the idea of cookies at the SOAP header will solve the
&
Rgds, Ricky
At 03:12 PM 1/15/2003 -0800, Steve Loughran wrote:
- Original Message -
From: "Ricky Ho" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, January 15, 2003 14:13
Subject: RE: Stateful Web Services
> Most
You need to tell the client to "store all cookies you receive, and resend
it in your next request".
Also, there is nothing in the WSDL telling the client that the state is
maintained in the server side. The fact that "session scope" is configured
is purely an implementation detail. Therefore,
- Original Message -
From: "Ricky Ho" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, January 15, 2003 14:13
Subject: RE: Stateful Web Services
> Most Java-based SOAP engine (over HTTP) implementation leverages the
>
on [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
8 PM
To: [EMAIL PROTECTED]
Subject: Re: Stateful Web Services
Hi Steve,
But in the simplest possible case, where I just want to persist data
between *invocations* (i.e. separate calls), do I still need session
info to be propogated client side?
e.g.
Call 1: deposit(100);
Call 2: depos
D]>
(B>To: <[EMAIL PROTECTED]>
(B>Sent: Wednesday, January 15, 2003 12:02
(B>Subject: Re: Stateful Web Services
(B>
(B>
(B>
(B>
(B>>Thanks Barry,
(B>>
(B>>This was the kind of "statefulness" and "persistence" that I am
(B- Original Message -
(BFrom: "David Peterson" <[EMAIL PROTECTED]>
(BTo: <[EMAIL PROTECTED]>
(BSent: Wednesday, January 15, 2003 12:48
(BSubject: Re: Stateful Web Services
(B
(B
(B>
(B> Hi Steve,
(B>
(B> But in the simplest possible case, whe
ED]]
Sent: Wednesday, January 15, 2003 3:48 PM
To: [EMAIL PROTECTED]
Subject: Re: Stateful Web Services
Hi Steve,
But in the simplest possible case, where I just want to persist data
between *invocations* (i.e. separate calls), do I still need session
info to be propogated client side?
e.g.
Call
Peterson" <[EMAIL PROTECTED]>
(B>To: <[EMAIL PROTECTED]>
(B>Sent: Wednesday, January 15, 2003 12:02
(B>Subject: Re: Stateful Web Services
(B>
(B>
(B>
(B>
(B>>Thanks Barry,
(B>>
(B>>This was the kind of "statefulness" and &q
(B- Original Message -
(BFrom: "David Peterson" <[EMAIL PROTECTED]>
(BTo: <[EMAIL PROTECTED]>
(BSent: Wednesday, January 15, 2003 12:02
(BSubject: Re: Stateful Web Services
(B
(B
(B>
(B>
(B> Thanks Barry,
(B>
(B> This was the kind of "
(B
(BThanks Barry,
(B
(BThis was the kind of "statefulness" and "persistence" that I am
(Binterested in (though I was also interested to hear what was said re
(BSOAP and sessions by Anne et al., as this was another question I had).
(B
(BCan you tell me, why does the client need to set "mai
-
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
---
(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 be
hat 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> Subj
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 standar
Title: 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
L 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 cr
ev.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, whic
len Daniels" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 01, 2002 8:33 PM
Subject: RE: stateful web services (a minor complaint)
>
> Hola, Stan!
>
> Comments inline:
>
> > The good news is that it's very easy to develop stateful web servi
Hola, Stan!
Comments inline:
> The good news is that it's very easy to develop stateful web services
> (hooray!). But...
> 1. If you write your client 'by hand' you must include this
> statement in
> Client.java:
> call.setMaintainSession(true);
>
The good news is that it's very easy to develop stateful web services
(hooray!). But...
1. If you write your client 'by hand' you must include this statement in
Client.java:
call.setMaintainSession(true);
2. If you generate a wsdl file and stubs, you must edit one
39 matches
Mail list logo
