The following diagram shows the architecture of ColdFusion event gateway applications:
Typically, a ColdFusion event gateway instance, a Java object, listens for events coming from an external provider. For example, a general socket event gateway listens for messages on an IP socket, and an SMS event gateway receives messages from an SMSC server.
Each event gateway instance communicates with one or more listener CFCs through the ColdFusion event gateway service. The listener CFCs receive CFEvent object instances that contain the messages, process them, and can send responses back to the event gateway, which can send the messages to the external resources.
Alternatively, a ColdFusion application can initiate a message by calling a ColdFusion function that sends the message to the event gateway. The event gateway then forwards the message to an external resource, such as an instant messaging server. A CFC in the application listens for any responses to the sent message.
Some event gateways can be one-way: they listen for a specific event and send it to a CFC, or they get messages from a ColdFusion function and dispatch it, but they do not do both. The example DirectoryWatcherGateway listens for events only, and the asynchronous CFML event gateway receives messages from CFML only. (You could even say that the directory watcher gateway doesn't listen for events; it creates its own events internally by periodically checking the directory state.)
Java programmers develop ColdFusion event gateways by writing Java classes that implement the coldfusion.eventgateway.Gateway interface. ColdFusion event gateways normally consist of one or more threads that listen for events from an event provider, such as a Socket, an SMSC server, or some other source. The event gateway sends event messages to the ColdFusion event gateway service message queue, and provides a method that gets called when an event gateway application CFC or CFM page sends an outgoing message.
The event gateway class can also do the following: