There has been some good buzz in the press and blogs about event gateways in ColdFusion Blackstone, and folks are starting to try to wrap their hands around the concept and what this all means. So …
ColdFusion has long been an incredibly simple way to build Web apps. That’s why we all use ColdFusion, simplicity (and thus productivity). But ColdFusion is not exclusively tied to the Web. In fact, ColdFusion does not even talk to Web browsers (that is the Web server’s job). ColdFusion simply executes scripts on the server in response to requests, requests which (thus far) have been typically HTTP originated.
So could ColdFusion respond to other requests? For example, data sent to a specific port, or changes in a folder, or inbound SMS and IM messages, or database table changes, or … ? The answer is yes, ColdFusion can respond to any and all of those, it just needs a way to know when those events occur.
And that is what the event gateway in Blackstone is all about. Gateways are interfaces to other systems, ways for events to trigger ColdFusion processing. A gateway watching a folder on a server can trigger ColdFusion execution when folder contents change. A gateway connecting to an SMS provider can respond to inbound SMS messages (and send SMS messages as well). A gateway can be pinged by a database trigger so that a database event forces ColdFusion processing (imagine being able to automatically dynamically generate static HTML pages whenever back-end databases change).
Gateway types are defined in the ColdFusion Administrator. Blackstone will ship with some types (we don’t yet know the final count and what exactly they’ll be), we will be sure to ship very useful ones (both as usable types, and as examples). You’ll also be able to create your own types (in Java), although most ColdFusion will find themselves using existing types (included ones, ones available for download, ones written by 3rd parties, etc.). Gateway types are just that, types, they are not gateway instances. The folder watcher type has no code specific to your folders or what you’d want when an event is triggered. An SMS gateway type knows how to connect to SMS servers and exchange messages, but is not tied to a specific account or processing. Gateway types are genericized, they are the processing that is not unique to your application. You can kind of think of gateway types as being a bit like database drivers, they contain (and encapsulate) the code and processing needed to interact with some system or technology. And, as already stated, they are registered in the ColdFusion Administrator.
Gateways are also defined in the ColdFusion Administrator. A gateway is simply an entry that defines the name, the associated type, the name of an optional configuration file, and the name of the CFC file containing your processing. A single gateway type can be associated with as many gateways as needed (so you can have several different IM applications running, or multiple folders being watched each triggering different events). The CFC used is no different to any other CFC, except that specific method names will likely be used. The CFC is straight CFML, and can contain any CFML code and processing. When a gateway event occurs (an SMS message arrives, a database trigger fires, etc.), the ColdFusion gateway engine calls the appropriate CFC method, telling it everything it needs to know about the event. And your CFC code can then respond, using the same CFML that you know and love.
So, if you want to respond to IM or SMS messages, you’d need to define a gateway (using the appropriate gateway type), create a configuration file for account and server information, and write a CFC which accepts arguments and returns data. It’s that simple. In fact, you could quite easily share processing between Web apps and SMS apps (for example) by having different entry-points to the same back-end code. And the differences between systems and transports (and even session state management) are all handled transparently. (For more on SMS gateways, see Tim Buntel’s blog posting http://www.buntel.com/blog/index.cfm?mode=entry&entry=6A1F548E-4E22-1671-548E2C987C3F6F32).
Of course, this means that you need to be writing ColdFusion Components. Actually, you should be writing them anyway, but if for some reason you are not yet doing so, consider this your very compelling justification to do so right away. You’ll be hearing and reading lots more about gateways in the coming months (there will be entire sessions on this subject at MAX in New Orleans), but for now, keep using those CFCs.

10 thoughts

  1. Very exciting stuff.
    One thing that occurs to me though… "Gateways are also defined in the ColdFusion Administrator. " Too bad gateways can’t be decoupled from the Admin.

  2. I think either Christian Cantrell or Aaron Johnson has posted instructions on managing datasources without explicitly using the ColdFusion Administrator. With a slight tweak to their posted Java code, you should be able to add gateways in a similar manner.

  3. I believe it was mentioned somewhere that Blackstone will have API for CF Admin functionality. Probably a bunch of CFCs you can call to add datasources, gateways, etc.

  4. Ben,
    We anxiously await access to this functionality, yet noone I know has gotten access to the beta yet, despite having filled in the forms at surveymonkey. Will the gateway would be socket-based and with ascii encoding (like web services), or will one be able to pass binary objects, say from one CF server to another? I have an app that is dying for this functionality (currently I call a web service to do this, but this creates huge overhead). Thanks a stack.
    Steve

  5. Steve, beta applications are being accepted, but the beta has not started yet … we’re almost there, don’t panic yet.

  6. Hey Ben, You had mentioned that there are going to be a variety of gateways that will be available as stock with CF Blackstone. If I could add one to the suggestion box — a debug gateway of some sort. When I first heard of gateways, that was the first thing I thought — the ability to create some sort of telnet session to the server where I can see debug information, or to be able to poke/prod session or application variables without editing the page and doing a <CFDUMP>
    Thanks!

Leave a Reply to Chris Simmons Cancel reply