You've probably often heard of COM objects and ActiveX components and how they can greatly improve your web ASP based applications. Well, just how can they improve your applications, and is it worth it? We'll take a look at the pros and cons here and lay everything out, so you can decide for yourself if COM can help you.
This article will assume you have a good general knowledge of Active Server Pages, and basic COMon knowledge. (Get it? COM-on knowledge, common knowledge? Anyway...)
What is COM?
The Component Object Model, or COM, provides a basis for allowing objects to expose its functionality to other objects or applications in other words, any application can interface with and use another application through COM. This allows for great code reuse and object oriented-ness. With COM, you also have language interoperability. You can code your object in VC++ and access it through Visual Basic because the object will use a standard interface to communicate, the COM interface (an interface in COM is simply a table of pointers to functions that the object exposes, but you don't need to know that).
Now when we speak of COM objects, we are actually talking about ActiveX and OLE (Object Linking and Embedding) objects that use the COM protocol to communicate with other applications and processes. So what is an ActiveX object? Simply any program that does something, and exposes its functionality. This can be from a little calculator to Microsoft Word.
How Does COM Work with ASP?
There are two ways you can access COM objects from an ASP page client side, and server side. I'll briefly mention client side objects here, and then we'll spend the rest of the article discussing server side objects.
On the server side, the most common way to create an object is by using:
Set item = Server.CreateObject("ApplicationID")
The application ID specifies the type of object to create. There are many built in objects to Internet Information Server (IIS), such as the Request and Response objects. You should be familiar with:
Here, you are calling the built in response object. Or:
Set rst = Server.CreateObject("ADODB.Recordset")
to access an ADO database. So you are familiar with basic COM objects already.
Well, the beauty part is that you're not limited to the built in objects. You can create any type of object you wish. From objects that simply wrap up ADO functionality, to objects that manage an entire system of documents and users. The limit is simply your imagination (and coding skills).
And creating a COM object is relatively easy as well. If you're writing good ASP code in VBScript, then you're almost there. You can simply copy the code into a VB application, compile it as a COM object, and you're ready to use that object in your ASP page.
So what are the reasons we should use a COM object versus simply placing the relevant code in an ASP page? There are quite a few, the most important of which I will list here.
This may not sound like a big deal, but when you have 100 ASP pages that require individual coding, you'll understand my point. Imagine, for example, every single one of the pages requiring a connection to a database and a recordset to display. You could write the Server.CreateObject method and associated SELECT statements and execute queries 100 times, or you could write it in one function in a COM object, and write one line of code each time, instead of the typical four or five.
Not only does this save you time to write code, but it also makes running everything easier. Imagine your connection string changed one day instead of having to change it in 100 places, you can now change one line in one place and you're done.
Another speed benefit is derived from more strict coding standards. If you are already coding with strict grammar, good job, but most of us aren't. By using strict grammar (declaring all variables, closing all connections, using typesafe names, etc) you save the computer that much more headache, and you get a speed boost for your troubles. The benefits are definitely worth the extra time you'll spend fine-tuning your code. (For more information on speed tuning ASP code, check out this article.)
There's not a week that goes by that someone hasn't discovered another hole in a Microsoft product. If you've been paying attention to the tech news (as you should be!), you'll know what I'm talking about. There are many holes in IIS that allow the clever hacker to view, modify, or delete your hard work. For instance, appending :$DATA on the end of an ASP page url on an unpatched version on IIS 4.0 will allow anyone to view all of your code.
When you move your code into a COM object, however, there is no way to sneak a peak like that, because the code has all been compiled. The only holes you have are ones that you didn't cover yourself, through faulty code.
3 Tier Model
This may not be applicable to all users, but there has been a big push to moving things to a 3 tier model; separating data, business logic, and the presentation layer. Doing this allows you to better design and separate development. For instance, you could make all your HTML specialists do the presentation layer without having to worry that they'll mess up your ASP code, and the DBAs won't get upset because your SQL statements are wreaking havoc on the database.
Using COM objects helps you easily migrate to this model, by wrapping up all the business logic into a separate component. Using COM objects almost forces you to use this approach (though be aware that the divisions between the layers are not always clear cut). Best of all, you can keep your code nice and tidy, while others will be impressed that they only need to call one line of code to do all that logic.
Yes, after all that good news, you knew there had to be some drawbacks.
This is the major concern for ActiveX web developers. Once you compile your code, you can't change it without recompiling it. This is a tremendous pain, especially when you don't have access to an appropriate compiler. Therefore, you can't simply change a variable, refresh the page, and see the changes. Imagine a poor web developer who has to wait on the COM developer to change something, find out it doesn't work, and change it over again. Over and over again.
When you are developing the COM object on your own computer, however, the problem is not so bad, since you can easily just recompile and refresh your compiler should theoretically automatically re-register your component. You only lose a little time spent recompiling, which can grow exponentially with the complexity of your code.
Also, COM objects can introduce what is known as DLL Hell. When you wish to test a COM object on a different computer from the one it was developed on, you have to register the object on that computer. Now what happens when you have a new version of the object, no matter how small the changes (i.e. a single variable as described above)? With the current version of COM, you cannot have multiple versions on the same computer, so you must uninstall the old version, and register the new version. This isn't that much of a pain, but the problems that can arise make one shiver, such as when the new object breaks old applications, as is bound to happen. This problem takes countless hours and forehead smashing to even locate the source, and double that to find out what you thought was the source isn't.
Luckily, Microsoft is trying to address this issue with new architecture featured in Windows .NET. Among the welcome features is the ability to have multiple versions of objects on the same computer, so you can develop and deploy without running around breaking things.
You may be able to use an object through your ASP pages, but discover that it won't work once you wrap it in a COM object. Why is this? Well, every ActiveX object comes with a license, which has a matching license in the registry, among other places. If you don't have the correct license installed on your machine, you can't use the object. And believe me, I've tried to hack through this license issue, it's very tight.
The solution is to bundle the object you need with your COM object. There are, of course, problems with this as well. The first is that the more stuff you bundle with your object, the bigger it gets. Normally, this isn't a major problem, but if you need to send someone a component via email, watch out.
Another problem is that some objects can't be wrapped up at all. You could build a really cool ASP application that uses Microsoft Word to perform file manipulation, decide to move it to a COM object, and then discover that Word won't let you steal its functionality. You must not only distribute the Word objects themselves, but also must have a complete licensed version of Word on the destination computer! It's not fun, I assure you.
So what can we do to make life easier? First of all, if your entire application consists of one page that only displays items from a database, you probably don't need to use a COM object. The overhead and time spent creating and implementing the object would outweigh the benefits you receive.
Second, do things in ASP first. It's always easier to do things where you can easily test and fix the functionality. Get everything working just right in your script, and then tweak it some more. Moving it to a COM object is bound to open up a new problem, and by then, you've already compiled, and will have to re-compile.
If possible, you can move all the logic that would go into your object into include files. This further separates the logic from the presentation, saving you much headache when you do move to COM objects.
Next, double check to make sure you're not using licensed software that may only be available on your machine. Often times, you will compile and run a COM object on your development machine without a hitch, and then once you move to another computer, find out that it doesn't work at all.
For example, if you are create an object that uses Microsoft's Internet Transfer Control, you will have to bundle that up with your object and transfer everything together. This control already exists on nearly every Windows machine out there, but without the proper license, you can't use it and the license only comes with development tools such as Visual Basic.
Finally, once you've compiled it, expect it to break. Often. Especially when you move it to another computer. Developing good COM objects that work correctly takes a lot of cross-computer testing.
So now you know a little more about COM. Hopefully, this article helped you decide whether or not to move to COM objects, and how to avoid some pitfalls if you do. For some more great resources on actually building COM objects, check out these links: