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, SOA & WOA Magazine

BlueDragon: Article

Beyond SOA & Web Services - ColdFusion / .NET Integration

As both a .NET programmer and ColdFusion developer, I always wondered how I could leverage the world of .NET in ColdFusion

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


More Stories By Catalin Sandu

Catalin Sandu is a software developer at RomSoft (www.rms.ro) 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.