On Mon, Feb 27, 2012 at 5:35 PM, Lars-Erik Helander <[email protected]>wrote:
> Hi and thanks again :) > :-) > > >I think WS-RM should take care of it, if the sequence acknowledgement is > >not acked within the timeout from the client (in this case synapse), it > >should (I mean the back-end server should) re-send the sequence > >acknowledgement after the timeout per the spec, IIRC. (I am not quite sure > >about the behaviour and it depends on the implementation that you are > using) > > I was not aware that the back-end server would be able to detect a > flaw in the ACK path, but it sounds reasonable that it could do that. > I need to learn more details about the WS-RM ;) > Well, I refreshed my memory by reading through the protocol element on sequence termination response of the spec, and looks like there is no ACK for that from the source to the destination. I was thinking that AckRequested is an option when sending a TerminateSequenceResponse, looks like it is not :-) So yes, some mechanism needs to be implemented in the synapse with persistence to guarantee terminate sequence response not getting lost in the Synapse layer, except for that I think the rest should generally work. Thanks, Ruwan > > Thanks > > Lars > > 2012/2/27 Ruwan Linton <[email protected]>: > > Hi Lars, > > > > On Mon, Feb 27, 2012 at 3:55 PM, Lars-Erik Helander <[email protected] > >wrote: > > > >> Hi Ruwan > >> > >> Thank you very much for the answer. It provided exactly the type of > >> information I was looking for. > >> > > > > Thanks, and you're welcome. > > > > > >> > >> Regarding: > >> >There is a case where this could fail too, if Synapse fails or crashes > >> > after receiving the signals like ACK etc from the back-end server, > before > >> > sending the same back to the client, in this case the resend should be > >> > discarded from the server and completes the transaction. > >> > >> I guess that synapse (when it has recovered) is not aware of the > >> history, but will be able to pick up according to the resends > >> initiated by the client, correct ? > >> > > > > Yes. > > > > > >> > >> The back-end server needs to be able to reproduce any previously sent > >> ACKs, either by being idempotent or in some other way deal with this > >> "internally". > >> > > > > I think WS-RM should take care of it, if the sequence acknowledgement is > > not acked within the timeout from the client (in this case synapse), it > > should (I mean the back-end server should) re-send the sequence > > acknowledgement after the timeout per the spec, IIRC. (I am not quite > sure > > about the behaviour and it depends on the implementation that you are > using) > > > > > >> I also guess that you might be able to manage the necessary persitency > >> for these ACKs by having a persistent queue in the flow between the > >> back-end server and synapse, but that would require some explicit > >> logic for this in the synapse in/out-sequences. > >> > > > > Yes, and that logic might get complicated when you want to handle all > > possible cases. One of the design principals for Synapse core is that we > > treated it as a dumb proxy which does what user instructs via its > > configuration and only that. So this sort of a logic needs to be custom > > developed, and that require a little bit depth of Synapse/Axis2 as well > as > > RM. > > > > Thanks, > > Ruwan > > > > > >> > >> > >> Thanks > >> > >> Lars > >> 2012/2/27 Ruwan Linton <[email protected]>: > >> > Hi Lars, > >> > > >> > First of all sorry for the late reply. > >> > > >> > On Sun, Feb 19, 2012 at 7:35 PM, Lars-Erik Helander <[email protected] > >> >wrote: > >> > > >> >> Hi, > >> >> I have a client and service that both are RM enabled. I want to put > >> >> Synapse in between the two to perform some transformation of the > message > >> >> data, but wants to keep the RM characteristics of the exchange. > >> >> > >> >> Is this possible? > >> >> > >> > > >> > Yes. > >> > > >> > > >> >> Do I have to explicitly enable RM on the Proxy Service and Endpoint > in > >> >> Synapse, or do Synapse by default pass on the RM related info between > >> the > >> >> client and the service? > >> >> > >> > > >> > You have to explicitly set RM at both ends, i.e. on the proxy service > as > >> > well as on the endpoint. Default behaviour of Synapse is to assume > that > >> the > >> > RM is terminated at the receiving side, unless otherwise specified for > >> the > >> > out going endpoint too. > >> > > >> > > >> >> > >> >> If I enable RM on the proxy and endpoint (which I guess will create > two > >> >> different RM associations: client <-> synapse and synapse <-> > service) > >> > > >> > > >> > You're correct. > >> > > >> > > >> >> is there a risk that the RM characteristics are violated compared to > the > >> >> RM characteristics of a direct association between the client and > >> service? > >> >> > >> > > >> > As far as the complete transaction is concerned, it will not, as > Synapse > >> > deals with the RM sequences etc and adheres to the specification on > >> > sequence messages and transaction initiation and termination as a > proxy. > >> > However as you have figured out, the actual message transmission > happens > >> in > >> > 2 transactions. > >> > > >> > The reliability is guaranteed as the sequence acknowledgement etc are > >> sent > >> > back to client only after getting the same from the back-end server > etc > >> and > >> > if synapse failed to deliver the ACK within the timeout (could be due > to > >> > failure in sending the request, or back-end server not being able to > send > >> > back the ACK on-time) it is the responsibility of the client to resend > >> and > >> > so forth. > >> > > >> > So from the clients perspective it is giving an end-2-end reliability. > >> > There is a case where this could fail too, if Synapse fails or crashes > >> > after receiving the signals like ACK etc from the back-end server, > before > >> > sending the same back to the client, in this case the resend should be > >> > discarded from the server and completes the transaction. > >> > > >> > Thanks, > >> > Ruwan > >> > > >> > > >> >> > >> >> Kind Regards > >> >> Lars > >> > > >> > > >> > > >> > > >> > -- > >> > Ruwan Linton > >> > Member, Apache Software Foundation; http://www.apache.org > >> > Director of Engineering; http://adroitlogic.org > >> > > >> > phone: +94 11 282 7532 > >> > email: [email protected]; cell: +94 77 341 3097 > >> > blog: http://blog.ruwan.org > >> > linkedin: http://www.linkedin.com/in/ruwanlinton > >> > google: http://www.google.com/profiles/ruwan.linton > >> > tweet: http://twitter.com/ruwanlinton > >> > > > > > > > > -- > > Ruwan Linton > > Member, Apache Software Foundation; http://www.apache.org > > Director of Engineering; http://adroitlogic.org > > > > phone: +94 11 282 7532 > > email: [email protected]; cell: +94 77 341 3097 > > blog: http://blog.ruwan.org > > linkedin: http://www.linkedin.com/in/ruwanlinton > > google: http://www.google.com/profiles/ruwan.linton > > tweet: http://twitter.com/ruwanlinton > -- Ruwan Linton Member, Apache Software Foundation; http://www.apache.org Director of Engineering; http://adroitlogic.org phone: +94 11 282 7532 email: [email protected]; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
