The World's Favorite Open Source GPL J2EE CFML Runtime Engine

BlueDragon Developer's Journal

Subscribe to BlueDragon Developer's Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get BlueDragon Developer's Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Open BlueDragon Authors: Reuven Cohen, Elizabeth White, Michael Sheehan, John Gauntt, Salvatore Genovese

Related Topics: Open BlueDragon Developer's Journal, ColdFusion on Ulitzer

BlueDragon: Article

ColdFusion and .NET Integration

Beyond Web services

I have provided a full sample on how to define and consume a WCF service from ColdFusion. It includes both the source code for the contract (see Listing 1) and the configuration XML file (see Listing 2), as well as explanatory comments for the relevant lines of code. The service has been implemented as a simple console application so you can see what is happening when it's invoked: every time an operation is called from ColdFusion, the service will print a log message.

Note that you should first start the service before consuming it from ColdFusion. The sample will run on localhost on port 4500. You can access it through http://localhost:4500/<WCFServiceName>?WSDL.

Of course, console applications may not be the best choice for hosting a service; a better scenario would be to host it in IIS (as a regular Web service), or simply as a Windows Service. But this also depends on the project type you're working on.

Using the Socket Event Gateway
One of the greatest additions to the ColdFusion application server is the event gateway system. Gateways are classes written in Java according to a well-defined application programming interface (API); they are capable of reacting to external events and handling requests not coming through the usual HTTP channel via a Web browser. Event gateways open up your application to the world of asynchronous programming, and so to a whole range of applications. You can even roll your own gateway type, or use the ones provided out-of-the-box in ColdFusion.

Among the gateway samples coming with ColdFusion is the socket event gateway. You can check out the source code for this type of gateway at <ColdFusion Install Folder>\gateway\src\examples\socket\ To use it you have to define a gateway instance first. The default configuration for this socket event gateway will use port 1225 for communication, but you can change it in the configuration file (see <ColdFusion Install Folder>\gateway\config\socket.cfg). After the gateway instance has been defined, it should be started from the ColdFusion Administrator.

Keep in mind that event gateways are a feature of the Enterprise and Developer editions of ColdFusion.

Writing a simple application that sends and gets data over a socket connection is very easy in .NET. All the classes you'll need are located in the System.Net.Sockets namespace. Here's how you can open up a connection and send some data to a socket in C#:

Socket s = new Socket();
s.Connect(host, port_number);

The Send method has a series of overloads that might be helpful; it returns the number of bytes that were actually sent. The Socket class also has different properties that can control the communication. To read data from a socket you use the Receive method as follows:

byte[] buffer = new byte[number_of_bytes_to_read];

Listing 3 is a very simple application (again, a console application) that will send a series of strings to a socket opened on port 1225. The gateway instance (the component in Listing 4) does nothing but return the received string back to the .NET application, which will display it back to you.

Of course, sending simple strings over the wire isn't spectacular, but you can define your own protocol to be followed by all clients that might communicate with your gateway. One possible scenario is sending XML fragments between the client and the server (the gateway instance); what's more, you can use Web Development Data Exchange (WDDX) for this. You already have WDDX support on the ColdFusion side, while in .NET you can use the COM library found on

Expose .NET Components as COM Objects
Let's come back for a while to our old friend CFOBJECT (and its cousin CreateObject). Sure you know that besides Web services you can instantiate COM objects on Windows as well. All you have to do is replace "web service" with "com" for the object type parameter and supply the component programmatic identifier (ProgID). Then you're free to use it whatever way you like. After you're done with the object, you mustn't forget to call ReleaseComObject so all resources associated with the COM object are freed up properly.

With careful design, most .NET assemblies can be exposed as COM objects, making them accessible for COM clients - including ColdFusion pages. The magic is done with a little help from a very neat thing called COM Callable Wrapper (CCW) that comes with the .NET Framework. CCW acts as a proxy between your .NET classes and the COM system. It takes care of reference counting for you, knows how to convert .NET types so that they are visible to the outside world, and comes with built-in implementations for a few standard COM interfaces.

There are some rules to be observed to make a .NET class COM-visible. First of all, you must mark your assembly as being COM-visible. Do that by using the ComVisible attribute in the AssemblyInfo file for your project (AssemblyInfo.cs for a C# project, AssemblyInfo.vb for VB.NET, and so on). Assuming you're writing a C# solution, this is what you need to write to make your assembly visible for COM clients:

[assembly: ComVisible(true)]

By default, ComVisible is set to false; you have to change this as shown above. This way, the .NET objects already defined in the assembly will be available to COM consumers for free. A few restrictions still apply as you'll see in a moment; what should be mentioned here is that you still have the option to control what is exposed or not. Simply by applying the ComVisible(false) attribute to one of your types (class, interface, whatever), that type becomes hidden again - you can even apply this attribute to methods, properties, and data members.

To effectively expose a .NET class to COM, a developer needs to know some rules. First, the class must be public, non-abstract, and have a default constructor. Second, what will be exposed (either data members or methods) must be marked as public; no protected, private, or internal members will be available to COM. What's more, all static stuff goes the same way; they won't be visible from outside.

Most of the COM-exposing stuff is done via some clever class- and method-level attributes. For example, you can assign your own dispatch identifiers for the class methods and properties, and you can choose whatever ProgID you want for a class and so on. To describe them all is beyond the scope of this article, however, you're free to explore the available documentation on

More Stories By Catalin Sandu

Catalin Sandu is a software developer at RomSoft ( and has 10 years of experience. He is both a Microsoft Certified Professional (on C++ and .NET), and an Advanced ColdFusion MX 7 Developer. Catalin is also a member of the British Computer Society since 2005.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.