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.