I'm writing to ask what might be the best approach for integrating my system with an external system within my organization that is 100% .NET-based (e.g. No Java allowed).
My system consists of a networked pair of Fuse MQ Enterprise active/passive clusters, along with a cluster of Fuse ESB Enterprise instances.
External Interface Design History
I recently advocated for using the Apache NMS API (.NET interface) with the ActiveMQ NMS assembly (.NET implementation). The external .NET team expressed concern about the resulting dependency on ActiveMQ, and asked whether AMQP might be a better option.
I've learned that AMQP 1.0 spec was released only a few weeks ago. I could not find a precise date for the STOMP 1.1 specification. But, it looks like it's been available since about 3/2011.
1. Would using the Apache NMS API with the STOMP NMS .NET library/assembly remove the dependency on ActiveMQ?
2. How might a NMS API .NET client differ from a AMQP client?
3. According to the ActiveMQ FAQ, STOMP is slower. In what other ways might the STOMP NMS .NET library/assembly differ from the ActiveMQ NMS library/assembly?
4. Does the Apache STOMP NMS implementation support immediate failover?
5. How does the STOMP transport on Fuse MQ Enterprise product compare to corresponding OpenWire transport in terms of reliability and failover features?
6. When might AMQP 1.0 protocol support in ActiveMQ be available? And, how soon after that release would it be suitable for a mission critical use?
7. What else might help to persuade the .NET team to choose STOMP or OpenWire over AMQP?
8. Would it be feasible for the .NET team use AMQP to connect to Qpid, or MRG as a stop-gap measure, until ActiveMQ has AMQP 1.0 support?
9. What issues might I face using Qpid or MRG with a bridge to my Fuse MQ Enterprise cluster.
Specs and Implementations
Edited by: roboticon on Nov 4, 2012 11:24 AM