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\SocketGateway.java. 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);
s.Send(your_message);

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];
s.Receive(buffer);

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 www.openwddx.com.

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 http://msdn.microsoft.com.

Here's a short example for a class that can be exposed to COM:

public class ExposedClass {
   public void DoThis();    // This method is exposed
   public int someData;    // This data member will be exposed as a COM property
   private long hidden;    // NOT exposed data
   public static float sharedStuff; // NOT exposed because of the static modifier
   [ComVisible(false)] public void DoThat(); // NOT exposed, because of ComVisible(false)
}

Finally, the assembly needs to be registered in the Windows registry so that COM can properly instantiate your exposed .NET stuff. However, since the resulting DLL isn't a true COM component, you won't be able to do this via RegSvr32.exe. For this, you have to use RegAsm.exe, or the assembly registration tool, coming with the .NET Framework:

regasm.exe YourAssembly.dll