As both a .NET programmer and ColdFusion developer, I always wondered how I could leverage the world of .NET in ColdFusion. Both platforms come with powerful features and using them together might be a wonderful friendship, if one could only make them cooperate. There are two worlds out there and none of them is an island.

Apart from this, and starting with Windows Vista, Microsoft will include the last incarnation of the .NET Framework in its flagship operating system, with all the bells and whistles that come with it. For those who like their ColdFusion environment hosted on a Windows server, this means they'll always have all the features provided in the .NET platform at hand. Even if a switch to Vista won't be an option in the near future for current projects, you may still wonder how you can put them to work for your ColdFusion application.

The promise of the next version of ColdFusion (code named "Scorpio" and due out later this year) is that it will support .NET natively. This also means that access to this platform will be of interest to ColdFusion developers, in the future anyway. Still, apart from the ability to use .NET objects directly from CFML, there are other ways of making ColdFusion and the .NET Framework talk to each other.

Here we're going to explore some of these methods. This article assumes a basic knowledge of event gateways and how to use external objects from ColdFusion (Web services and COM objects), as well as a fair understanding of the .NET architecture. On the one hand, there's your world, ColdFusion. On the other side is .NET. So what are our bridging options?

Consuming Web Services
Of course, the first answer that comes to mind is to build and deploy ASP.NET Web services. You don't have to know the intricate details of the Simple Object Access Protocol (SOAP) or Web Services Definition Language (WSDL) to successfully write such a component in .NET (or ColdFusion for that matter) - at least for most developing tasks. The .NET Framework will take care of all details for you.

For example, the class that will implement the methods exposed by a Web service doesn't even need to be derived from the Web Service class found in .NET, although doing so will provide the service with direct access to different common ASP.NET objects (session state, application state, request context, and so on). On the other hand, the methods that should be public for the Web service must be decorated with the WebMethod attribute. Not all methods should be decorated this way, effectively making those methods private to the implementation of the component.

Consuming a .NET Web service from ColdFusion is just a matter of using CFOBJECT or CreateObject, depending on the developer's preferences. Care should be taken when defining method parameters and return values so that both platforms understand each other (for example, you can't pass a ColdFusion structure to .NET as is).

Anyway, this road of Web services has already been taken and discussed in many articles about ColdFusion and .NET. I won't go further than that and start exploring other interoperability options.

Talking .NET 3.0: Windows Communication Framework Services
In the last release of the .NET Framework, Microsoft complemented the previous version with a few interesting components. In fact, .NET 3.0 is the old 2.0 platform; the Common Language Runtime (CLR) that sits at the base of the framework hasn't been upgraded at all. On top of it there are now four main technologies written entirely in .NET 2.0: Windows Presentation Foundation (WPF), Windows Workflow Foundation (WF), Windows CardSpace (WCS), and Windows Communication Framework (WCF), which is the focus here.

There are many technologies that are meant for making two applications talk to each other. Depending on the project requirements, one can choose between named pipes, message queue-based communication, peer-to-peer protocols, and so on, including Web services. The rationale behind WCF is to provide a unifying programming model for all existent communication technologies, at the same time offering the possibility of defining your own custom transport protocol. Instead of trying to learn multiple technologies, a programmer would have to know WCF. All components written according to the WCF model can easily talk to applications exposing their functionality through any protocol.

To expose a class to the outside world through WCF, one must define an interface and decorate it with the ServiceContract attribute, while the methods defined for that interface should be decorated with an OperationContract attribute (the ones that aren't decorated as such won't be exposed at all). The C# example below defines an interface (in WCF speak, a contract) exposing a single operation:

[ServiceContract]
public interface IHello {
    [OperationContract]
    string SayHello(string name);
}

The actual implementation must be provided in a class that derives from this interface. To start the service, several other steps must be followed, such as configuring the service (that is, informing the WCF system about the address where the service will be exposed; the configuration is done in a special XML file called app.config), and hosting it (meaning, running the application - there are also several options here, such as compiling the service as a console application, running it inside IIS, implementing it as a Windows service, and so on).

The good news for a ColdFusion developer is that the WCF components can be configured to act as Web services. From a ColdFusion point-of-view, such a WCF object is just another Web service exposing its functionality via WSDL, thus being accessible through CFOBJECT/CreateObject.