The next major version of ColdFusion, code-named "Blackstone," is getting ready to ship, and by gauging customer and partner reactions thus far, we have a winner on our hands.

Lots of Goodies
The marquee features in Blackstone have been discussed repeatedly over the past few months (especially at MAX in New Orleans). They include:

• Creating rich and engaging Flash forms using simple CFML tags
• Simplified access to industry standard XForms
• Painless creation of printable content (in FlashPaper and PDF formats)
• Reporting extensions (including a brand new Report Writer)
• Gateways that provide a mechanism to connect to just about any back ends and systems, with ColdFusion both initiating communications and responding to requests
• SMS support, enabling ColdFusion to generate SMS messages as well as to power SMS-based applications

Multiple Instances Revisited
ColdFusion MX Enterprise features support for multiple ColdFusion instances, although that is actually less a ColdFusion feature and more a J2EE server feature that ColdFusion users can take advantage of. ColdFusion MX, after all, is a Java application (deployed as an .ear or .war, like any other Java application). Simply put, using multiple ColdFusion instances provides greater security, greater stability, and greater scalability (almost like having ColdFusion installed on multiple physical servers, but all on one server).

The current shipping version of ColdFusion Enterprise supports the use of multiple instances. If you have an existing J2EE server, you can create multiple .ear or .war files, and can then deploy them as you would any other Java application. If you do not have an existing J2EE server, the ColdFusion installer can install JRun 4 for you, and in doing so will also create and deploy the first ColdFusion instance so that you can be up and running immediately.

When you want to deploy additional instances, then things get a little tricky for users without experience in J2EE server administration. You'll need to use the J2EE server administration tools to create a new server, run the ColdFusion installer to create the .ear or .war, expand the files (if using JRun), make tweaks to an XML file, then copy the expanded files into the server folders - doable, but not exactly a trivial process. (Unfortunately, this is why so many users have yet to deploy multiple instances.)

Blackstone will make this a whole lot simpler. In Blackstone you will have the same three installation options that are present in ColdFusion MX 6.1, but selecting the JRun+CF option in Blackstone installs additional administration screens that make the deployment of instances (and even the creation of clusters of instances) as simple as any other ColdFusion administration process. You'll be able to simply fill in a form and hit a button to create a new instance, without needing to use the JRun management tools or the ColdFusion installer, without needing any XML tweaks, and without even knowing what an .ear or .war file is.

How could this be used? Consider these use cases:

1.  You are deploying a brand new application, one that uses its own data sources and is built by a different development team (who need CF Administrator access), and you want the new application to be safely isolated from your existing production applications. Simply create a new instance, launch the ColdFusion Administrator for that new instance, define the data sources and any other needed settings, copy the code, and you are good to go.
2.  You are about to deploy an update to your application code, and need to maintain the existing application as a fallback, just in case something goes wrong. Simply create a new instance (you could even create a .car file using the old instance to save data sources and any other needed configuration, launch the ColdFusion Administrator for the new instance, and import the .car file to import those settings), copy the code, associate your Web server to the new instance, stop the old instance (to prevent resources being used unnecessarily), and you're done. If you then need to roll back, start the old instance, and reassociate your Web server to it. Clean and simple.
3.  You have an existing application that is seeing a spike in load (holiday shoppers maybe), and want an additional server running the same application (so that you can handle a greater load, and also provide failover in the event that a server problem occurs). Simply create a new instance, point to the Java package containing the code and settings used for the first instance, and let ColdFusion do its thing. You'll have a second instance created, configured like the first, and containing the same application as the first. You can then use a second screen to create a cluster (perhaps to enable session sharing between the instances). You get the idea.

Of course, for those who want more control, JRun will still be installed with its own management software just like it is now, and you can deploy and manage applications just as you can now. But for those of us who simply want to leverage what is undoubtedly the most significant benefit of ColdFusion Enterprise over ColdFusion Standard, Blackstone will make life much simpler.

Improved J2EE Deployment
ColdFusion (as of CFMX) is a Sun-verified Java application, and is installed on top of J2EE servers like any other Java applications. Well, kind of. ColdFusion MX (including ColdFusion MX 6.1) can indeed be deployed on top of a J2EE server, but the complete process is one that does not excite J2EE administrators.

In J2EE-land, administrators are typically given an application to deploy, and they don't pay a whole lot of attention to what that application is and how it works. Nor should they; developers worry about applications, and J2EE administrators worry about servers staying up and running well. How does this work? Applications to be deployed on a J2EE server are packaged up as a single file, a Java archive file (usually with a .ear or .war extension). The archive file contains everything needed for an application to run - source code, configuration settings, supporting files, everything. Once an application has been tested and is ready for deployment, it's packaged (and of course the package is test deployed), and handed off to the J2EE administrator who drops it onto the J2EE server (okay, so I'm simplifying things a bit, but the basic flow is accurate). What J2EE administrators don't do (or don't like doing) is run through a post-installation to-do list containing things like create a data source, set up some mappings, install these extensions, and so on.

And yet J2EE administrators deploying ColdFusion MX must do just that. ColdFusion itself (the core engine, compiler, and runtime services) can indeed be deployed like any other Java application, but that's just ColdFusion itself. Once ColdFusion is deployed someone still needs to move all of the .cfm and .cfc files over, and use the ColdFusion Administrator to define data sources and mappings and more. In other words, while ColdFusion itself is deployed like any other J2EE application, the total experience of deploying a ColdFusion application is not.

Blackstone changes this by allowing complete J2EE deployment packages to be built. Blackstone comes with a packaging tool that creates a complete .ear or .war file that can contain the ColdFusion runtime (with or without specific features), application code, data sources, and more. The tool can take some time to run (building a complete deployable .ear or .war is not a quick process), and when complete that package can be given to a J2EE administrator to be deployed just like any other Java applications. This means that ColdFusion applications can even be deployed on a J2EE server that is not running ColdFusion, because the ColdFusion engine will be packaged in the Java package file.

This is an important, and much needed enhancement. From a J2EE administrator's perspective, deploying Blackstone applications will be just like deploying any Java applications. Actually, they'll not even have to know that it's a ColdFusion application - it's Java, pure and simple.

Conclusion
Blackstone is an incredibly exciting release, and I'll be covering Blackstone features in depth in future columns. But beyond developer features, Blackstone also better leverages underlying Java and J2EE to simplify deployment, stability, and security.