Hi Folks, I am very poor with images. However, I have attached a diagram. I think, it may give you some idea regarding my requirements
Rinsad On Fri, 7 Jan 2005 04:14:25 +0000, Samisa Abeysinghe wrote > Sorry Folks, but I am a bit lost. I think John is trying to > understansd how much changes are required to the core client and > server engines when it comes to supporting WSA; I too am trying the > same. > > It could be easier if Rinsad could list out (summarize) what changes > are requiresd to the engine and why. > I think we have to clearly list out what the handler should be doing > and what the engine should be doing - making sure that we do not > build WSA specific stuff into the engine. A diagram would do help a great > deal here. > > Thanks, > Samisa... > > On Fri, 7 Jan 2005 09:25:49 +0600, Rinsad Ahmed > <[EMAIL PROTECTED]> wrote: > > 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) > > > > -- Lanka Software Foundation (http://www.opensource.lk) ------- End of Forwarded Message ------- -- Lanka Software Foundation (http://www.opensource.lk)
<<attachment: wsa.gif>>
