axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <HAWKI...@uk.ibm.com>
Subject Re: Session Management with WS-Addressing
Date Fri, 07 Jan 2005 09:23:16 GMT




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" <rinsad@opensource.lk> 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
> > <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,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" <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
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]


Mime
View raw message