ColdFusion 7 contains a new subsystem to support event gateways. The gateway types are Java classes that implement an application programming interface (API) provided by ColdFusion. Figure 1 shows the process for event gateway communication. The gateways communicate with the CF Event Gateway Services subsystem through CFEvent objects. The subsystem, in turn, queues the CFEvent object requests and passes them to the ColdFusion runtime 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 1. Process for event gateway communication
Some of the event gateways provided with ColdFusion MX 7 are SMS for mobile text messaging; XMPP for open-standard instant messenger networks such as Jabber; Lotus Sametime for enterprise instant messenger communications; and asynchronous CFML for sending requests from your CFML to a CFC for processing in a separate thread. ColdFusion 7 also provides some sample event gateways types (with source code), including JMS for messaging applications that support the Java 2 Enterprise Edition (J2EE) standard; TCP/IP Socket for use with a telnet client to interact with your applications; and Directory Watcher for watching a file system directory and to run your CFC when a user or application creates, edits, or deletes a file in that directory.
You create gateway instances from a gateway type. Instances correspond to individual copies of a gateway that are running. This is an object that is started/stopped (through the 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 different logins, phone numbers, buddy names, directories to watch, and so forth.
Getting into the mind set of writing event gateway applications requires a change in thinking from writing traditional web applications. The paradigm is different because you are no longer tied to the request/response nature of HTTP. Event gateways are asynchronous and can receive and send messages without depending on each other.
There are two basic types of event gateway applications: initiator applications and responder applications.
An initiator application is a ColdFusion application that generates an event message from CFML code and sends the message using a configured event gateway instance. An example of an initiator application is an e-commerce application that sends an SMS notification when a user's order has shipped. The application uses the SMS gateway to send a message, responding to some logic in the CFML code. You can enhance any CFML application to be the initiator. Use the sendGatewayMessage function to send outgoing messages, such as SMS text messages through an event gateway. In this case, you use the function just like the CFMAIL tag.
A responder application is a ColdFusion application that receives an event message that comes from external source through the listening event gateway instance. The event gateway service forwards that event to the listener CFC, and the CFC method returns a response back to the event gateway instance. An example of a responder application is an IM 'bot that responds to questions. Responder applications are written in CFML and use a CFC as the listener for a gateway. The 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:
| gatewayID | Instance ID |
|---|---|
| data | ColdFusion structure containing message data |
| originatorID | Identifier of event sender |
| gatewayType | Type of gateway (SMS, IM, etc.) |