Thanks Carsten, I have almost finished the stuffs like Endpoint references and Message Identity parts. Now I think, it is the time to look into this complicated part. Q: Rinsad,is your concern that the stub/skeletons don't support communication to handlers or is it something different? A: It is different. What I mean is, WSA-Handler uses the class ReferenceProperties to store the session properties. It sets it as a complex property into IMessageData. But how it is going to be accessed by the stub/skeletons. For that both WSA-Handler and stub/skeleton should use the same interface to store these properties. It is my concern
Rinsad On Thu, 6 Jan 2005 10:03:47 -0800, Carsten Blecken wrote > 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:[EMAIL PROTECTED] > 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" <[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)
