One of the most powerful new features available in ColdFusion MX 7 Enterprise that many ColdFusion developers might not yet be using is event gateways. Event gateways open up entirely new possibilities for ColdFusion and allow our ColdFusion applications to communicate with more or less any other Internet-enabled system even if the system doesn't communicate via the "traditional" HTTP protocol.

CFMX 7 Enterprise ships with a few gateways to get you started, such as an SMS gateway for communicating with mobile devices, a directory watcher gateway, a socket gateway, a Java Message Service (JMS) gateway, and Jabber/XMMP as well as Lotus Sametime IM gateways, so you have a lot of possibilities right out of the box.

If you don't need the specific functionality offered by these gateways you might not have investigated them thoroughly and because the event gateways themselves are written in Java, creating new gateways may not be a high-priority item for many ColdFusion developers. But there is another gateway that ships with CFMX 7 Enterprise that ColdFusion developers can take advantage of right away, which offers numerous benefits in your ColdFusion applications. In this article I'd like to introduce you to the Asynchronous CFML Gateway, describe some of the great potential uses of the gateway, and show how I added an asynchronous CFML gateway to vastly improve the performance and functionality in an existing ColdFusion application.

The Asynchronous CFML Gateway
The purpose of the asynchronous CFML gateway is to allow developers to offload long-running processes to the gateway. The gateway immediately passes control back to the application and does it's processing behind the scenes. This means that your users will no longer have to wait for lengthy batch processes to complete before doing other things within the application. This is great for things like logging, which if you log a lot of data can really bog down your application since the user has to wait for the logging process to complete on each request.

Even if you have a process that runs behind the scenes that is initiated by the ColdFusion scheduler as opposed to by a user action, leveraging the asynchronous gateway can allow for the process to complete more quickly. For example, if you have a loop of some sort and the work done upon each iteration is fairly lengthy, by sending a message to the asynchronous gateway on each loop iteration the overall process doesn't need to wait for each iteration to complete before proceeding.

What allows this magic to be possible is the use of ColdFusion Components (CFCs) that operate within the event gateway environment as opposed to being tied to a specific request. By creating a CFC that contains a few specific methods (actually we'll concern ourselves with one method in particular - more on this in a moment) and registering the CFC as an event gateway instance in the ColdFusion administrator, the CFC can now operate independently of the traditional request/response model of web applications.

Bear in mind, however, that not all processes are suitable for use with the asynchronous event gateway. One big caveat here is that because the asynchronous process is detached from the request/response cycle, it isn't really feasible to provide feedback to the user in a traditional way such as sending the user to a confirmation page when a process completes. Also, if your application contains processes that occur sequentially and later processes rely on the results of preceding processes, then even if one of these processes is time-consuming this isn't a case in which use of the asynchronous gateway is possible. When you use the asynchronous gateway you essentially throw the process over the fence and give up control over when it completes and the ability to rely on the results of the asynchronous process.

The asynchronous CFC can however, do things such as log information to a file or database, send information via e-mail, or even send an instant message using the IM gateway, so by no means does the asynchronous CFC's processing disappear into a black hole.

In addition to these methods the event gateways can of course also use the cflog tag, which outputs information to a log that can be viewed from the ColdFusion administrator or directly in the log file itself. In the ColdFusion administrator's Debugging & Logging section you will also see an Event Gateway log that can provide information about what occurs inside your gateways. Finally, for some additional thoughts and methods by which to get feedback from asynchronous CFCs, please see Sean Corfield's blog entries about his Concurrency library under "Resources" at the end of this article.

If you haven't considered the power of asynchronous processing before, I'd be willing to bet the wheels are spinning and your head is filling with ideas of how you can leverage this power in your applications. Let's take a look at one real-world example that created dramatic improvements and was surprisingly easy to build.

Web-Based "E-Mail Blaster"
A few years ago I wrote a ColdFusion application for my company's marketing department that is used for generating and sending e-mail marketing campaigns. This application became affectionately known as the "E-Mail Blaster." Prior to the existence of the E-Mail Blaster our marketing team was literally cutting and pasting e-mail addresses from an Excel spreadsheet into the Lotus Notes e-mail client. Clearly not the most efficient way to do things given the fact that some of our larger batches of e-mail can top 50,000 recipients, and Notes has an upper limit of a few hundred recipients for each e-mail. (Before you declare me the Spam King of Texas, bear in mind that that our lists are entirely opt-in!)

When I saw how the marketing department was dealing with these e-mail campaigns I immediately knew that this was a perfect job for ColdFusion. ColdFusion Enterprise handles large volumes of e-mail extremely well, and it was quite simple to build a web-based interface for creating e-mail campaigns that saves countless hours of time versus the old cut-and-paste method. We use another tool to maintain contact lists, so the marketing team extracts the recipient list into an Excel spreadsheet. They then use the ColdFusion application to upload the Excel spreadsheet containing the recipients' e-mail addresses along with an HTML file containing the contents of the e-mail, and the E-mail Blaster handles the rest.

Hurry Up and Wait
The application was an immediate hit with the marketing department, but there was one drawback. Even as quickly as ColdFusion handles e-mail it still takes a bit of time to process 50,000 e-mails, and in the traditional request/response model of web applications this means the user of the application has to wait ... and wait ... and wait for the process to complete. This doesn't necessarily mean the user can't go do something else while it's processing, but people tend to get used to submitting a form and seeing a response relatively quickly so by force of habit the users of the E-mail Blaster tend to wait for a response from the application.

In a long-running process such as this the response can be substantially delayed, and this can cause problems ranging from simple annoyance to users resubmitting e-mail batches because they assume the process stopped or an error occurred. In the original version of the application there were problems with Internet Explorer refreshing the processing page automatically because I wasn't flushing anything to the screen during the send process. Once I discovered this issue I updated the application to flush each e-mail address to the screen as the e-mail was sent, which gave the user primitive feedback and also solved the auto-refresh issue with Internet Explorer.