email article printer friendly more resources

Build Serviced Components—the Right Way
Take advantage of these practical guidelines for implementing serviced components properly, and reduce coding and maintenance headaches now—and in the future.
by Francesco Balena and Giuseppe Dimauro

June 30, 2005

Technology Toolbox: VB.NET

Editor’s Note: This article is excerpted from Chapter 31, “Serviced Components,” of Francesco Balena and Giuseppe Dimauro’s book, Practical Guidelines and Best Practices for Microsoft Visual Basic and Microsoft Visual C# Developers, with permission from Microsoft Press [2005, ISBN: 0735621721, www.microsoft.com/learning/books/]. It has been edited for length and format to fit the magazine. You can read a PDF of the full chapter here.

Serviced components are Microsoft .NET Framework objects that run under Component Services and can leverage the full range of COM+ services, including Just In Time Activation (JITA), automatic transactions, synchronization, object pooling, role-based security (RBS), and programmatic security. You can run a serviced component as a library component (in the client’s process) or a server component (in a different process, possibly running on a different computer), even though a few COM+ services are available only in server libraries.

If you aren’t familiar with serviced components and their benefits, you can read the whole story on MSDN (see Additional Resources). If you have worked with serviced components already, we’re sure you’ll find some interesting tips in this article. Note that a couple code examples in this article assume that you have imported a pair of namespaces with the Imports (Visual Basic) statement: System.Data.SwlClient and System.EnterpriseServices.

It’s important that you consider carefully the pros and cons of using transactional serviced components to implement COM+ transactions as opposed to using standard ADO.NET transactions. Implementing transactions in serviced components (COM+ transactions) offers several advantages, including the support for distributed databases, a higher degree of independence from the database, and a cleaner object-oriented design (for example, you can use attributes to select the transaction isolation level). However, COM+ transactions use the Microsoft Distributed Transaction Coordinator (MS DTC). DTC-based transactions can be from 10 to 50 percent slower than ADO.NET transactions. When working with a single database server, you might decide to use ADO.NET transactions from inside a standard .NET class rather than encapsulating the database code in a serviced component.