Thanks David! Definitely +1 for fixing this in Sandesha ..
Sanjiva.
Brian De Pradine wrote:
Hi Sanjiva,
If this problem can be fixed in the Sandesha layer that will be better
than the current fix. I will revert the changes.
Cheers
Brian DePradine
Web Services Development
IBM Hursley
External +44 (0) 1962 816319 Internal 246319
If you can't find the time to do it right the first time, where will you
find the time to do it again?
Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote on 05/03/2007 02:59:15:
> Brian De Pradine wrote:
> >
> > In this scenario the server sends a response message to the client.
The
> > client then tries to send an acknowledgement to the server, but the
> > acknowledgement gets lost, for whatever reason. This means that the
> > WS-RM layer, in the server, will eventually time-out and send the
> > response message again. This time the client should send an
> > acknowledgement to cover both the original and the duplicate response
> > messages.
> >
> > This scenario is broken because the duplicate response never makes
it to
> > the WS-RM layer on the client side, because the
> > AddressingBasedDispatcher recognises it as a duplicate and throws an
> > exception instead. This means that the WS-RM layer never gets
driven to
> > send the second acknowledgement. The result is that the server will
> > simply keep sending duplicate responses forever (almost)!
> >
> > In order to get this scenario to work the AddressingBasedDispatcher
will
> > need to dispatch any duplicate messages as normal, instead of deciding
> > that they are 'bad' and throwing an exception. This will allow
WS-RM to
> > be easily added into the picture at any time. This also means that if
> > there is no WS-RM engaged then a service will potentially be driven
more
> > than once if there are duplicate messages (created by some other
means).
> > This shouldn't be a problem, however, because web services are
meant to
> > be stateless entities anyway :-) If you do happen to have a web
service
> > that is not stateless then you will need to engage WS-RM to ensure
that
> > it is not driven by duplicates.
>
> OK I understand the scenario but I'm -1 on this because it breaks normal
> users. You can't say that Web services are stateless and therefore
its ok
> to just let messages get delivered repeatedly violating our MEP concept!
>
> RM is a lower level thing than MEPS- its infrastructural. The MEP should
> not be marked complete if the message hasn't been received to the
> satisfaction of the lower level.
>
> If what Chamikara suggests will fix this for RM that's great but no
matter
> what this change is not acceptable because its breaking the
definition of
> a MEP. Think of a TCP analogy: TCP users a protocol similar to RM to
> resend packets. Anyone who implements something like HTTP over TCP
doesn't
> need to be concerned with the response being delivered twice!!
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
------------------------------------------------------------------------
/
/
/Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
