Component Tales: COM+ Services

[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]

Have you ever heard about Microsoft selling an application server? No? Well, this is because in Windows the application server is part of the operating system! It carries the inexpressive name “COM+ Services” and is located in the Software\System\Application Support node of the component catalog.

There are no settings related to this component and therefore, if you want to use it just adding it to the configuration is sufficient.

History

The former name of COM+ Services was “Microsoft Transaction Server”. This name explains a little bit better what COM+ Services were targeted at in the beginning. The first releases of this technology were able to provide a transactional runtime environment for application components based on Microsoft’s Component Object Model (COM) standard. In this environment components were able to participate in transactions across application and machine boundaries, leveraging Remote Procedure Calls (RPC) of the distributed COM (DCOM) technology.

Services

Over time the ability to have distributed transactions remained one of the features of the application server, while quite a few other functionalities were added to it.
Here are is an overview of the current state as provided in the MSDN library:

• COM+ Application Pooling
• COM+ Application Recycling
• COM+ Applications Running as NT Services
• COM+ Compensating Resource Manager
• COM+ Events
• COM+ Instrumentation
• COM+ Just-in-Time Activation
• COM+ Low-Memory Activation Gates
• COM+ Object Constructor Strings
• COM+ Object Pooling
• COM+ Partitions
• COM+ Queued Components
• COM+ Resource Dispenser Service
• COM+ Security
• COM+ Services Without Components
• COM+ Shared Property Manager
• COM+ SOAP Service
• COM+ Synchronization
• COM+ Transactions

This is a long list and therefore the name for the technology was changed in later releases to show that the focus lies not solely on transactions. If one looks deeper into the functionality provided by these services the scope is overwhelming. Therefore, let us pick some interesting ones from an embedded perspective for a brief overview:

· COM+ Transactions - are great to be used, if an application needs to provide data consistency while storing data in different places e.g. updating a song database and the corresponding file store e.g. in a multimedia application.

· COM+ SOAP Services - are able to turn plain COM components into real Web Services. This is a quite compelling approach to integrate (legacy) COM Applications into .NET Framework or web solutions.

· COM+ Object Constructor Strings – You want a safe, but configurable place to store a database connection string? Object Constructor Strings do have the means to provide this.

· COM+ Queued Components - are able to add robustness to an application by storing methods calls even when a requested component is currently not available.

COM+ Services in the .NET world

The arrival of the Internet showed limitations of the RPC communication standard and problems with registration requirements of COM (known as “Dll hell”) brought an end to the COM evolution. But, this does not mean that COM+ Services are dead. They are still hiding beneath the covers wrapped by the System.EnterpriseServices namespace!Because to this, it is not hard to access the very capable COM+ infrastructure from a managed application as shown in the snippet below.

The three required things are a reference set to the System.EnterpriseServices assembly, a transaction initiated by the declarative “[Transtaction]” statement above the method and, lastly, the class must be derived from ServicesComponent. If these prerequisites are met the managed application is, for example, able to create, take part or abort distributed transactions.

Impact on a Windows Embedded Standard image

Com+ Services are a part of the overall Windows infrastructure, which has not been developed with embedded requirements in mind. Therefor, the impact to a Windows Embedded Standard image is significant. The COM+ Services component pulls in additional infrastructure, such as the Distributed Transaction Coordinator (MSDTC), which overall adds up to 80 MBytes. Nevertheless, when you look at increasing compact flash sizes compared to falling prices for these storage devices and the functionality by including the services, overall there still may be a win for an embedded device.

On the other hand, if your embedded project does not use COM+ Services, it is easy enough to leave this infrastructure part out (which is not possible on a Windows desktop system), and save the footprint.

- Alexander

Alexander Wechsler

Wechsler Consulting

www.wechsler-consulting.de

Technorati Tags: XPe,Standard 2009,COM+