Talking through some current issues with ColdFusion Event Gateways
ColdFusion, Technology, Java
Normally on my blog I attempt to throw out some tip, trick, or nugget of some sort. This time? Not so! I am currently trying to find a solution to a problem at hand and am brainstorming the best way to handle a few things. I am really just talking this out for my own benefit, but I would love to hear thoughts from others that have perhaps solved similar issues.
On a project that I am currently engaged in I am leveraging ColdFusion Event Gateways which work as a subscriber to a SonicMQ JMS server. My gateway instance listens for messages on the ESB (Enterprise Service Bus) on a particular destination name (topic/queue). When it receives a message, it parses the XML that it received, and plays traffic cop pushing data into various services that need it. I have this working flawlessly in my small development environment. However, I have a couple of complexities ahead of me that I am having difficulty coming up with a good solution.
On a project that I am currently engaged in I am leveraging ColdFusion Event Gateways which work as a subscriber to a SonicMQ JMS server. My gateway instance listens for messages on the ESB (Enterprise Service Bus) on a particular destination name (topic/queue). When it receives a message, it parses the XML that it received, and plays traffic cop pushing data into various services that need it. I have this working flawlessly in my small development environment. However, I have a couple of complexities ahead of me that I am having difficulty coming up with a good solution.
- Running in the cloud - Our production environment will have any number of CF instances, not clustered, but rather running as isolated applications with a load balancer directing the requests using sticky sessions. Our system will be bringing new instances on/off line as traffic traffic dictates. I have yet to solve the issue of how to set up my JMS Event Gateway in this environment. I definitely don't want 20 different listeners out there all doing the same work. I have considered the idea of having some sort of a support database where a listener can insert a row with a specific JMS message ID and when any other server picks up a message with that ID it will see that it is already being acted upon and it can safely ignore it. There are a couple of negatives that I can see right off the bat. First is that every single subscribed instance will have to pull in the same message and test to see whether or not it should be acted upon. It just seems like a little bit of redundancy that shouldn't be there. Secondly, there is a chance that two servers could pick up the same request within milliseconds of each other and both could end up doing the work. Duplicate processing could not only be wasteful, but could also create some data integrity issues.
- Different environments have different settings (dynamic config) - Right now in our development phase, we have a single config file with setting specific to our development JMS server (credentials, domain, URL, Initial Context Factory, etc). However, soon I will need to have this process support a number of different environments: multiple dev environments, multiple integration environments, multiple QA environments, and eventually production. Ideally it would be wonderful if I could find some way to load a specific config into the event gateway at server init time, but as of today I have _NO_ idea how to solve this one. First, there is no real intrinsic indicator at the server level that lets it know what environment is currently running (yet anyway...) and secondly, ColdFusion event gateway architecture isn't conducive in any way to dynamically loading a specific config.
No comments for this entry.
|| 
Add Comment
Add Comment
Loading....