We are at an architecture crossroad.
The previous system used used share DB for communicating between each other, but we want to get rid of the cfschedule polling latency. All the sub-system are written in CF.
I'm researching on MOM, mostly likely a JMS broker since CF comes with an event gateway for it, or basic remote method calls. Side question: would using *.cfc?method= through http be faster then invoking them as SOAP web services?
We would also like to be able to log failed attempts, query actual status, and maybe auto retry after a period of time. Does MOM/JMS fit our bill? Our shall we implement our own queue?
Also, we will be using CF standard, so in the event gateway is limited to 1 thread, and 2 custom threads concurrently.
Any advice or suggestion would be appreciated, thank you!
Given that you're asking about replacing shared DB with either ActiveMQ or remote method call, I'm assuming your use case is really message passing versus application shared state; shared DB is obviously a good way to do shared state between multiple applications. Your description also makes me think that your application is sending a notification or event to other applications because something interesting has happened...
Remote method calls work when your calling a single application, you need immediate response, and you know the other application will be available (i.e. running). Many systems find this approach challenging if the receiving application may not be running when the message needs to be sent. Remote methods calls are also challenging if you currently, or in the future, need to send to multiple applications, especially if future receivers are unknown to the sending application.
MOM, and ActiveMQ specifically, is a great approach to reliable and asynchronously sending messages to one or more receivers. The sending application gives ActiveMQ the message and then continues on doing its work (doesn't block your application for doing more work). The message receiver(s) will receive the message when they are connected to ActiveMQ - that is, if they are connected when the message is sent its effectively as fast as remote method; if the receiver connects at a later time, they will receive when they connect (no polling). ActiveMQ ensures the message is safe till the receiver acknowledges receipt.
If you are sending events, using a messaging system like ActiveMQ is really good in that you can use a paradigm called publish / subscribe where messages (events) can be delivered to multiple receivers. These receivers are unknown to the sending application; they just need to know how to connect to ActiveMQ. This paradigm is a great way to de-couple your applications; your application sends interesting events, and other applications that could benefit from knowing that event happened can connect to ActiveMQ in the future...
A great resource for many integration patterns, including publish / subscribe, is Gregor Hohpe's Enterprise Integration Patterns site. More information on ActiveMQ can be found at the Apache ActiveMQ or at FuseSource's ActiveMQ site
Hope that helps,
Scott