BlueDragon.NET versus ColdFusion 8: .NET Integration Compatibility
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.
The Adobe documentation lists eight .NET Interoperability Limitations for CF8; I'd like to focus on three of these:
- You cannot invoke methods with pointers as arguments or the return type.
- You cannot invoke methods that take Out parameters.
- You cannot pass CFML structures or queries directly to .NET methods.
- You can invoke methods with pointers as arguments or the return type.
- You can invoke methods that take Out parameters.
- You can pass CFML structures or queries directly to .NET methods.
I created a simple example to use the GemBox component to do the following:
- Create a new Excel file with an empty worksheet.
- Insert the results of a CFQUERY into the empty worksheet.
- Search the spreadsheet for a given text string ("rome"), and return the row and column where the string is found.
Here's the demo source code:
<cfquery datasource="ows" name="films">
SELECT * FROM Films
</cfquery>
<cfscript>
excelFile = createObject( ".net", "GemBox.Spreadsheet.ExcelFile" );
worksheet = excelFile.get_Worksheets().Add( "films" );
// automatically convert "films" query to System.Data.DataTable
worksheet.InsertDataTable( films, 0, 0, false );
excelFile.SaveXls( expandPath( "films.xls" ) );
</cfscript>
<p>Created films.xls!</p>
<cfscript>
cellRange = worksheet.get_Cells();
foundRow = -1;
foundCol = -1;
</cfscript>
<!--- return out parameters: foundRow, foundCol --->
<cfif cellRange.FindText( "rome", false, false, foundRow, foundCol )>
<p><cfoutput>Found 'rome' in row #foundRow#, column #foundCol#</cfoutput></p>
<cfelse>
<p>Did not find 'rome'</p>
</cfif>
</cflock>
Click the following links to:
- Run the demo
- Download the demo source code to try yourself
Actually, there's no "automatic conversion" taking place; BlueDragon.NET internally implements CFML query variables as a subclass of System.Data.DataTable, so the CFML query variable just gets passed directly to the InsertDataTable method without any conversion at all! Similarly, BlueDragon.NET internally implements CFML struct variables as a subclass of System.Collections.Hashtable, so can pass a CFML struct directly as an argument to methods that require a System.Collections.Hashtable. This is great not only for compatibility, but also for performance!
You should also note the call to the FindText method; the last two arguments are .NET "out" parameters that get updated within the method to contain the row and column numbers of the text, if found. As stated in the Adobe documentation, CF8 doesn't support "out" parameters for .NET method calls.
If you're using CF8, you won't be able to run this demo, because CF8 doesn't allow you to invoke the InsertDataTable or FindText methods. If Anuj wants to update his CFC to support inserting the results of a CFQUERY into a spreadsheet, or searching for text within a spreadsheet, he's going to have a much more difficult task with CF8 than he would with BlueDragon.NET.
More generally, this simple demo illustrates the points that:
- If you're using third-party .NET components, with CF8 you may be not be able to use all the functionality of those components because there are methods you won't be able to invoke. With BlueDragon.NET, you won't have these limitations.
- Similarly, with CF8 you won't be able to invoke all of the built-in .NET Framework API methods. With BlueDragon.NET, you'll have much more freedom to use the rich features offered by the .NET Framework.
- If you're designing your own .NET components for use with CF8, you'll have to be careful about how you design the methods of your APIs in order to avoid the limitations of CF8. Again, with BlueDragon.NET you'll have much more freedom to take full advantage of the features offered by .NET.
It's interesting that the Adobe marketing blurb for the CF8 .NET Integration features says:
"In previous versions of ColdFusion...you could use web services to integrate ColdFusion and .NET, but that technique often suffered from poor performance or compatibility problems."As I've shown here and in my previous blog entry, the CF8 .NET Integration feature in fact suffers from similar performance and compatibility problems as web services. The CF8 .NET Integration feature does not provide "native" .NET integration at all--as they claim--but is based on Java-to-.NET bridge technology and remote procedure calls that are architecturally very similar to web services.
The only way to get the performance and compatibility advantages of true native integration between CFML and .NET is with BlueDragon.NET.
If you're interested in learning more, download a 30-day evaluation copy of BlueDragon.NET to experience these benefits for yourself.
In future blog entries, I'll explore a set of features provided by BlueDragon.NET that CF8 doesn't support at all: integration with ASP.NET and IIS.
Selling point for CF8 and .NET integration was - you work in Java environment where there is huge amount of free code you can use but now you can also add intergation with .NET with having to create web services (which is some scenarios are very slow).
Now let's be opposite - what is the difference in speed when connecting to Java datasources without building web services between BD.NET and CF8? There is another problem. Many people started using underlying Java objects mixed directly with CFML. That means future migration from CF8/OpenDB/Railo to BD.NET may be painful.
In my opinion CFML already has well established technology platform - it is Java. I don't see the point for using CF instead of ASP.NET in .NET env. Only reason may be if I want migrate my apps from CF to .NET step by step. Maybe...
"BlueDragon.NET is created with .NET? Then I'm not surprised your implementation is faster when it comes to .NET or has more capabilities than the one built into CF8."
Yes, you'd think this would be an obvious point. You'd also be surprised at how many people don't get it, which is why I'm going to the trouble to explain it in this blog series.
"Selling point for CF8 and .NET integration was - you work in Java environment where there is huge amount of free code you can use but now you can also add intergation with .NET with having to create web services (which is some scenarios are very slow)."
I think Adobe has oversold the CF8 .NET Integration feature, using technically inaccurate and misleading phrases such as "native integration" and "unified runtime." Again, that's part of my motivation for writing this blog series.
"Now let's be opposite - what is the difference in speed when connecting to Java datasources without building web services between BD.NET and CF8?"
There's no such thing as a "Java datasource." A datasource is a database server such as Microsoft SQL Server, Oracle, or MySQL. CF8 communicates to these databases via JDBC; BlueDragon.NET communicates to these databases via ADO.NET, which performs as well or better than JDBC (especially when working with Microsoft SQL Server, ADO.NET and BlueDragon.NET offer both feature and performance advantages over JDBC and CF8, as you'd expect).
"There is another problem. Many people started using underlying Java objects mixed directly with CFML. That means future migration from CF8/OpenDB/Railo to BD.NET may be painful."
Not as painful as you might think. We've helped many customers migrate from Java-based ColdFusion to BlueDragon.NET, and have become quite good at it (this is probably a topic worthy of another blog entry).
"In my opinion CFML already has well established technology platform - it is Java. I don't see the point for using CF instead of ASP.NET in .NET env. Only reason may be if I want migrate my apps from CF to .NET step by step. Maybe..."
There are many advantages to running CFML on .NET instead of Java; the top reasons we hear from BlueDragon.NET customers are: performance, reliability, and better integration with Microsoft products and technologies.
I enjoy many aspects of .NET, but am not a fan of ASP. CFML, in my mind, is a much more intuitive Web language. In that sense, BlueDragon is a no-brainer.
Just my $.02...