Ben Forta

I recently mentioned a Google Talk bot that I put online at cfdocs@gmail.com. Google Talk users can add this user to their buddy list and then submit CFML tag and function lookups to it. (I’ve also brought Yahoo IM and AIM versions online as nickname cflivedocs, but more on those in a subsequent post). As promised, in this post I explain exactly what the IM bot is and what it does, and will continue this topic in subsequent posts.
We’ve all used instant messaging (or IM), almost always for person-to-person communication; send a user a message and it’ll pop up on their desktop allowing them to respond. An IM bot is a virtual IM user (bot is short for robot), an application that can receive and send messages programmatically. Bots are not a new idea, IRC bots have been around for years, in pre-web days we used to use e-mail bots to submit gopher and usenet searches via e-mail, and if you think about it, spiders (used by search engine to index web site content) are bots of sorts in that they programmatically simulate what it is that users would do with their web browsers.
So what would an IM bot be used for? Imagine that UPS or FedEx had bots online (named UPS or FedEx) that would allow you to simply type a tracking number in an instant message, instantly receiving a tracking response. Or an airline allowing you to type in a flight number to obtain gate information or flight status. Or your company employee directory allowing users to type in partial names to do lookups (the results of which could include an e-mail address which could be clicked on to send an e-mail). Or my ColdFusion LiveDocs example, mentioned previously. Of course, not all applications are suited to this type of interaction. But many are, and IM bots allow you to provide instant access to applications leveraging the immediacy and simplicity of now ubiquitous IM clients.
Developing an Google Talk IM bot obviously requires that you have an application waiting to receive requests (and thus running at all times) that is logged in to the Google Talk network (and thus requiring a thorough understanding of the technical implementations used by Google Talk). Or you can simple use ColdFusion, which obviously will be always running (so as to respond to HTTP requests), and which already comes with the code needed to login and interact with Google Talk. And this requires a word or two (or more) about ColdFusion event gateways.
ColdFusion MX 7 Enterprise (and Developer’s Edition) includes support for event gateways. The best way to understand event gateways is to understand what it is they allow.
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 gateways are 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). And a gateway connected to Google Talk can respond to (and send) Google Talk instant messages.
ColdFusion has a built in event gateway service (which can be stopped and started using the ColdFusion Administrator, and which is running by default). The event gateway service receives all gateway requests, queuing and routing them to the appropriate gateways as needed, and then executing them using a designated number of allowed threads (10 by default).
ColdFusion ships with an array of gateway types out of the box (additional ones are available from 3rd parties, and you may write these yourself too). Gateway types written in Java, and are registered in the ColdFusion Administrator. 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 generalized, 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 must be registered in the ColdFusion Administrator before they can be used.
Gateway instances are also defined in the ColdFusion Administrator. A gateway instance 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. So, if you needed a gateway to respond to requests coming in over a socket, you’d create a gateway instance using the appropriate gateway type and specifying a CFC file that would actually receive those requests so as to be able to respond to them. A single gateway type can be used in 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 are used (these are specified by the gateway type being used, each gateway type will expect specific CFC methods to be present). 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, data is received by a socket being watched, and so on), 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.
Which brings us back to Google Talk IM bots.