Hi, thanks for clarifying this.
Thanks Lars 2012/2/27 Ruwan Linton <[email protected]>: > 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
