Some Features of COM

[Previous] [Next]

In this section, we're going to take a look at some of the features that are new in COM+. We'll start with a description of inheritance in general and implementation inheritance in particular.

Implementation Inheritance

One of the things that some developers have criticized COM for is its lack of support for inheritance. One could argue that this criticism hasn't been well founded; after all, COM supports a special kind of inheritance called interface inheritance. This means that one COM object can inherit the interface of another object and guarantee full compliance with the interface inherited. Using containment, which means that one object contains another object, COM developers have been able to simulate inheritance. The containing object inherits the interface of the contained object; when clients call a method of the inherited interface, the containing object can call the corresponding method of the contained object, thereby reusing the code of the contained object. But it hasn't been possible for a COM developer to reuse code by the use of full inheritance, also called implementation inheritance.

Implementation inheritance means that one object can completely inherit not only the interface but also the implementation code of the inherited object. In implementation inheritance, there's no need for the inheriting object to call the inherited object to reuse its code; reuse is automatic. If the inheriting object needs to do things differently from the inherited object, it can override the implementation of the inherited object. COM doesn't support implementation inheritance at all; COM+ does through aggregation.

Aggregation is a special form of containment. When using aggregation, a COM+ object can directly expose the interface of a contained object to clients. There's no need for the containing object to call the contained object; this is done automatically through aggregation. There's one restriction that you should know about, though: aggregation works only with in-process components. In fact, aggregation works only within apartment boundaries.

We wanted to tell you about implementation inheritance in COM+, but this book is definitely not the place to tell you about all the details, advantages, and disadvantages of it. If you want to know more about inheritance in COM+, and indeed about the apartment model and other threading models, you should get yourself a copy of Inside COM+ Base Services.

Declarative Development

COM+ continues on the road that Microsoft has been on for quite a while now. This road leads to a new development paradigm; increasingly, you can replace code creation with declarations. Microsoft started on this road as early as Microsoft Access 1.0 and Visual Basic 2.0. These product versions allowed you to use data binding, declaring the relationship between a data consumer such as a text box in a form and a data source such as a data control on the same form. Using data binding, there was no need for you to create code to move data from the data source to the data consumer, or to create code to move data from the data consumer back to the data source after the data was modified. It all came automatically from the setting of a few attributes.

Early versions of Microsoft's data binding technologies didn't work particularly well; they were a mixed blessing, especially if you wanted to create anything but the very simplest of applications. Data Access Objects (DAO) was Microsoft's first attempt to deliver data binding. DAO worked fairly well if your database was a Microsoft Access database; less well with Microsoft SQL Server or Oracle databases, to mention just a couple of the more advanced database products. With these databases, you were liable to have both performance and behavior problems caused by the duplication of database engines.

Advanced database products, such as SQL Server and Oracle, have their own server-based database engine; less advanced database products, such as Microsoft Access, don't. Because DAO was originally meant chiefly to support Microsoft Access, DAO had to pack its own client-based database engine. When DAO was used together with advanced databases, two database engines were involved: DAO's database engine on the client side and, say, SQL Server's on the server side. But DAO was the beginning of something really worthwhile, and for many newcomers to Windows and database programming, DAO really was a blessing, making a number of difficult tasks much easier.

Today data binding has matured. Thanks to ADO and OLE DB, you can use much better data binding technologies than before, whether you develop Win32 user interfaces such as Visual Basic forms or page-based user interfaces with HTML 3.2 or dynamic HTML (DHTML). Modern data binding is a real help today, and the performance and behavior problems of yesterday are long gone. During the DAO days, we said to developers attending our courses, "Don't use data binding—use your own code instead!" Today we say, "If you want to maximize performance and minimize problems, use data binding!"

MTS took us several steps further ahead on the same road toward more declarations and setting of attributes and less programming. The transactional attribute available in every MTS component, together with the requirement that components report success or failure to MTS by calling the SetComplete or SetAbort method, was a giant step on that road. Simple attribute setting replaced complicated programming. At least for nontrivial transactions, the difference in programmer workload and program complexity was astounding. In addition to the transactional attribute, MTS gave us declarative role-based security. This feature of MTS can dramatically reduce the need to create security code in MTS components.

COM+ brings us further along on the same road. For example, queued components demand practically no extra programming for message queuing, which is in sharp contrast to the situation before COM+. As we explained earlier in this chapter, all you have to do is set two attributes on a COM+ application and one on each interface involved in queuing to replace heaps of difficult and low-level code.

When component load balancing (CLB) arrives, it will follow the same paradigm. You won't have to modify any programming code to make a component part of a CLB strategy. All you have to do is declare that you want the component to change its behavior.

Tom Armstrong (mentioned at the beginning of this chapter) points out that one of the good things about declarative development is that you can postpone decisions. You don't have to consider every aspect of the behavior you want a component to exhibit while you develop the component. This statement concerns those aspects of the component that you can influence by setting attributes as described in this chapter and Chapter 14. You can postpone such decisions until you deploy the component because these decisions, when you make them, don't affect the internals of the component, only attributes that are external to the component. And those attributes are controlled by and set by an administrator.

COM+ Catalog and the Component Services Snap-In

Before Windows 2000, all the administrative information that concerned COM or MTS components was stored in the Windows Registry. This was OK because compared with COM+ components, COM or MTS components didn't require much administrative information. COM+ needs a better way to store the increased amount of such information, and such a way is offered by the COM+ catalog. The COM+ catalog is a special system database that stores administrative information about COM+ applications, components, and interfaces. The COM+ catalog also makes that information available through the Component Services snap-in that at least on the surface looks a lot like the "old" MTS Explorer.

Figure 15-9 shows part of the Component Services user interface. You'll get to it through the Start menu by pointing first to Programs and then to Administrative Tools and finally by clicking Component Services.

Figure 15-9. The Component Services snap-in.

In Figure 15-9, we have loaded two different but similar console windows. The first one features the components contained in the Racing Facades COM+ application, while the second one features the only component contained in the Racing Main Business COM+ application. Normally you'd have several main business components in the latter application, just as you have in the facade application, but as a demonstration the windows in Figure 15-9 should do.

The console tree is located in the left pane of both windows. It gives you an overview of the components in an installation. Both windows focus on the COM+ Applications branch, and you can see in the lower console window a list of such applications, one of which is expanded, showing its components. You can also see which security roles have access to the respective applications featured in each window. Interestingly, roles such as Administrator and Customer have access to the facades application but not to the main business application; only the AdminFacade and CustomerFacade roles have access to main business components.

The right pane of the console windows gives detailed information about the element selected in the console tree. For example, the components selected in the console tree of each window and the view selected in the right pane of each window let you see the setting of the transactional attribute of the components. In Figure 15-9, you can see that none of the facade components support transactions, whereas the only business component requires transactions. (From this setting of the business component's transactional attributes, you can draw one of two conclusions: either the business component is stateless or the design itself might lead to locking problems. We'll qualify this statement in Chapter 23, "Some Final Issues," in the section called "Revisiting the Stateful Model.")

If you select a component and then click Properties on the Action menu, you're rewarded with a dialog box containing several tabs, each tab making one type of attribute of the component available for viewing and setting. In Figure 15-10, we've selected the Security tab of the dialog box to see or set the security settings of the component.

Figure 15-10. This is the Security tab of the component properties dialog box.

In the Security tab, you can set one property that decides whether the COM+ application should make authorization checks for this component or whether any user permitted to use the COM+ application should automatically also be permitted to use this component. In Figure 15-10, this property is set so that this component will do its own access check. To access this component, clients must first have access to the COM+ application itself, but also to this very component. With component-level access checking set up like this, you must select one or more authorization roles, which are shown in Figure 15-10.

Just as you can select properties for a COM+ component, you can do it for an entire COM+ application. (Remember, a COM+ application is a collection of configured COM+ components, just as an MTS package is a collection of COM components.) Figure 15-11 shows the security settings of the COM+ Racing Facades application, to which the component studied in Figure 15-10 belongs.

Figure 15-11. Security settings for the entire COM+ application.

Figure 15-11 shows that COM+ also allows you to set an application-level attribute to decide whether the application itself should enforce access checking. If you decide to enforce access checking, as in the figure, you must also set a few other attributes to make the security story complete. You can have security checked at the process level only or at both the process and component levels. Checking at the process level only means that clients permitted to access the COM+ application can access all the components of the application. Checking at both levels means that clients permitted to access the COM+ application can still be refused access to an individual component in that application; to be permitted access to a component, security on that component must also be set, as shown in Figure 15-10.

Figure 15-11 also shows that you can select one of the six standard authentication levels and one of the four impersonation levels available; these attributes in fact belong to the Windows 2000 Distributed Security Services. The authentication level attribute spans from None, meaning that no authentication control is performed, to Packet Privacy, meaning that each call is authenticated and verified, and also that each argument passed with remote calls is encrypted. The impersonation level settings span from Anonymous, where the client is unknown to the server (meaning among other things that the server can't impersonate the client), to Delegate, where the server can impersonate the client's security context and make calls to other servers on behalf of the client. We'll direct you to Inside COM+ Base Services for more information about both these concepts.

Let's look at one additional figure before we leave this section. Figure 15-12 shows how a particular user account is selected to run the Racing Facades COM+ application.

Figure 15-12. One user account is selected to run the Racing Facades COM+ application process.

Every COM+ application (and MTS package) must be run by a user account. As shown in Figure 15-12, there are two options to choose from:

• Interactive User, which is the default option. With this setting, the application runs in the name of the user logged on the computer that is running the COM+ application and its components.
• This User, an option that requires that the COM+ administrator pick an existing user account from Windows' security database. The application and, of course, all the components installed in it are then run using the chosen user account and the access privileges given to that account.

In Figure 15-12, a special user named RacingFacade, registered as a user in the ADBMAIN domain, is chosen to run the Facades COM+ application. When components in that application call on other components in other COM+ applications, or when they access the database, it's the special user named RacingFacade that makes the call or accesses the database. For the action to be successfully completed, the RacingFacade user account must have all the privileges needed to use the resource called on, be it another component in another COM+ application or a database object.

The Compensating Resource Manager

Another new feature of COM+ Component Services is the Compensating Resource Manager (CRM). The purpose of this feature is to let you enlist a nontransactional operation in a transaction. For example, the file system of Windows 2000 isn't transactional; you can't roll back or commit operations on a file. Every operation on a file is automatically committed as soon as the operation is completed. Therefore, you can't enlist a file operation, such as the deletion of a file, in a transaction and have the file arise anew if another part of the transaction fails. With a CRM, you can!

When you create a CRM, you create two components, a CRM Worker and a CRM Compensator. You set the transactional attribute of the CRM Worker to require transaction; then you design and program its methods to do the work you want to include in the transaction. If the job is to delete a file, as in the example mentioned in the preceding paragraph, the CRM Worker moves the file in question to another folder. Before moving the file, the CRM Worker component connects to the CRM Clerk component through the ICrmLogControl interface (both components being parts of COM+) to have the operation enlisted in the transaction and therefore logged. When the transaction is completed, that is, either committed or rolled back, COM+ fires an event and calls the CRM Compensator component to publish that event through the ICrmCompensator interface. This interface contains methods such as BeginCommit, CommitRecord, EndCommit, BeginAbort, AbortRecord, and EndAbort. Depending on which methods COM+ calls, the CRM Compensator object can react to the event and permanently remove the file or move it back to its original folder.

Of course, the delete-a-file example is only one kind of the nontransactional operations that CRM lets you enlist in transactions. The CRM story we've told you is incomplete also in that you should know more details before you use CRM. For more information about CRM, we recommend David Cameron's speech, found in the Microsoft Windows 2000 Developer's Readiness Kit. There's also information about CRM in David Platt's Understanding COM+.