Vince Bonfanti's Weblog - BlueDragon.NET

ColdFusion Markup Language (CFML) on Windows Azure!

Mon, 01 Feb 2010 16:58:00 -0400

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!

There's still a bit of work to do before we can officially release BlueDragon.NET for Windows Azure, but we're very excited to have achieved this milestone so quickly after completing the port from Visual J# to C#. 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.NET port to C# complete -- new opportunites for ColdFusion Markup Language (CFML)

Thu, 17 Dec 2009 10:18:00 -0400

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.

BlueDragon.NET at DevConnections 2009 in Orlando, March 22-25

Fri, 30 Jan 2009 11:45:00 -0400

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

In the mean time, you can download BlueDragon.NET and try it for yourself during the 30-day evaluation period. We'll see you in Orlando!

`memcached` client CFC for BlueDragon.NET

Thu, 04 Dec 2008 14:57:00 -0400

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]

BlueDragon.NET versus ColdFusion 8: .NET Integration Compatibility

Fri, 19 Sep 2008 14:50:00 -0400

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]

BlueDragon.NET: alternatives to CFGRID, CFWINDOW, and CFTOOLTIP

Fri, 29 Aug 2008 15:25:00 -0400

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!

BlueDragon.NET versus ColdFusion 8: .NET Integration Performance

Wed, 27 Aug 2008 11:57:00 -0400

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]

BlueDragon.NET versus ColdFusion 8: Multiple Instances

Thu, 14 Aug 2008 16:41:00 -0400

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]

BlueDragon.NET Performance: Another Satisfied Customer

Mon, 04 Aug 2008 12:34:00 -0400

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."

This prospective customer is now moving into full production testing with BlueDragon.NET and I expect that within a few weeks I won't have to refer them as "prospective," but simply as another satisfied BlueDragon.NET customer. 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.

BlueDragon.NET versus CF8 .NET Integration: Architecture

Tue, 29 Jan 2008 12:01:00 -0400

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.

New Atlanta partners with Microsoft for "Heroes Happen Here" 2008 launch wave

Thu, 06 Dec 2007 10:03:00 -0400

From a Microsoft press release:

Reaching a major milestone in development, Microsoft Corp. today made available the Windows Server 2008 release candidate one (RC1) for customers to download and evaluate. In addition, Microsoft committed more than $150 million (U.S.) worldwide for outreach and demand generation to IT professionals and developers, and disclosed additional details and partner programs in preparation for the "Heroes Happen Here" launch events, beginning on Feb. 27, 2008, in Los Angeles. The launch features Windows Server 2008, Microsoft SQL Server 2008 and Microsoft Visual Studio 2008, and the theme is focused on celebrating the incredible work that IT professionals and developers do to deliver heroic results to their organizations, colleagues and customers.

Listed in the press release among the partners participating in the Heroes Happen Here launch wave is our very own New Alanta. Look for more info from us on this as the date draws closer.

Why migrate from ColdFusion to ASP.NET?

Tue, 02 Oct 2007 12:24:00 -0400

There's a thread on the CF-Talk mailing list on which this statement was made:

For what it's worth, it's almost never a good idea to switch from CF to .NET, or vice-versa, if you have any significant investment in application code. Anyone who tells you otherwise is just angling for your money.

I happen to disagree with that statement, so I offered this response:

There are many good reasons to stay with CF rather than switching to .NET, but there are also many good reasons to switch from CF to .NET, as we've seen many companies do over the past few years (starting with MySpace.com). I'm not advocating that anyone *should* make that switch, but here are some of the reasons we've heard from people who have made the switch (not necessarily in any particular order):
Licensing costs. Some people balk at paying $7500 per CPU pair for CF Enterprise when ASP.NET is included in Windows at no cost. I understand that CF Standard is $1300 per server, and that for a small number of servers even the $7500 per 2-CPU cost can be small compared to overall project costs. But, for someone with dozens, or hundreds, or thousands of servers, the CF license costs can become a real obstacle.
Performance and reliability. Some people find they get better performance and reliability of their web applications running .NET rather than CF.
Developer tools. Some people find that the tools available for ASP.NET development--especially Visual Studio--are superior to tools available for CF development.
Developer availability. Some people find it's easier to hire trained, experienced ASP.NET developers than it is to find and hire trained, experienced CF developers.
I realize I have to tread carefully in this forum, so again, I'm not advocating that anyone should switch from CF to .NET, but am disputing Dave's statement that, "it's almost never a good idea to switch from CF to .NET" by pointing out that there are many organizations for whom it has in fact been a very good idea, and listing some of the reasons why. Since I'm sure to be accused of "just angling for your money" anyway, let me point out that BlueDragon.NET can be very effective in helping you migrate from CF to .NET while preserving your investment in CFML code.

CF is a good tool, but so is ASP.NET. There are legitimate benefits to both technologies, and reasonable, competent people can and do choose one or the other (or choose to switch from one to the other) based on their needs. Saying that someone should "put down the crack pipe if he thinks it's a good idea to switch from CF to .NET" is not reasonable nor technically sound advice, and does not make a positive contribution to any rational discussion of the topic.

Migrating from ColdFusion to ASP.NET via BlueDragon.NET

Fri, 07 Sep 2007 14:47:00 -0400

We regularly talk to companies and organizations who are migrating their web application platform from ColdFusion to ASP.NET, and one of the most common questions we're asked is, "Why would I use BlueDragon.NET instead of just rewriting everything in ASP.NET?" This is a reasonable question, and there are some cases where it might make more sense to just rewrite; however, we believe that in the majority of cases it makes more sense to use BlueDragon.NET. When addressing this question, the two major issues are the cost and time of rewriting versus the cost and time to migrate using BlueDragon.NET (cost and time are related, but are separate issues, as I'll explain). The issue of cost is relatively straightforward. BlueDragon.NET Standard Edition costs $1999/server for unlimited CPUs; BlueDragon.NET Enterprise Edition costs $2999/CPU (see the price list on our web site). You know how many servers you have, so calculating the cost of migrating to BlueDragon.NET is easy--though keep in mind that most of our customers require fewer BlueDragon.NET servers than ColdFusion servers to handle the same amount of traffic; in one dramatic case, a customer was able to replace 14 CFMX 7.0 servers with only 4 BlueDragon.NET servers (your mileage may vary). Calculating the cost of rewriting is a bit harder--and most software developers I've known tend to underestimate this effort--but at least you can use the cost of the BlueDragon.NET licenses as an upper limit on what you should be willing to pay to rewrite. Here are some example figures: suppose you have three production servers and you'll use the BlueDragon.NET Standard Edition. Your cost for BlueDragon.NET licenses would be: 3 X $1999 = $5997. Now let's assume developers cost you $50/hour (a very low number!): $5997 / $50 = 120 hours. So if it takes more than 120 hours (3 weeks) for one developer to rewrite your entire application, it'll cost less to use BlueDragon.NET instead. These are simplistic numbers to illustrate a point. Of course, there's also effort involved in migrating from ColdFusion to BlueDragon.NET; however, in our experience this effort is measured in days or weeks, whereas the cost to rewrite is usually measured in months and sometimes years. This issue of time to rewrite directly affects the cost, but there's another issue with the time it takes to rewrite that's separate from the direct cost. For the duration of time that it takes to do the rewrite, you can't add any new features to the application that's being rewritten. For some applications, and for short rewrite durations, this isn't a big deal; the old application doesn't need to change and can keep running on ColdFusion while the new application is being rewritten for ASP.NET. But for some applications (both internal and customer-facing), it isn't practical to say, "We're not going to add any new features to the old application for 6 months or more while we rewrite for ASP.NET; where we're done with the rewrite, then we can start adding new features again." There's an opportunity cost associated with a rewrite: you can't do anything else while you're rewriting. Migrating via BlueDragon.NET allows you to avoid this opportunity cost, and to rewrite your application incrementally over time, while still adding new business-critical features. One real-world example illustrates both the cost and time issues. A prospect (now customer) came to us saying they estimated it would take two years and cost $10 million for them to rewrite their ColdFusion application (this is a commercial banking application that had been developed by a large team over many years). This was clearly unacceptable; just imagine, after spending two years and $10 million they'd end up with exactly what they have today--the exact same application, only implemented for ASP.NET instead of ColdFusion! And because this is a commercial application that they sell in a competitive market, there's no way they could stop adding features for two years while they did the rewrite. Both the real costs and opportunity costs of rewriting made that an impossible task. Instead, they spent about $40K for BlueDragon licenses, and a few months effort to do the migration (primarily testing just to verify that everything works the same). While cost and time are the two major issues, there are other issues to consider. Is the ColdFusion application an old, legacy application for which there isn't any active development going on now or anticipated for the future? Maybe it's even running on an ancient version of ColdFusion--maybe CF 5.0 or 4.5? If so, then why rewrite at all? Why not just move it to BlueDragon.NET to gain the performance and reliability advantages of the modern Windows and .NET platform? Again, this is somewhat of a cost issue, but in addition to "What will it cost?" and "How long will it take?" you also need to ask "Why am I doing this?" and "What do I expect to gain?" Another point to consider is that BlueDragon.NET allows you to create mixed CFML/ASP.NET web applications. You've heard the saying "ColdFusion is Java", well it's equally or more true that "BlueDragon.NET is ASP.NET". BlueDragon.NET extends the ASP.NET runtime to support CFML applications; BlueDragon.NET is implemented as an IHttpHandler, which is the standard mechanism for extending ASP.NET. IHttpHandlers play the same role in ASP.NET as Java Servlets do in J2EE servers. Many people (especially on the ASP.NET side) don't understand just how fully integrated BlueDragon.NET is with ASP.NET, and this integration is going to be even stronger when we release BlueDragon.NET 7.1 for IIS 7.0. BlueDragon.NET not only allows you to create mixed CFML/ASP.NET web applications, but it also allows you to have mixed development teams, and to retrain CFML developers in ASP.NET gradually over time. This is especially important for shops that have large teams of CFML developers. Rather than bearing the cost and inefficiencies of retraining CFML developers all at once, BlueDragon.NET allows for a gradual and less stressful migration for everyone. There are other factors to consider, but this blog entry is already long enough. If you want to learn more or discuss any of these points in detail, contact me by leaving a comment on this blog entry, or send an email to sales@newatlanta.com. To learn more about BlueDragon.NET, refer to the Deploying CFML on ASP.NET and Integrating CFML with ASP.NET documents on our web site. Then download BlueDragon.NET and try it for yourself. P.S. I intentionally did not address the question of why someone would want to migrate from ColdFusion to ASP.NET in the first place. That's a completely separate discussion and perhaps a topic for another blog entry for another day. My point here is not to try to convince anyone that they should migrate from ColdFusion to ASP.NET, or to debate the pros and cons of ColdFusion and ASP.NET, but rather to address a question that's commonly raised by people who have already made the decision to migrate.

.NET CLR versus Java VM: Innovation

Thu, 02 Aug 2007 10:21:00 -0400

I just ran across this interesting blog post from May that contains this quote:

"I think it’s clear that Microsoft are innovating faster on the CLR. ... Generics were supported earlier and better in C# than in Java ... the CLR has better support for multiple languages than the JVM; and now it has the DLR, which is probably two years ahead of the JVM being able to offer anything comparable."

I couldn't agree more, though I disagree with some of the author's conclusions in that same blog entry (from reading the full blog entry and others, the author seems to have a pro-Java, pro-open source, anti-Microsoft bias; it's interesting that in spite of these biases he can still recognize the technical superiority of Microsoft's solutions). From my personal experience with the Java Community Process (JCP) and the glacial pace of innovation on the Java platform, I'd guess that his view that Java can catch up to the DLR within two years is overly optimistic. The technical advantages of the .NET CLR over the Java VM are among the main reasons we're putting so much engineering effort into BlueDragon.NET, particularly the new DLR-based implementation.

Windows Server 2008 to be launched Feb 27, 2008

Wed, 18 Jul 2007 08:18:00 -0400

At last week's Worldwide Partner Conference 2007, Microsoft announced that Windows Server 2008, SQL Server 2008, and Visual Studio 2008 will be launched together on Feb 27, 2008. The announcement is somewhat buried in this press release. Here are articles on ZDNet and NetworkWorld. I'm sure we'll hear a lot more about this as the date draws closer.