axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Blecken" <cblec...@macrovision.com>
Subject RE: Session Management with WS-Addressing
Date Thu, 06 Jan 2005 18:03:47 GMT
Some comments (all over the map):

1) In general it would be great to support WS-A since
   it would allow to move beyond simple request-response
   scenarios.
2) The idea is that WS-A can get a message from point A to
   to B to C (multiple hops)without worrying about the transport,
   so that between A and B we can have a HTTPS connection and
   between B and C a HTTP connection.
3) I thought the Call::setHandlerProperty could be used to
   communicate to the handler on client side and you can get
   the IMessageData from the Wrapper on the Server side. Rinsad,
   is your concern that the stub/skeletons don't support communication
   to handlers or is it something different?
4) The session management aspect of WS-A is clearly the most complicated
   part. It might be possible to initially concentrate on the 
   Endpoint references and Message Identity parts of WS-A and leave
   the session management for later. 

Carsten

-----Original Message-----
From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
Sent: Thursday, January 06, 2005 4:48 AM
To: Apache AXIS C User List
Subject: Re: Session Management with WS-Addressing






Hi,

more questions:-(

Any chance you could create some pictures to help my poor brain understand
the interactions and changes that need to be done ?
(fyi: My questions are dotted all the way througth the paper trail.)


Thanks for helping me understand.

John Hawkins



"Rinsad Ahmed" <rinsad@opensource.lk> wrote on 06/01/2005 11:59:59:

> Thanx for the concern John,
> 1) ReferenceProperties is simply a class containing a map<char*,char*>
> attribute and addProperty(char*,char*) and getProperty(char*) methods.
>
> 2)The WS-Addressing handler creates an instance of the
ReferenceProperties
> from the soap headers and add it to the IMessageData, as a complex
property
> (eg:- pIMsg->setComplexProperty(char*,ReferenceProperties) from the
incoming
> soap message. And also, it gets the property from the outgoing
IMessageData
> and construct the outgoing soap headers.
>
> class ReferenceProperties
> {
> private:
>         map <AxisChar*,AxisChar*,ltstr> m_refProps;
> public:
>
>    ReferenceProperties();
>        const AxisChar* getProperty (AxisChar* pachName);
>        void addProperty(const AxisChar * pachLocalName,const AxisChar *
> pachValue);
> };
>
>3)WS-Addressing, focus on maintaining sessions in a protocol neutral
> manner. I hope, the current session management is specific for http.
> If we say the client uses one transport protocol when requesting a
service.
>  But the response is sent by the server (replyTo) to another server where

>they use a different protocol. then the current implementation will fail
to
>maintain session.
>eg:
>Say A is a client, B,C are 2 endpoints. A and B use http. But B and C use
>smtp.>

So, this breaks ssl as well? If true - is this known - how do people get
around this?

> 4)Yep. I mean state is session. Server engine is only going to pool the
> ReferenceProperties. It should pool it for a specific time.If there is no

> further access with in that time that object is discarded. Even though
the
> client didn't close, after that specific time, the information with the
> client are invalid.
>
> 5)The informations inside the ReferenceProperties are set by the user.
But
> the engine should set some attributes such as an ID to distinguish
messages
> uniquely and a timestamp.
>
> If any thing unclear or wrong please comment
>
> On Thu, 6 Jan 2005 10:28:00 +0000, John Hawkins wrote
> > Hi Rinsad,
> >
> > I've put quite a few comments below to help me understand the
conversation
> > - if you could be so kind :-)
> >
> > Overall - I'm concerned that ws-addressing is now becoming invasive
> > to the engine - this was not what we first discussed. WS-Addressing
> > was a handler and as such such I (perhaps naively) thought it could
> > be contained within a handler. My main concern here is that if a
> > user does not want ws-addressing then the engine is going to slow
> > down and become more complex to support it.
> >
> > Perhaps if you could answer my clarification questons below we'll be
> > in a better position to understand the issues on the mailing list.
> >
> > many thanks,
> > John.
> > John Hawkins
> >
> > "Rinsad Ahmed" <rinsad@opensource.lk> wrote on 06/01/2005 08:33:00:
> >
> > > It is time talk about session management with ws-addressing.
> > >
> > > WS-Addressing supports session management (or stateful communication)
in
> > a
> > > protocol neutral manner.For that, it uses an xml element named
> > > Referenceproperties, which consists all the session specific
parameters
> > as
> > > sub elements, which in turn a sub element of a soap header element,
> > > abstractly named as EndpointReference.
> > > Note:- The header elements From, ReplyTo, FaultTo are instances of
> > > EndpointReference.
> > >
> > > In my handler, I use a complex object which is an instance of class
> > > ReferenceProperties to store these parameters and store it in the
> > > IMessageData which is accessible by the Web Service or Web Client.
> > >
> > > But at the moment the client and server engines have no support
either to
> > set
> > > it to the outgoing message or get it from the incoming message.
> >
> > 1). Sorry - set what in what ? Set the ReferenceProperties with an
outgoing
> > message?

Please can you answer this question.

> > 2) What's in the reference properties class?
> >
> > >
> > > Here I am suggesting a way for the session management over
ws-addressing.
> > >
> > > First, the server and client engine should provide an API similar to
> > > ReferenceProperties class which I used. Or we may come agree on a
common
> > > interface.
> >
> > 3). Need info as above on what's in that class please.
> >
> > >
> > > Second, the server engine should maintain a pool of
ReferenceProperties
> > which
> >
> > 4) Do you mean both client and server engine? It seems to me that to
> > have the below function you mean both?

Please can you answer this question.

Also - why should the server maintain these - can the ws-addressing handler
maintain them?


> >
> > > are keyed by sessionId. Each object should have a timestamp. After a
> > certain
> >
> > 5) What's a session in this context? How does this session relate to
> > HTTPSession that Samisa recently implemented?
> > 6) Where does this timout come from - is this specced in ws-addressing?
> > 7) Who sets it - the user?


Please can you answer this quesion.


> > 8) How does this relate the HTTP timeouts?
> >
> > > time elapsed the object should be removed from the pool(session
timeout
> > > period). If the client accessed the service with in the timeout
period
> > the
> > > timestamp should be updated. If the object has already removed, a new
> > session
> > > should be initiated.
> > >
> > > Third, even after the connection is broken, the state information
should
> > be
> > > available in the client memory which is required to be used later,
till
> > the
> > > client itself is closed.
> >
> > 9) By "state" do you mean the "session" information?
> 10) Why is the "state" required to be used later ?

Please can you answer this question. Is it because a new connection can be
made which continues the previous session and you never know when that
session can be removed?

> > 11) What if the client never closes?

Please can you answer this question

> >
> > >
> > > Please comment on this requirement. Ask for any clarification
> > >
> > > Regards
> > > Rinsad
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
>
>
> --
> Lanka Software Foundation (http://www.opensource.lk)
>


Mime
View raw message