Yes, you read the title correctly, and no, I'm not losing it. I really do believe there are times when you should not use ColdFusion. And before crowds start gathering in the streets to burn my effigy, let me explain.

Understanding ColdFusion
ColdFusion, as we all know, is an application server, and a darn good one at that (whew, saved myself just in time). ColdFusion does lots of wonderful things for us. It reads and writes information in databases, it performs all sorts of conditional processing, it interacts with server file systems, it talks to HTTP, FTP, LDAP and mail servers, and much more.

But the fact that ColdFusion can do all those things for you doesn't mean it should, nor does it mean you should always use ColdFusion to solve all problems.

Let me put it another way. ColdFusion provides all the logic elements needed to write complex business rules, but applications dedicated to processing such rules can probably do the job far more efficiently. Similarly, ColdFusion provides tags and functions that can be used for directory and file manipulation, but compiled code written using low-level IO libraries will typically be far more effective at that same job. Another example: ColdFusion lets you loop through retrieved data to perform aggregate calculations, but any database will dramatically outperform ColdFusion at this same task.

Now before I get into trouble, let me state very clearly that this is not a flaw in ColdFusion. It is deliberate and by design. There is no application that does everything better than any other application. Application development always involves trade-offs - you have to give up some things to gain others. That's true of every application, from operating systems and development tools to the applications that you yourself develop.

ColdFusion is designed to provide you with incredible functionality, and with almost no learning curve. It's a tough balance to maintain, but ColdFusion has proved remarkably capable at playing these dual roles. And in doing so, there is an understanding that there are some things ColdFusion will never do as well as other applications.

Again, this is not a flaw. Read on.

When Not to Use ColdFusion
What makes ColdFusion unique is that it was designed with the understanding that there are products and technologies out there that excel at specific tasks. Unlike other application development systems that lock you into a specific set of tools or options, ColdFusion was designed to be completely open and flexible.

Of course, ColdFusion's creators also realized that developers shouldn't have to write low-level C code each time they want to perform directory or file-level operations. Thus the core CFML language was enhanced to include tags that can do those things. But that doesn't mean that CFML is necessarily the best way to solve a problem. Don't confuse the convenient solution with the ideal one.

In many ways ColdFusion is middleware. It is less an application and more a facilitator, glue you use to bind all the bits that make up your application - commercial bits, bits written in ColdFusion and bits written in other languages. These bits are typically called components.

Using Components
There's another reason to use other products and technologies to extend ColdFusion, aside from being able to leverage the advantages and strengths of those products and technologies.

Logic implemented in ColdFusion can't be shared easily with other applications. Now, if your entire organization ran only on ColdFusion, that wouldn't be a problem, but I've yet to come across any organization that can make that claim. Be it accounting systems, shipping tools, human resource management products, network security systems and who knows what else, your organization is likely made up of lots of different products. By moving logic or business rules, for example, into external components, they may be shared by different applications.

Let me give you an example. You have an e-commerce site (everybody does, right?). When items are purchased you run complex calculations to determine tax and shipping fees. Now you could write all that logic in ColdFusion, but if you did you'd end up re-creating that code for every other application that needed access to those calculations. A better solution would be to create components that perform the necessary calculations, and allow those components to be shared by all your applications, including ColdFusion.

Here's another example, perhaps a more tangible one. Your application accepts form fields from a user and then writes them to a database. To ensure database consistency you first massage the data - you convert state abbreviations to uppercase, capitalize country names and other proper nouns, and convert all phone numbers to a standardized format. And you do it all in ColdFusion using simple <CFIF> and <CFSET> statements and a bunch of CFML functions. Of course, data can be inserted into your database from other sources too (other applications, perhaps, including your DBMS's admin tools), so you'd need to find a way to write code to normalize data in every one of those applications too, a task that's not fun and possibly not always even doable. A better solution would be to write those conversion and manipulation rules at the database level (maybe as a trigger, or as a scheduled stored procedure); that way any applications would automatically benefit from those rules, including ColdFusion. In this example that database level trigger or stored procedure is the component, the external block of logic that applications can leverage.

Extending ColdFusion
Allaire has always believed that we developers should be able to pick the best-of-breed products when needed. And if there is no best-of-breed product, well, developers should be able to write their own. With ColdFusion they can. Ever since ColdFusion version 2 there have been ways to extend the product, and with every subsequent release the number of ways to do this has increased.

In ColdFusion 4.5 (the current release) the primary methods include the C/C++ API, COM, CORBA and server-side Java. (I'm not including custom tags here as those are used to write CFML code - they're obviously not used to write code that can't [or should not] be written in CFML.)

C/C++ CFXs
ColdFusion's C/C++ interface has been around since before most developers started using the product (unfortunately, in all that time the interface hasn't really changed much). The C/C++ interface exposes a subset of ColdFusion's functionality to code written in C or C++. Functions are provided to read and write queries as well as to perform basic variable manipulation.

Using this interface it's possible to call any C code from within ColdFusion. Indeed, it's primarily used to write interfaces to other C code libraries (this is the interface I used to create my CFX_Zip tag, for example).

The big advantage of this extension is performance. The big disadvantage is that a good working knowledge of C (or C++) is required, as is the ability to write multiuser safe code. As such, this interface is usually used only for very specific projects.

COM
COM - Component Object Model - is a software specification that's designed to allow applications to dynamically link (include) components at runtime. What this means is that developers can encapsulate functionality into clean published components and then allow other applications to interact with them.

COM objects are usually DLL or EXE files, and they can be written in almost any language imaginable, from C/C++ or Visual Basic to Java or Delphi. Once an object is written, it must be installed and registered on the computer on which it is to be used. Registering the COM object publishes it (and its interfaces) to other applications (like ColdFusion since version 3) so they can use it.

The big advantage of this extension is that COM objects are easy to write (Visual Basic, Visual C++ and other development tools even feature wizards to simplify COM object creation). The big disadvantage is that COM is essentially a Microsoft Windows-only solution. As such, COM is best suited for highly Windows-centric environments.

CORBA
CORBA (Common Object Request Broker Architecture) is an alternative specification for a distributed component object definition and use. The CORBA specification is defined by the Object Management Group (OMG), a group that includes some of the leading industry vendors. In a CORBA environment an object is an encapsulated entity whose services are accessed only through well-defined interfaces. The location and implementation of each object is hidden from the client requesting the services.

CORBA is a sophisticated and powerful specification. It's also a very capable and very scalable one. And ColdFusion (as of version 4) can call CORBA components.

The big advantage of this extension is that CORBA is powerful, portable and scalable. The big disadvantage is that CORBA isn't cheap (and I'm not just talking about initial cost of software). As such, this ColdFusion extension is best suited for organizations that have an existing investment in CORBA technology. I honestly don't see organizations embracing CORBA just to use it via ColdFusion.

Server-Side Java
By now everyone has heard of Java. What started off as a language promising complete portability (incidentally, C started off with the same promise) has evolved into a powerful platform complete with all sorts of APIs and extensions. At the base of it all there is still a language - Java - and, obviously, doing any work in Java requires a good working knowledge of the language. (For the record, while Java is probably easier to learn than C or C++, it's considerably harder to learn than ColdFusion.)

Server-side Java is just that: Java that executes on the server. Unlike applets, which are Java applications that run on the client (the browser), server-side Java executes on the server, much like ColdFusion. Unlike applets, which are more often than not useless (thank goodness the days of 20-minute page downloads to be able to display a colored rotating bullet are over), server-side Java has quickly proved itself to be capable, scalable and highly portable. And ColdFusion 4.5 supports several different types of Java integration (extending the CFX_J interface made available in ColdFusion 4).

The big advantages of server-side Java are the ones I just listed - scalability and portability, as well performance. The big disadvantage is that you have to learn Java, but newer Java technologies are making that process much simpler. As such, extending ColdFusion with server-side Java is a good choice for just about anyone. There's no real downside to this one.

Summary
An important part of knowing how to use ColdFusion is knowing when not to use ColdFusion. There are lots of great products and technologies out there, and you should pick the best components for the job (or write them yourself if needed). The good news is that using the extensibility options listed above, ColdFusion can be made to work with just about anything out there.

As I alluded to before, my current bias is toward extending ColdFusion using server-side Java. One very important reason for this is that Allaire is a big believer in server-side Java (as demonstrated by the acquisitions of Live Software and Valto), and Java is going to play a very important role in the future of ColdFusion. If you use Java to extend your applications, you'll be right on track with what Allaire has in store for you. But I'm out of space, so more on that next month.