axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <HAWKI...@uk.ibm.com>
Subject Re: Session Management with WS-Addressing
Date Thu, 06 Jan 2005 12:48:11 GMT




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