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 31.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 in this chapter. 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.

Figure 31.1. ColdFusion event gateway communications.

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 different from the traditional HTTP-based request/response model. Web application 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 applicationsusually 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 emails 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 31.2.

Figure 31.2. Detail of a CFEvent message.