COM

There are two extremes that developers can go to with COM. The first is the developer who wants to use COM for everything, and the other is the developer who wants to avoid COM no matter what.

There are many good reasons for using COM in your application ”just make sure that you have some before you use COM in your application. Good reasons for using COM are as follows :

• You have existing, well-designed, tested COM objects.

• You want a componentized application design.

• You want to take advantage of COM+ services.

This is by no means a comprehensive list, but it helps emphasize the importance of good early design in your application. There are, however, a number of problems that you can run into if you decide to use COM in your application. (In fact, you can run into some of these issues even if you don t use COM, but they re more common for COM developers.) We discuss these issues in the sections that follow.

OLE Automation Types

One of the first issues that the ATL Server team often finds with real-world applications is an abuse of OLE Automation types (e.g., BSTRs). The OLE Automation types are designed and optimized for communicating over COM interfaces. They can, however, lead to scalability and performance problems if you abuse them in your applications.

How do you know if you are abusing OLE Automation types? Examine their use in your application. Are you keeping their use almost exclusively to COM communication code? Or are you using them throughout your application? It s not uncommon for the ATL Server team to see examples of applications where, even though COM isn t being used, OLE Automation types are used extensively. Though it s obviously not a problem to perform one or two simple operations on these types, are you passing them through to other functions? Because of the limitations of these types, the ATL Server team often sees cases where developers are converting from OLE Automation types to richer types (e.g., BSTRs to CString s), and then back to OLE Automation types to pass to another function, which then converts to a richer type, and so on. This cycle of constant type conversions is unwieldy, unnecessary, and very inefficient.

Marshaling

One of the keys to making efficient use of COM in your application is understanding marshaling of COM interfaces. This involves not only understanding the concepts of marshaling (which are beyond the scope of this book), but also understanding which marshaler you re using (yes, you have a choice).

The main point we want to get across in this section is that you do have a choice of marshaler, and for almost all applications the default marshaler is going to be inefficient. Examples of other marshalers that may be more efficient are the ATL Wizard “generated marshaler and the COM+ lightweight marshaler (if you re using COM+). Another way to go is to create a custom marshaler, but there are issues with this.

Most of the issues with custom marshaling revolve around ensuring that your custom marshaler is efficient for the application in which you re going to use it. Again, it can be easy to try and reuse a previously created custom marshaler or to make use of a companywide custom marshaler that was designed to be very efficient for a different application.

Security and Process Model

Another important issue if you re going to use COM is that you need to understand the security and process model of COM. These are issues that you need to keep in mind when designing your application, ensuring that you keep the pros and cons of different options in mind and choose the one that best suits your particular application.

The COM process model enables developers to use an object in-process or from an external process. There are advantages to using each of these models. Running from within your application s process (or IIS) enables very efficient communication with the object, but it does pose some risks. These risks include isolation (crashes in the COM object will now bring down your application), application size (your application will increase in size , making for less efficient use of processor caches), and separation (updating the component won t be as easy).

Running from outside of your application s process (or IIS) protects you from these risks, but you now pay a cross-process marshaling penalty whenever you try to access your object.

The COM security model enables you to ensure your objects are correctly secured. There are two risks you face here. The first (less severe) risk is that your objects become inaccessible to your application. The second (more severe) risk is that your objects are now accessible to unauthorized users. This is a problem particularly if your object is processing sensitive information.

COM+

COM+ development issues run exactly the same as the COM development issues: Either developers use COM+ without requiring any of its features and add unnecessary overhead and complexity to their applications, or they avoid COM+ like the plague and end up implementing the same functionality in a less efficient and more bug-prone way.

Why would you want to use COM+? Do you need COM+ functionality? COM+ functionality includes the following:

• Transaction support: Transactions are a very complex area of computer science. COM+ provides one of the best transactional implementations under Windows, so if you need transaction support in your application, use COM+.

• Object pooling: Object pooling allows your application to be more efficient by having a preinstantiated pool of objects to which you make requests . If you want object pooling, consider using COM+.

• Context management: Context management allows your application to keep information about its execution environment, such as the identity of the object s creator and the transaction encompassing the work of the object.

• Security: COM+ provides its own security system that enables you to make the most of object isolation and how your objects interact with each other.

Need this or other COM+ functionality? Then don t reinvent the wheel ”just use COM+!