We've just achieved the first "Hello World" CFML page running on Windows Azure via BlueDragon.NET, New Atlanta's ColdFusion-compatible CFML server. Click the link below to see it yourself:

Hello from BlueDragon on Windows Azure!

Let me know if you're interested in getting early access to a technology preview release of BlueDragon.NET for Windows Azure, which we plan to make available to selected customers within the next few months.

BlueDragon, New Atlanta's ColdFusion-compatible CFML server, was originally written in the Java programming language. The BlueDragon.NET edition--which was released almost five years ago and powers MySpace.com, the world's largest CFML web site--was originally created using Microsoft's Visual J#. Using Visual J#, which compiles Java-language source code directly to .NET Common Language Runtime (CLR) byte code, allowed us to rapidly port the very large BlueDragon code base from Java to .NET; and, it allowed us to share a significant percentage of code between the Java and .NET editions of BlueDragon (about 80% of the code in BlueDragon.NET 7.1 is shared Java-language source code--the rest is written in C#).

However, in January 2007 Microsoft announced plans to retire the Visual J# product, which meant that we needed a new strategy for BlueDragon.NET. There wasn't an immediate urgency to address this issue because Microsoft will continue supporting Visual J# through 2017; and, both Visual J# and BlueDragon.NET 7.1 are fully supported on the recently released Windows 7 and Windows Server 2008 R2 operating systems. But, the fact that Visual J# will not be supported by Visual Studio 2010 or .NET Framework 4.0 meant that it had become obstacle to future development of BlueDragon.NET.

Earlier this year New Atlanta engineers began the effort to port BlueDragon.NET to a pure C# code base and I'm happy to announce that this effort has been completed. We now have a version of BlueDragon.NET in-house that's written completely in C# and passes all of our regression testcases. Having achieved this major milestone, we can now move forward with several projects that we had either started or planned, but were blocked due to the dependency on Visual J#.

While I can't yet forecast when these will be delivered in commercial product releases, here are some of the BlueDragon.NET projects we're working on or have planned related to various Microsoft products and technologies:

• Windows Azure. Cloud computing is one of the most exciting and important technology trends to emerge in recent years. Our goal is to provide complete support for developing and deploying ColdFusion Markup Language (CFML) applications on Microsoft's cloud computing platform via BlueDragon.NET.
• SharePoint. Microsoft's business collaboration platform has become one of its most successful and popular server-based products. Our goal is to allow developers--via BlueDragon.NET--to create fully-integrated SharePoint content written in ColdFusion Markup Language (CFML).
• ASP.NET MVC. Microsoft's new web application model-view-controller (MVC) framework supports content (views) that are created using technologies other than ASP.NET WebForms. We currently have a working prototype of a custom view engine based on BlueDragon.NET that allows fully-integrated ASP.NET MVC content to be developed using ColdFusion Markup Language (CFML).
• Visual Studio. Key to integrating ColdFusion Markup Language (CFML) with other Microsoft products and technologies--such as Azure, SharePoint, and ASP.NET MVC--is the ability to develop and debug CFML within Visual Studio.
• Dynamic Language Runtime (DLR). Visual Studio 2010 and .NET Framework 4.0 implement significant enhancements for integrating dynamic scripting languages with the .NET Common Language Runtime (CLR). We are already exploring ways to take advantage of these enhancements in the BlueDragon.NET implementation of ColdFusion Markup Language (CFML).
• Linux/Mono. An "open source, cross-platform implementation of C# and the .NET Common Language Runtime (CLR) that is binary compatible with Microsoft.NET," the Mono project allows C# applications to be deployed on Linux operating systems. Now that Visual J#--which isn't supported on Mono--is no longer required, it should be possible to deploy BlueDragon.NET (and CFML applications) with little or no changes on Linux via Mono.

We're very excited by all of these new opportunities, and I look forward to providing more details about each of these new projects, and to technology preview releases that we plan to make available starting in 2010.

As it has been since we first announced BlueDragon.NET almost seven years ago, it remains our goal to provide BlueDragon.NET customers with the best possible solutions for integrating ColdFusion Markup Language (CFML) with Microsoft products and technologies.

New Atlanta will be exhibiting at the DevConnections Spring 2009 event in Orlando, FL from March 22 through 25. Stop by our booth to learn how you can use BlueDragon.NET to:

• migrate existing ColdFusion applications to ASP.NET without rewriting any code
• improve the performance and reliability of your ColdFusion applications
• integrate ColdFusion (CFML) and ASP.NET technologies

We'll see you in Orlando!

We were recently asked by a customer whether BlueDragon.NET could support memcached, a "high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load." Though BlueDragon.NET already supports query caching, our customer's goal is to implement a cache that can be shared across multiple servers in a cluster and that can store data types other than just query results.

In response to their request we created the Memcached client CFC for BlueDragon.NET, which is based on the .NET memcached client library.

[More]

This the third in a series of blog entries that compare BlueDragon.NET with the ColdFusion 8 (CF8) .NET Integration feature. In the first, I discussed the architectural differences between the two products; in the second, I showed how these architectural differences translate into an enormous performance advantage for BlueDragon.NET. In this blog entry, I'd like to show the advantages of BlueDragon.NET regarding .NET compatibility.

[More]

Michael Sprague has written a very nice set of CFML custom tags that use the jQuery JavaScript libraries to implement alternatives to the CFGRID, CFWINDOW, and CFTOOLTIP tags introduced in ColdFusion 8 (CF8). In Michael's words:

"This (CFjqAjax) is a library of custom tags that replicate the CFGRID, CFWINDOW, and CFTOOLTIP tags from ColdFusion 8. The CF8 tags work, but I find YUI and Ext much harder to work with than jQuery, and the file size of the JavaScript libraries that CF8 includes is excessive. So, I created CFjqAjax."

My first thought on reading this was, "I wonder if CFjqAjax will run on BlueDragon.NET?"

Click here for the answer

No changes were required to any of Michael's code to run on BlueDragon.NET (the data displayed in the CF_WINDOW example is different than the demo on Michael's web site, but is displaying correctly based on the contents of the downloaded package).

Nice work, Michael!

CFML-to-.NET integration is the ability to create and invoke methods on .NET objects from CFML using the CFOBJECT tag and CreateObject function. In a previous blog entry I discussed the architectural differences between BlueDragon.NET and the implementation of the ColdFusion 8 (CF8) .NET Integration feature. To summarize:

• CF8 implements .NET integration via remote procedure calls (RPC) to an external process and a Java-to-.NET bridge.
• BlueDragon.NET is implemented as an in-process extension to ASP.NET; creating and invoking methods on .NET objects is done using the .NET reflection APIs.

The implications of these architectural differences for CFML-to-.NET integration are:

• BlueDragon.NET performance is much better than CF8;
• BlueDragon.NET provides much better compatibility with .NET than CF8 (CF8 imposes limitations that BlueDragon.NET does not); and,
• BlueDragon.NET provides a wealth of opportunities for integration with IIS and ASP.NET that CF8 does not support at all.

In this blog entry I'd like to delve into more detail on the first point: performance.

[More]

A prospective customer recently asked if BlueDragon.NET has any advantages over ColdFusion 8 for running multiple instances. For those not familiar with the topic, Adobe has published a short white paper entitled, Multiple Server instances using Adobe ColdFusion 8 Enterprise Edition; in this white paper, the benefits of multiple instances are listed as, "high availability, enhanced security, fine-grained application optimization, individualized application administration, and clustering." All of these benefits are also available in multiple instance configurations of BlueDragon.NET.

[More]

I was approached by a prospective customer at Microsoft's TechEd conference who asked if BlueDragon.NET could solve the performance issues he's having with ColdFusion. I told him that based on our experiences with companies such as MySpace, eBags, HealthGrades, DevX, and dozens of others I was very confident it could, but that "the proof was in the pudding" and the only way to know with any certainty was to test his application.

A few weeks ago I was able to pay him a visit and help set up his application for testing on BlueDragon.NET. We ran into two minor CFML compatibility issues that we were able to fix with patches very quickly, and a few days later I received this email:

"Here are the results of preliminary testing over 1 minute:

CF7: 381 pages served Blue Dragon: 1007 pages served

So Blue Dragon served up 164% more pages or 2.6 times the number of pages as CF 7 running on the same server. This is very encouraging."

These performance gains are typical when doing performance benchmarking of real-world applications on BlueDragon.NET; in fact, a performance gain of 2.6 times is actually on the low end--we regularly see performance improvements of 5 to 10 times just by migrating an existing ColdFusion application to BlueDragon.NET.

If you're having performance problems with an existing ColdFusion application, download a 30-day evaluation copy of BlueDragon.NET to see for yourself the immediate performance improvements it can provide.

Since the release of ColdFusion 8 (CF8), we're regularly asked by prospects and customers to compare BlueDragon.NET versus the CF8 .NET Integration feature--including a conference call this morning--so I thought it was time to write some of this down. In this first of a series of blog entries, I'd like to begin by comparing the architectures of the two products, which is the basis for understanding their differences.

CF8 is implemented in Java; its .NET Integration feature is implemented by bundling a third-party product, JNBridgePro. JNBridgePro runs as a separate server process that hosts the .NET runtime (CLR) and communicates with CF8 via either shared memory, TCP/IP, or HTTP (it's unclear whether the shared memory option is available with CF8; the CF8 documentation for the CFOBJECT tag lists a PROTOCOL attribute that accepts the values "tcp" or "http", with the default being "tcp"; there's no mention of shared memory). In the Windows Services control panel you can see the "ColdFusion 8 .NET Service"--that's the JNBridgePro server.

JNBridgePro creates Java proxy classes that represent the .NET classes you want to invoke; the Java proxy classes manage the client-side communication with the JNBridgePro server. For more information, see: How JNBridgePro works. From a topology perspective, the CF8/JNBridgePro implementation of .NET Integration is very similar to accessing .NET via web services: both implement Remote Procedure Call (RPC) mechanisms where the target .NET objects reside on a server (JNBridgePro) that the client (CF8) invokes via local proxies and a networking protocol. If you choose the HTTP protocol option for CF8/JNBridgePro, the high-level messaging protocol is SOAP--same as web services--making the analogy even more direct and clear (the TCP option for CF8/JNBridgePro uses the .NET Remoting binary protocol).

BlueDragon.NET is implemented in .NET (not Java) as an extension of the ASP.NET runtime to support the CFML programming language. There's no separate BlueDragon server; open the Windows Services control panel or Task Manager and try to find BlueDragon--it's not there. Depending on which version of Windows and IIS you're using, BlueDragon runs within either the ASP.NET Worker Process (IIS 6.0) or IIS Worker Process (IIS 7.0) that hosts the .NET runtime (CLR). See this earlier blog post for a general discussion of the BlueDragon.NET architecture and comparison with Java/J2EE.

When you use CFOBJECT to create a .NET object in BlueDragon.NET, you're directly creating an instance of that object within the same process and .NET runtime, and directly invoking its methods via normal function-call mechanisms. Unlike CF8, with BlueDragon.NET there are no proxy objects, no network communication protocols, no marshalling and unmarshalling of parameters and return values, and no type conversions between Java and .NET. In other words, CFOBJECT for .NET objects on BlueDragon.NET works the same way that CFOBJECT for Java objects works on CFMX/CF8 (and the Java/J2EE editions of BlueDragon).

The architectural differences between BlueDragon.NET and the CF8 .NET Integration feature have enormous impacts on performance, .NET compatibility, and the ability to integrate with ASP.NET. In short, BlueDragon.NET provides much better performance and .NET compatibility than CF8; BlueDragon.NET also provides a wealth of opportunies for ASP.NET integration that are not supported at all by CF8. I'll explore each of these topics in more detail in future blog entries.