ColdFusion MX 7 has some exciting new functionality but the most important and revolutionary of these new features, hands down, is the event gateway. Event gateways are to application server environments what the CFQUERY tag was to database interaction.

As you will see, the event gateway technology transforms ColdFusion MX 7 (CFMX 7) from just another Web application server to an enterprise services platform, allowing CFMX 7 applications to work with just about any other application and/or platform over any well-defined protocol including SMS, RMI, MQ, JSM, AMS, TCP, and UDP. If you have ever worked with message-oriented middleware, much of the paradigm behind event gateways will be obvious to you. On the other hand, if you've not, the ColdFusion event gateway operates like MOM.

Event gateways also allow ColdFusion applications to perform in new and nontrivial ways. You, the developer, can move away from an HTTP-based request/response development approach to event-based frameworks that respond to events created by such things as a folder change or a phone call. Before you begin this article, take a breath and clear your mind. Try to forget what you know about traditional Web development. Read this article with an open mind, knowing that there is no possible way a single article can cover everything that event gateways can do. The only limit now to ColdFusion MX 7 is your imagination. Okay, let's begin.

What Is an Event Gateway?
ColdFusion MX 7 gateways are Java classes that implement an application programming interface (API) provided with the CFMX7 application server. Figure 1 shows a high-level diagram of the event gateway communications. Event gateways communicate with the ColdFusion event gateway services through CFEvent objects, which we will define later. The event gateway service system puts CFEvent objects, if necessary, in a queue and then passes them to the ColdFusion run-time engine for processing as input to ColdFusion Components (Listener CFCs). The Listener CFC might return output to the event gateway services subsystem and then back to the event gateway.

You create gateway instances from a gateway type. Instances correspond to individual copies of a gateway that are running. Gateway instances are Java objects that are started/stopped through the ColdFusion Administrator. Each gateway instance specifies a CFC to handle incoming messages. You can have more than one instance of an event gateway type, and each instance will have its own configuration. For example, you can have multiple instances of a given gateway type, each with a different login, phone number, buddy name, directories to watch, and so forth.

Simply put, ColdFusion's new event gateway exposes the power of J2EE's underlying messaging technology. This allows you to use ColdFusion in a way that's different from the traditional HTTP-based request/response model. Web applications have grown more sophisticated and moved from isolated information-retrieval applications to mission-critical applications that not only expose some applications to users but tie together older processing systems, databases, enterprise resource-planning systems, and so on. As this evolution progressed, developers frequently had to kludge special and proprietary connections to other applications. ColdFusion developers often found it hard to connect to legacy applications, ERP systems, package applications, and other commercial off-the-shelf applications - usually by using a variety of other languages and proprietary integrations tools.

This difficult task was compounded by previous ColdFusion versions sometimes having difficulty scaling. Requests to these applications often hold open a connection and/or thread while ColdFusion connects to another application, retrieves that information, and creates a response, even though no user or application is waiting for a response. For example, a scheduled task that fires off a batch process sending thousands of e-mails to subscribers could tie up ColdFusion threads for an hour until the process is finished. Now, with ColdFusion event gateways, you can fire an event from a ColdFusion page or CFC and run that batch process in the background, while keeping your ColdFusion threads free to handle Web requests.

Events in ColdFusion are asynchronous requests, which means that a request can occur but the actual requested action can occur at another time; this is different from traditional HTTP requests, which either are fulfilled or timed out. ColdFusion events can reside in a queue where each event is fulfilled when the server has capacity and resources to handle it. This is especially useful for applications in which a transaction or process doesn't need to happen at the time a user requests it, such as notifying a system that an order has been placed. Asynchronous messaging has many other uses as well.

Categories of Event Gateways
Event gateway systems essentially fall into two categories.

Initiators are CFMX7 applications that generate an event message from a CFC or CFML application page and send the message using an event gateway instance. An example of an initiator would be an application that checks a POP 3 server for new messages and, if new messages are there, sends an SMS notification that forwards the information to your cell phone. This is done by using the sendGatewayMessage function to send outgoing messages like these SMS text messages through an event gateway.

Responders are CFMX7 applications that receive an event message from some external source through the listening event gateway instance. The event gateway service then routes the event to a listener CFC that you configure when you create an event instance. Depending on the method triggered by the event, the CFC can return a response. An example could be an IM Help Desk application. Let's say you want to give users the ability to IM your company and get help on technical problems. You could set up an IM event gateway and instance, and have a listener CFC that waits for IMs and then routes them to the first available technical support person or, if no one is free, sends a message asking the customer to wait. The customer is then put into a queue and later connected to the first available technical-support person.

A responder listener CFC listens for an event from a given gateway instance and processes the event structure passed to it, to return a response. The event structure contains the message, along with some detail about its origin. If you dumped the CFEvent message, it might look something like Figure 2.

Creating a Simple Gateway Application
In Chapter 29, "Extending ColdFusion with Java," we created several examples for a photo album application. One of the examples we created looped over the contents of a directory and made thumbnails for all the images found in that directory. That's pretty cool, but it requires a user to interact with the application through a Web browser. What if your boss now asks you to allow users to FTP-upload files of photos, and wants the application to detect that a file has been uploaded and create an associated directory of thumbnails! Normally you couldn't do this with ColdFusion because you're not interacting with the server directly through HTTP - but with ColdFusion MX 7 and the DirectoryWatcher event gateway, it's a snap.

For this example, the DirectoryWatcher event gateway (supplied with CFMX7) will create a simple responder application. The DirectoryWatcher gateway sends events to a listener CFC when a file is created, deleted, or modified in a directory you tell the gateway to watch. It checks the directory at an interval specified in a configuration file that you edit, and when the interval has passed, checks for changes since last time. If it finds any changes, DirectoryWatcher sends a message to a listener CFC, which can perform the unzipping and creation of thumbnails.

First you need to configure the gateway configuration file, found in:

coldfusion_root\gateway\config\directory-watcher.cfg

For this example we'll assume that your ColdFusion root is on drive C, so a literal example of the file path would look like this:

C:\CFusionMX7\gateway\config\directory-watcher.cfg

Open this file and edit the very first attribute, directory, and have it point to where you will FTP your zipped files. For this example, the directory is called gallery and the path is as follows:

directory=C:/Inetpub/wwwroot/JavaInteg/imageio/resize/gallery/

Table 1 lists a number of other configuration file attributes you can set. After you've edited the directory path, save the file.