You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by Rinsad Ahmed <ri...@opensource.lk> on 2005/01/06 09:33:00 UTC
Session Management with WS-Addressing
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.
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.
Second, the server engine should maintain a pool of ReferenceProperties which
are keyed by sessionId. Each object should have a timestamp. After a certain
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.
Please comment on this requirement. Ask for any clarification
Regards
Rinsad
Re: Session Management with WS-Addressing
Posted by Rinsad Ahmed <ri...@opensource.lk>.
1)So, this breaks ssl as well? If true - is this known - how do people get
around this?
No. The ws-security will extend ws-addressing in future. I am not very clear
on this issue.
2)Also - why should the server maintain these - can the ws-addressing handler
maintain them?
It seems to be a good solution. We should analyse the pros and cons of this
solution. However,we need an interface, through which the client and server
able to get and set ReferenceProperties.
3)What if the client never closes?
Server engine pools session specific information 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. So when the client make a connection after timeout
period, it will initiate a new session.
4) Is it because a new connection can be made which continues the previous
session and you never know when that session can be removed?
No.
Think of a web browser and an application server. Web browser retains session
information till it is not closed. But the server timeouts. When the client
try to connect to the server after timeout period, a new session will be
initiated. A similar mechanism is required.
On Thu, 6 Jan 2005 12:48:11 +0000, John Hawkins wrote
> 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" <ri...@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" <ri...@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)
> >
--
Lanka Software Foundation (http://www.opensource.lk)
Re: Session Management with WS-Addressing
Posted by Rinsad Ahmed <ri...@opensource.lk>.
Sorry
error
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.
corrected
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.
> 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
>
Re: Session Management with WS-Addressing
Posted by John Hawkins <HA...@uk.ibm.com>.
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" <ri...@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" <ri...@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)
>
Re: Session Management with WS-Addressing
Posted by Rinsad Ahmed <ri...@opensource.lk>.
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" <ri...@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)
Re: Session Management with WS-Addressing
Posted by John Hawkins <HA...@uk.ibm.com>.
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" <ri...@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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>