There is this new implementation of Reliable Messaging from WSO2 called Mercury. You can download it from here. There is discussion going on as to whether Mercury should be sequal to Sandesha2 as Sandesha3 or not. Ppl who argue against it has basically following points
1. When adding features to current Mercury it will ultimately become as complex and as ugly as Sandesha2. In other words they have concerns whether Mercury solve existing Sandesha2 problems.
2. Sandesha2 is tested for performance and results are satisfactory and have doubt about Mercury performance.
3. Sandesha2 is feature rich.
4. Mercury still only provides only a very basic feature set and therefore they can’t adopt it at this stage.(RM 1.1 spec is not supported)
What those ppl accept in general is that
Sandeha2 is complex and need lot of improvement and that improving is not easy.
Ppl who argue in favour in Mercury have following points
1. Mercury architecture is based on a state model which is clean.
2. It would not be susceptible for race conditions and dead locks(I heard some ppl worry about that in Sandesha2)
3. Mercury is open for improvements and they beleive that it could be done in a cleanly fasion.
I am these days considering implementing Mercury/C for Axis2/C web services platform. When I had an initial look at the architecture diagrams and Mercury/Java code I understand that it is actually very clean and easy to adopt for writing Mercury/C, although I am not satisfied with the quality of the architecture documents that shipped with the Mercury release. It seems that nobody has reviewed it. For example it mention CSR but nowhere it has defined what is CSR(Of course Create Sequence Response). I must thank Amila Suriarachchi for coming up with this innovative design. I will continue to analyse Mercury architecture and most probably will implement Mercury/C which I beleive could be completed in about 3 months time once started.
