Hi Rinsad, I think what I'm looking for (as Samisa is too) is for a clear "picture" of what the responsibilites are for ws-addressing between the handler and the engine. My preference is to not have any ws-addressing specifics in the engine at all if possible. I understood this was the original goal and you seem to think (judging from your previous notes) that this may be possible? If you could find a way of listing this out then that would really help, (perhaps a sequence diagram might help here?) thanks, John. John Hawkins "Rinsad Ahmed" <[EMAIL PROTECTED]> wrote on 07/01/2005 09:01:51: > 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,constAxisChar > * > > > > > 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 bythe 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 sessionrelate 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" deleted by John Hawkins/UK/IBM]
