axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rinsad Ahmed" <rin...@opensource.lk>
Subject Re: Session Management with WS-Addressing
Date Thu, 06 Jan 2005 11:59:59 GMT
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 and the server use two different transport protocols, then the current 
implementation will fail to maintain session.

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?
> 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?
> 
> > 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?
> 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 ?
> 11) What if the client never closes?
> 
> >
> > Please comment on this requirement. Ask for any clarification
> >
> > Regards
> > Rinsad
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >


--
Lanka Software Foundation (http://www.opensource.lk)


Mime
View raw message