axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa.abeysin...@gmail.com>
Subject Re: Session Management with WS-Addressing
Date Fri, 07 Jan 2005 04:14:25 GMT
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 <rinsad@opensource.lk> 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:HAWKINSJ@uk.ibm.com]
> > 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" <rinsad@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" <rinsad@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)
> 
>

Mime
View raw message