COM+ Tutorial from Scratch: Part I

COM+ Tutorial from Scratch has two parts. Part I has basic concept of COM+ and its related topics. Part II will teach you how to use COM+ in real world applications.

This article is an extended version of my previous article " What COM+ exactly is?". This tutorial explains what is COM+ and how it works in real world applications. I have used Windows 2000 and VC++ 6.0.

Windows DNA is the first steps to understand COM+.

Windows DNA

To understand COM+, Windows DNA is the first thing to know about. Let's see what Windows DNA and its components are?

Windows DNA is a framework that describes how to develop multi-tier,  high performance, scalable, and distributed applications over the network. The goal of DNA is to provide enterprise level solutions which is suitable for any size. The heart of DNA is an integrated programming model based on COM+. In other words, Windows DNA is a way to provide an enterprise based solutions from Microsoft.

Windows DNA Architecture : Here is Windows DNA architecture:

Windows DNA consists of three layers

1. The Presentation Layer

This layer is responsible for information gathering from user, performing basic validation of user input, sending it to the business layer and again receiving results of the business layer and presenting these results to the user in a viewable formats such as VB forms. This layer consists tools such as VB, HTML, DHTML, Win32 applications, Client-Server scripting, Java Applets, Netscape Plug-Ins, ActiveX controls

2. The Business Layer

This layer is responsible for receiving input from the presentation layer, interacting with the data access layer to process the information and sending back the processed information to the presentation layer. This layer provides business rules and services to help to write scalable applications. These services are tightly integrated with each other and the underlying operating system and exposed in a unified way through COM. They include the following:

• Web services, through Microsoft Internet Information Server ( IIS ).
• Transaction and component services, through Microsoft Transaction Server ( MTS ).
• Queuing and asynchronous services, through Microsoft Message Queue Server ( MSMQ).
• Server-side scripting, via Active Server Pages (ASP).
  Interoperability services, such as the COM Transaction Integrator ( COMTI ) for accessing the IBM Customer Information Control System (CICS)   and IBM Infromation Management Systems (MIS).

3. The Data Access Layer

This layer directly interact with the data which usually reside in the databases such as SQL Server or Oracle. This layer is responsible for storage, retrieval, and general maintenance of data as well integrity of data. The Windows DNA approach of data access is called "Universal Data Access'. UDA is a set of system level and application level programming models called OLE-DB, ADO and RDO.

COM+: Definition

In 1992, Microsoft evolved OLE ( Object linking and embedding ) which was named as COM ( 1995 ) later with new enhancements and features. In 1996, COM started supporting distributing computing and Microsoft named it as DCOM ( Distributed COM). At the same time Microsoft developed one new transaction server called Microsoft Distributed Transaction Coordinator (MDTC) which was enhanced to Microsoft Transaction Server (MTS) in 1997. In 1997, Microsoft developed one more server for queuing services called Microsoft Message Queue Server ( MSMQ). Now what??? After all these development, In 1999, Microsoft combined all these services in an integrated runtime environment which is called COM+. In other words, COM+ is an integrated environment which provides developers  COM, MTS, MSMQ and some other services.

Is COM+ = COM + MTS?

What, exactly, is COM+? Is combination of COM and MTS COM+? If you see the evolution of COM+ from OLE then you can say "Yeah, COM+ = COM + MTS". But COM+ is more than that. COM+ is an extended version of COM with two major changes. First, it includes extended and updated version of MTS, MTS 3, and four major services including MSMQ, Load Balancing, Event Services, and IMDB. We will see all these services in more details later in this tutorial. These all components and services work together to provide an integrated enterprise solution, that's what COM+ is. So let's say this:

COM+ = COM + MTS ( update version) + COM+ Services

COM+ Catalog

Previous versions of Windows ( before 2000 ) used to have windows registry database to store information of COM components. Windows 2000 has a separate database for COM+ components, called COM+ Catalog. COM+ Catalog is an explorer way to interact with this database for developers. Besides GUI interface, it has some nice features such as securities etc. For example, you develop a component that supports load balancing. Some applications may want to use load balancing and some may not. You can indicate load balancing support by setting attributes by using COM+ explorer. Because of size problem of this article, I will write a separate article on COM+ Catalog. 

COM+ Components and Services

Let's see COM+ components and services now. Here is COM+ model :

Here is a detailed list of these components and services. In this article I would not discuss COM/DCOM and MTS parts because I will cover them in separate tutorials. I will discuss some MTS extended features such as JIT activation, Resource pooling and Role-based Security. Remaining part is COM+ services. That's what COM+ is all about besides COM and MTS. 

COM+ load balancing

First requirement of a distributed application is scalability. In other words, network traffic and number of clients shouldn't affect performance of an application ( which is impossible in reality though). Load balancing is a mechanism to distribute client calls to multiple servers. COM+ helps using two types of load balancing, called dynamic and static load balancing. In load balancing, client workload is distributed among network servers. COM+ supports load balancing on component level. When a client requests a specific component, it first connects to a load balancing router which contains the information about servers. This router then passes request to a server based on server load and availability. If server is available then client receives an instance of component on the server. The best thing is if a server goes down, COM+ automatically routes client request to another server. Windows 2000 has this service, called clustering service.

Ok, here is how load balancing works. When we create an instance of a remote server, we must have to pass remote machine name to access remote server ( component). This machine name is hard coded. Here is example:

To create an instance of a remote component, a client application must explicitly specify, either through the COSERVERINFO structure or via the RemoteServerName registry entry, the name of the machine on which to create the instance. This is shown in the following code snippet:

si.pwszName = L"RouterMachineName";
CoCreateInstanceEx( CLSID_MyComponent,
                    NULL,
                    CLSCTX_REMOTE_SERVER,
                    &si,
                  ... ); 

COM+ Catalog stores information about servers. When are request goes to a router, the router looks in the COM+ Catalog and works with the  SCM to route it to the appropriate machine. Once routed to a specific node in the application cluster, the remote object is created and the reference is passed directly back to the client. Once the instance is created, there is a direct connection between it and the client application.

COM+ IMDB

The IMDB is a robust, transient, and transacted database style cache that enhances the performance of distributed applications. IMDB uses OLE DB and ADO and provides fast access to database. Instead of loading data on runtime. IMDB stores database in physical memory as start up time.

COM+ object pooling

If you are using MTS support in your ATL/COM components then you might already have been used object pooling support provided by ATL/COM wizard. You will see how easy is to create an MTS component that supports object pooling using ATL/COM AppWizard.

Object pooling is a kind of recycling of objects. When a client releases an object that supports object pooling, instead of destroying that object completely, COM+ recycles it. When another client requests same object, COM+ gives an instance from recycle. Since these  set of component instances loaded in memory so that they are immediately available for use by client applications.

When you create a component using ATL/COM wizard which supports MTS and Object pooling, your interface is inherited with the IObjectControl interface. Ok, here is how to create a component with MTS and object pooling support.

• Use ATL/COM AppWizard and create a component called "myComponent" with MTS support.
• Insert New ATL object, Category : Objects, Object: MS Transaction Server
• Click Next, You will see ATL Object Properties Wizard. Give myMTSServer as short name in Names tab.
• In MTS tab, select dual interface and checked Support ObjectControl and CanBePooled.
• Click Ok.

That's it. Now your component will support MTS's object pooling. Piece of cake. huh? Now if you will examine CmyMTSServer class, looks like

class ATL_NO_VTABLE CmyMTSServer :
    public CComObjectRootEx<CComSingleThreadModel>,
    public CComCoClass<CmyMTSServer, &CLSID_myMTSServer>,
    public IObjectControl,
    public IDispatchImpl<ImyMTSServer, &IID_ImyMTSServer, &LIBID_MYCOMPONENNTLib>
{
}

CmyMTSServer class supports IObjectControl interface and has four methods. One constructor and three IObjectControl interface methods. When the component is instantiated within MTS, MTS provides activation and deactivation notifications through the IObject-Control interface. Here is declaration of IObjectcontrol:

interface IObjectControl : public IUnknown
{
   HRESULT Activate();     
   void Deactivate(); 
   BOOL CanBePooled();      
};
here is implementation :
HRESULT CmyMTSServer::Activate()
{
 HRESULT hr = GetObjectContext(&m_spObjectContext);
 if (SUCCEEDED(hr))
  return S_OK;
 return hr;
}
BOOL CmyMTSServer::CanBePooled()
{
 return TRUE;
}
void CmyMTSServer::Deactivate()
{
 m_spObjectContext.Release();
}  

After deactivating an instance, MTS calls CanBePooled() to see if the instance can be placed in a pool of objects standing ready for use by the next client request. Is it a good idea to develop a component with Object Pooling support? depends? I guess not always. I will discuss article "How to write COM components with MTS support?"..

COM+ Queued Components

COM+ supports this service using Miscorosft Message Queues Server(MSMQ). Using quesing services a client can easily execute method calls, even if that component is off line. MSMQ records and queues method calls automatically whenever the component is available. This service is useful for online applications which must be completed. For example, Online banking, air reservation system etc.

Here is one live example. Suppose there is a component on server which accepts online customer order. Client calls component's method OrderNow(). This code code creates an instance of an OrderServer component, sets some properties such as client number and order quantity, and then calls OrderNow(). The OrderNow() method takes the information, validates it, and probably creates a row in an Orders table in some database:

IOrderServer* pOrderServer = 0;
CoCreateInstance( CLSID_OrderServer,
                  ...
                  IID_IOrderServer,
                  (void**) &IOrderServer );

pOrderServer->Num_of_Customers(5 );
pOrderServer->Quantity( 10 );
lpOrderServer->OrderNow( &lOrderNumber );
pOrderServer->Release(); 

Here connection between client and server maintained until interface pointer is released. Here client assumes that the component is available. What if component is not available? In the case of COM+ Queued Components, client and components are not tightly coupled. Client submits a request to MSMQ's queue. MSMQ checks the availability of component and passes when it is available.

When the client instantiated a queued component, the runtime actually creates a local proxy object called a recorder. As the client makes method calls, the recorder proxy serializes the calls into an MSMQ message. When the client commits the object by releasing all references to it, the message is passed to the server via MSMQ. A special service running on the server then de-queues the messages and instantiated the component using another proxy called the player. The player interacts with the component as if it were the actual client by playing the stored method calls. If anything fails, the message is placed back into the queue, at which point you have several options based on the services provided by MSMQ.

COM+ events

In COM, events can be handled by using two techniques, either using interface callback mechanism where the client implements an interface described by the component. Events or notifications are then fired by calling through the client’s interface. for example, here Advise() and Unadvise() methods set up the connection:

// Our event interface
interface IMyEvents : IUnknown
{
   HRESULT SomethingHappened( BSTR bstrWhat );
}

// An interface on our component
interface ISomeInterface : IUnknown
{
   ...
   HRESULT Advise( IMyEvents* pIEvents );
   HRESULT Unadvise();
}
 
The second technique, called Connectable Objects, uses the standard COM IConnect-ionPoint interfaces. When two modules talk to each other, one provides information and other recieves information. In COM+, the module which provides information called "Publisher", and receiver called "Subscriber".

Here are some problems with COM which are resolved in COM+:

• The publisher and subscriber are tightly bound through compile-time knowledge of each other, the actual interface definitions.
• Adding publisher support for multi-casting or “fan-out” requires a lot of code.
• The architecture only describes a series of interfaces. As developers we still have to write the code to implement these interfaces.
• The connection point interfaces were developed without regard to distributed environments and are not efficient in those scenarios.

The COM+ Events model significantly upgrades the existing COM Event model. COM+ Events decouples the tight binding between the publisher and subscriber by introducing an intermediary object called the event class. Any entity that wants to publish information must do so through an event class object. The event class is created by interacting with the COM+ Events subsystem through the IEventClass interface, which is abbreviated below.

interface IEventClass : public IDispatch
{
   HRESULT put_EventClassID( BSTR bstrEventClassID );
   HRESULT put_EventClassName( BSTR
   bstrEventClassName );
   HRESULT put_FiringInterfaceID( BSTR
   bstrFiringInterfaceID );
   ...
}; 

An event class is a component implemented by the runtime that sits between the publisher and its subscribers. Because the event class actually implements the event interface, it looks like a subscriber to the publisher. When a publisher wants to fire an event, it creates an instance of the event class, calls the appropriate method, and can then release the interface. The runtime then determines how and when to notify any subscribers. As in the Queued Components case, the lifetimes of the publisher and subscribers have been decoupled. For this reason, all event interfaces are restricted to [in] only parameters.

Subscribing to an event is just as easy. The subscriber registers with the COM+ Events service by creating a subscription object, again through the help of the runtime and the IEventSubscription interface. Once created, the subscriber registers the subscription with COM+. The component will be notified as events are published.

In short, this new event system:

• Provides a publish-subscribe scenario that decouples the entity lifecycles.
• Adds an activation model to the event system. If a subscriber is not active when an event occurs, the event runtime can activate the subscriber and pass it the event information.
• Provides a “third-party” publish-subscribe environment. Once an event class is created, anyone can become a publisher or subscriber of the events (based on security issues, of course).
• Supports a rich filter mechanism. By writing filter objects, you can filter at the publisher level, which is very efficient, or at the subscriber level.

Just-In-Time Activation

In COM+ when a client makes a call to an object to create an instance, COM+ provides that client a reference context to that client instead of reference to the object. Client gets reference to the object when client calls a method of that object. This technique is called Just-In-Time activation. Why JIT? That's good question. Let's say you have thousands of clients want to call ( want to instantiate ) one component but only few of them actually want to call methods of that component. In this case, its a big overhead to create instances of that component for each client.

IObjectContext is the interface which provides context object of a an interface.

Role-Based Security

COM+ ( Windows 2000 ) supports Role-Based security. Role-based security is you can assign different permissions for different users or groups on a component. For example, you can make a component which will let project manager read, write, or change specs of a project while programmers can only read the specs. This all you can set either by using COM+ Explorer or via programming.