Features of COM Services

 

Chapter 18 - COM+ Services
bySimon Robinsonet al.
Wrox Press 2002

  

Features of COM+ Services

COM+ Services began life as a Windows NT add-on called Microsoft Transaction Server, MTS. Subsequently, Windows 2000 subsumed MTS as an integral part of the operating system, renaming it in the process. In addition to all of the original features of MTS, COM+ Services boast exciting new ones that further reduce the amount of code that the component developer has to write. The features of COM+ Services include:

• Automatic transaction handling

• Just-In-Time (JIT) object activation

• Security

• Event support

• Object pooling

• Component message queuing

• Component load balancing

A configured class has a set of COM+ -specific declarative attributes, which specify the required COM+ services. At run time, COM+ ensures that it provides the required services to the COM+ objects. COM+ provides its services through contexts , which are implemented as objects called the object context . All COM+ classes are instantiated in a context, and each object lives in precisely one context. Classes that are not configured ignore their associated contexts.

We should first be aware that there are two different types of COM+ applications:

• A library application is a collection of component classes, that when instantiated, are created within the calling client's process

• A server application is a collection of component classes, that, when instantiated, are created in a dedicated surrogate process that is separate from the calling client's process

Most ASP-based applications typically used components stored in server applications. Because Server Application components are hosted in a dedicated, surrogate process, the failure of a server component doesn't crash the web server. For standard (non-.NET COM applications), you set the Activation type property on the Activation tab of the application's Properties window:

As you'll see later, there's a different procedure for specifying a .NET assembly's activation type. You'll learn how to do it programmatically, with attributes.

Transactions

A transaction is a set of operations that succeed or fail as a unit, that is, if one operation in the set fails, all the other previously completed operations in the transaction must be rolled back to the original state before the transaction was started.

Consider a web site that features credit card processing for orders. If a user orders a product from the site, it is essential that not only is the user 's account charged, but that an order record is placed in the order database as well. If there's a problem entering an order record into the database, the charging of the credit card must be undone, and the order also needs to be canceled , otherwise a user will be charged for an item that they will never receive.

In the old days, developers had to cook up their own transaction enforcement schemes in order to get the sort of functionality mentioned above. These schemes usually involved lots of Boolean variables and elaborate error-handling strategies, and were bug-prone. More recently, the ADODB.Connection object offered support for transactions in a form that was quite elegant. Now, by means of the ContextUtil object that we'll look at shortly, COM+ Services presents developers with a transaction mechanism that is robust, ready-made, and even easier to use than the ADODB.Connection approach.

How Transactions Work

The Distributed Transaction Coordinator (DTC), a component of the Windows operating system, is in charge of administering transactions. Components that can enlist and participate in transactions must match an interface that the DTC understands, and must provide a resource manager that is capable of rolling back or committing units of work when told to do so by the DTC. This high degree of abstraction allows components as diverse as database engines and credit card processors to work together.

The DTC enforces transactions through a process called the two-phase commit. When enforcing a transaction, the DTC first asks every resource manager participating in the transaction whether it will be able to complete its work; this is the first phase. If and only if the DTC receives an OK from every participant, it tells each participant to go ahead and commit the changes; this is the second phase. If one of the participants experiences problems in the first phase, the DTC will tell every participant to undo its work.

Every transaction operation such as a credit card charge and the subsequent insertion of an order record has a context with which it is associated. To say that an operation occurs in the context of a transaction is to say that the operation is a part of the transaction, and can suggest to the DTC that the transaction be rolled back or committed. Such an operation effectively has the power to "veto" the committal of all the operations in its context.

COM+ provides its services through contexts , which are implemented as objects called the object context . All COM+ classes, configured and non-configured, are instantiated in a context. Each object lives in precisely one context.

COM+ provides services to configured classes at run time, when required, through contexts. Non-configured classes, on the other hand, ignore their associated contexts as they are not aware of such object contexts.

Transactions in n-Tier Architectures

Architecturally, the typical client-server application that makes use of COM+ transactions consists of a layer of data access objects that perform the grunt work of adding, deleting, retrieving, and updating records in the database, wrapped with a layer of business objects that enforce the business rules, topped by a Windows Form-based or browser-based user interface.

It's common for a single business object method to call several different methods on several different data access objects. If one of the data access methods fails to execute properly, the business object method can use the COM+ transaction mechanism to ask the DTC to roll the operation back, ensuring that the data is left in a consistent state.

Just-In-Time Activation (JIT)

Because object instantiation consumes server resources, developers have traditionally had to be careful about when in the program it was performed. Specifically, they had to be sure that heavily used, multi-user programs with a lot of traffic only created objects when required, and deallocated them immediately when they were no longer needed. Fortunately for us, COM+ Services provides another approach that frees the developer from this concern.

With Just-In-Time activation, a developer can instantiate objects once at the beginning of the program, and then use them whenever needed, without worrying about the resources that they consume while they are dormant . Invisibly, COM+ Services deallocates the space occupied by the objects when they're unused, and resurrects them at the moment that the client code invokes their methods. Thus, the client code can hold references to many objects for as long as it wants, confident that COM+ Services will provide the objects as necessary, and deallocate their memory whenever possible.

JIT-activated classes must manage state wisely. If COM+ Services deallocates the space occupied by your object between subsequent calls to it, there's no guarantee that the same property values will persist between the first and second call. In other words, classes designed to be used with COM+ services should be stateless.

We've all used server objects that require some initialization before their methods can be invoked. The ADODB.Connection object is one example; you need to initialize its ConnectionString property before you can tell it to Execute() a SQL query. Because a JIT object can't persist state between calls, you can't initialize it and invoke its methods in separate steps. Instead, a call to a JIT object must pass to that object all the values that it needs to perform its work.

Security

There are two aspects to the security model that COM+ Services provide.

The first aspect is authentication. Briefly, COM+ Services allow you to place restrictions on who has access to serviced components and the methods that they provide. Using the Component Services snap-in, you can set an application's authentication level to determine when authentication is performed: upon the client's connection to the server object, or with each network packet of communication to the object, or as each method is invoked, etc.

The second aspect to the COM+ Services security model is a component's impersonation level. Since a server object performs work on behalf of a client, it can sometimes be useful for a server object to assume the access privileges and identity of the client that it serves. The impersonation level allows you to determine this.

Role-based security is the convention typically associated with client-server applications that utilize COM+ Services. In this approach, a server object first checks that its client belongs to a certain Windows security role before performing work on its behalf.

Events

The architecture of the COM+ event mechanism differs from the traditional mechanism of using connection points.

This event service has often been termed the " publisher-subscriber " model. In this approach, you develop an event interface and register it with COM+ Services. Next, you register classes that want to be able to raise events defined in the interface as publishers. Last, you register classes that want to be able to handle events defined in the event interface as subscribers. When a publisher/server object raises an event, COM+ Services is in charge of notifying all of the subscribers. Because the subscriber classes are not directly coupled to the publisher classes, but instead rely on COM+ Services to serve as an intermediary, this architecture is often described as "loosely- coupled " events.

To implement this scheme, you must follow these steps:

• Create an event class DLL that implements the event interface

• Register the event class DLL with COM+ Services

• Create a server component that internally instantiates the event class and invokes methods on the instance in order to raise events

• Register the server component as a publisher with COM+ Services

• Create client components that implement the event interface in order to catch events

• Register the client components as subscribers with COM+ Services

When these steps are completed, a publisher class can raise an event simply by creating an instance of the event class and invoking one of its methods. As noted above, COM+ services will tell each subscriber class that the event has been raised. However, despite the robustness of this approach, there are at least two drawbacks to the way that COM+ Services implements this event model.

• Because subscriber objects are notified of raised events one at a time, each subscriber object has the potential to make the others wait if its event handler is slow

• At least at the time of writing, COM+ Services does not have the ability to raise events from publisher objects to subscriber objects on different machines

Again, the principal advantage of the publisher-subscriber event architecture is that the publisher and subscriber classes remain loosely coupled, able to communicate without maintaining direct references to each other.

Object Pooling

In terms of processor cycles and bytes, it's expensive to instantiate and initialize certain objects. This expense is compounded for a web server that must serve tens of thousands of users simultaneously . So that users don't experience delays while the web server struggles to create component objects, COM+ Services provides object pooling.

As you might infer , this COM+ service allows the maintenance of a pool of objects that are created and waiting for use even before they are needed. When a server session needs a particular component object, it just requests one from the pool of available ones, getting one immediately if one is ready, or waiting in a queue until a new one becomes available. When the object is released by the client, COM+ Services does not destroy it, but instead allows it to persist in the pool, ready in the event that another client needs it. Because you can determine the minimum and maximum number of objects in the pool, you can discretely control how much of the server's resources are dedicated to the component class.

Object pooling is useful when the components being pooled have expensive initialization requirements. For example, a web site might have many option lists that are generated from tables in a database. Rather than building the option list on the fly every time a page is viewed , the lists can be generated by the pooled component when it is instantiated. Since pooled components maintain state, the options lists that it maintains can then be retrieved by any web page that needs to display a list. The expensive initialization, in this case querying the database and building option lists, only happens once per object, when it is instantiated by COM+.

Note that even though pooled components maintain their state, you cannot simply import all of your legacy COM components into COM+ as pooled components and expect them to work properly. During multiple method invocations there is no guarantee that you will receive a reference to the same object during each call.

Message Queuing

Special conditions may arise during the course of a program's execution. The database server may crash, or the user may attempt, purposefully or accidentally , to submit work from a disconnected terminal. Traditionally, developers have had to make special provisions in their application code to deal with these anomalies.

Now, the COM+ message queuing service will allow developers to avoid coding for disconnected situations. Briefly, the queuing service will record method calls from a client object to a server object that is unavailable, so that they can be played back to the server object when it once again comes online. The client code remains unaware that anything out of the ordinary has happened , and that COM+ Services is acting as an intermediary.

As you might imagine, message queuing comes in handy when you're designing applications that must run from both disconnected and connected machines. Also, message queuing is an integral part of Microsoft's new BizTalk Server, a new server program that can orchestrate how data moves through and between organizations. When you install Windows 2000 Server, message queuing is an option that you can install or leave out.

Component Load Balancing

Even with the benefits that object pooling and Just-In-Time activation provide for maximizing server resources, there may be times when one server machine just isn't strong enough to serve all of an application's clients . In such situations, developers can make use of COM+'s Component Load Balancing Service. This service distributes application objects out across a farm of co-operating web servers, so that no one server is overwhelmed by object requests and so that end users continue to enjoy smooth, consistent performance.

The crux of the Component Load Balancing strategy is the Component Load Balancing server, or the CLB. The CLB is a Windows Advanced Server or Windows Data Server machine that serves as a manager to the other servers in the farm. The CLB is in charge of distributing the object requests between the available servers.

The algorithm that the CLB server uses for picking object hosts is a sophisticated one. It proceeds in order down a list of available servers, handing creation requests to the first server that is available. Because this list is sorted from most robust to least robust server, stronger servers are more likely to host requests.

Once a connection is established between the client application and the server machine that the CLB has assigned to the client, communication proceeds between them without subsequent intervention by the CLB. Because there's no guarantee that the client's server object will continue to be hosted on the same server machine, components must be stateless, and object pooling is not available.