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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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)
