At last year's Developer's Confer-ence I presented a session on creating n-tier (or multitier) applications in ColdFusion, explaining how tiered applications were more manageable and reusable. So why bring this up almost a year later? Well, a project I was working on recently forced me to revisit this topic, but this time for a whole new reason.

Sending Faxes with ColdFusion
A few years ago I wrote an application that needed to generate faxes programmatically. This particular application was used heavily, and generated thousands of faxes a day. To handle that kind of load I set up a dedicated fax-server - a computer equipped with multiple fax boards (each capable of sending multiple faxes simultaneously) and special software that turned data (text, graphics, and even application files) into faxes. The fax-server had multiple interfaces: a print driver that redirected output to the server, low-level APIs, a polling agent that picked up files from specified directories, and even an e-mail gateway.

Because I had no idea which interface would work best, I wrote a custom tag that black-boxed all the processing. I could simply pass data to a tag that looked like the following code, and all the heavy lifting could be tweaked and revised as needed:

<CF_SendFax TO_NAME=""
TO_NUMBER=""
FROM_NAME=""
FROM_NUMBER=""
SUBJECT="">
...
</CF_SendFax>

In the end I used the e-mail interface, which provided the simplest integration from a CFML coding perspective. I was able to use <CFMAIL> to send e-mail to a special mailbox (the TO attribute contained the recipient fax number, the message body contained the cover sheet, and so on). Clean and simple.

A month or so ago I needed to send faxes programmatically again, only this time for a low-volume application running on a Windows 2000 server. So, instead of setting up an expensive high-end fax server, I opted to use the fax services built right into Windows 2000 (yes, Windows 2000 installs a true fax service if you have a fax modem installed). The interface to this service is COM, so using <CFOBJECT> and a series of supporting <CFSET> tags (and some help from Dain Anderson of www.cfcomet.com fame), I ended up with a custom tag that could send faxes via this service. The interface was completely different: COM versus e-mail, files containing content versus message bodies, passing values as properties versus mail headers, and Windows-only versus multiplatform. What did my new custom tag look like? I'll show you:

<CF_SendFax TO_NAME=""
TO_NUMBER=""
FROM_NAME=""
FROM_NUMBER=""
SUBJECT="">
...
</CF_SendFax>

It's All About Encapsulation
So, two very different faxing solutions with very different capabilities and very different interfaces. Yet from within my CF code they're essentially interchangeable.

What makes this all work is encapsulation: taking a process and black-boxing it within a clearly defined interface so the inner workings are hidden and isolated. Encapsulation in ColdFusion is achieved via custom tags in much the same way as Java developers write beans and Windows developers write DLLs. And just like writing beans or DLLs, encapsulating processes within custom tags requires careful planning. A well-designed encapsulation as a custom tag mustŠ

• Provide a clean and consistent interface to simplify invocation
• Not require extensive understanding of the internal workings
• Not have dependencies on external objects, code, or assumptions - code should just work as is
• Be well documented

Group Development
Once upon a time (which was not that long ago in human years), all development was done by individuals - often someone with no social life, lots of caffeine, and a stack of books on everything from IP to JavaScript to creating animated GIFs. Fortunately, we've gotten past that stage; development is (or should be) a well-managed process, complete with schedules, project management, and groups of developers with complementary areas of expertise.

That's a good thing, except that all the little bits that make up ColdFusion development (and indeed all Web development) tend to be so interrelated that developers need to know lots of things about lots of technologies. This of course makes it hard to find developers, harder to keep them, and even harder to train new ones.

Which is why tiered code and encapsulation are so important. Suppose your GUI gurus create a sophisticated menuing and navigational system, or your DBA redesigns your database schemas, or your resident COM expert implements the aforementioned fax services integration. If all these were encapsulated properly, any developer could use the underlying technologies without special training, without needing lots of help, and without making all sorts of horrible mistakes. And if (or when) those same gurus and experts changed or updated their creations, the developers using them wouldn't have to restart from scratch.

Tiering your code - encapsulating functionality or processes or components - is the key to successful group development.

Portability
Portability refers to the ability of code to run on different systems without requiring changes. For the most part, portability is of no real concern to ColdFusion developers. After all, I don't know many ColdFusion installations that suddenly needed to move from Linux to Solaris, or from Windows to HP/UX.

So why is portability of interest? Back to the fax example I started off with. Portability is impacted not only by the underlying operating system, but also by any external services - like faxing. The fax service I just used is very operating system-specific. It runs on Windows 2000 only (not even on Windows NT or Windows ME). Does that mean I shouldn't use it? Absolutely not. There's nothing wrong with using whatever services and features that are available to you. If it's there, use it.

At the same time, you must protect yourself and make sure you aren't marrying your code to external processes you can't control. In my case, if the fax service goes away in the future, or if I have to run the app on Linux, or if I suddenly find that the volume of faxes has exceeded the abilities of this simple serviceŠwell, then, I'll find another faxing solution and create a tag with the same name and attributes to encapsulate the calls. None of my code will break; any needed changes will be local and controlled; and, for now, I can go on using what works because, well, it works for me right now.

In other words, why worry about portability until you really have to? For now, just make sure any code that could present portability problems is appropriately encapsulated. Worry about portability if that ever actually becomes necessary.

For the record, this isn't a new concept. Internally, this is exactly how ColdFusion works. <CFFTP> is implemented on Windows in a very different way than it is on UNIX, but CF developers don't need to know this. The underlying code is different, but the functionality and interfaces are the same, thanks to encapsulation.

Summary
Tiered development is nothing new, and n-tier development theory is the kind of stuff that makes stuffy academics break out in smiles. True n-tier development can be a pain to implement, but the basics of tiered development - breaking code into logical chunks with the appropriate levels of encapsulation - are very applicable to ColdFusion development. Keep this in mind the next time you design an application. The extra effort is minimal, and the benefits are staggering.