VSLive! Speaker Interviews—Juval Lowy


Juval Lowy is a frequent VSLive! speaker and expert on .NET. As a preview of some of the great content at upcoming VSLive! Conferences, check out Juval's in-depth look at Enterprise services. Or better yet, register now for an upcoming event and experience this content in person!

Also, check out your chance to save with upcoming Early Bird Discounts at a conference near you!


What are Enterprise applications?
The term Enterprise application is overloaded. It means different things for different people. To most, it means an application with a large number of users, where scalability and throughput is a must. However, there are other possibilities: it can be an application with fewer users, but with drastic spikes in load, or an application with few users that use many expensive resources, or a combination of these. Applications that are mission critical, that have to operate 24x7, with zero down time are also Enterprise applications. Applications that deal with sensitive information are another type of Enterprise applications. Applications that have to interoperate with a wide range of platforms are another example. Finally, any application where quality and productivity are the top priority, are also Enterprise applications. In short, an Enterprise application is any application that is not a toy program.

What are .NET Enterprise Services?
.NET Enterprise Services are a set of component services designed to ease considerably developing Enterprise applications. .NET Enterprise Services are actually the result of integrating COM+ into .NET, and they offer a wide range of services essential for any Enterprise application, including object pooling, instance management, transactions, concurrency management, security, asynchronous, disconnected calls and loosely coupled events. Components that take advantage of these services are called Serviced Components, because they derive from the class ServicedComponent. You can configure the services using either special attributes in your code or the COM+ Component Services Explorer after deployment. For example, if you want .NET to maintain a pool of your objects, and have at least 3 objects in the pool, but not more than 10, you would write:

using System.EnterpriseServices;
[ObjectPooling(MinPoolSize = 3,MaxPoolSize = 10)]
public class MyComponent :ServicedComponent
{...}

You can also configure the pool parameters during deployment, using the Component Services Explorer. If you want Transaction support as well, you can use the Transaction attribute:
using System.EnterpriseServices;

[Transaction]
[ObjectPooling(MinPoolSize = 3,MaxPoolSize = 10)]
public class MyComponent :ServicedComponent
{...}

I thought COM and COM+ were deprecated
COM is deprecated. COM+ is probably the only piece of technology from the pre-.NET era that moved as-is into the world of .NET. COM+ is simply a poor name. COM+ is the second release of MTS (Microsoft Transaction Server). MTS too was a poor choice of a name for the services it offered. When MTS was first released in 1998, many developers thought that because they did not use transactions, they did not need MTS, and therefore they completely ignored all the other great services MTS offered, such as security and deployment. In Windows 2000, Microsoft integrated these component services with the operating system itself. Microsoft decided to call the second release of its component services suite COM+ (not MTS 2.0), so that every COM developer would think they need to use it, that maybe it is an advanced COM release. However, with the move to .NET, Microsoft has painted itself into a corner, because COM+ sounds way too COM-ish to be related to .NET. I actually suggested to Microsoft to call it .NET+, but they decided to rename it to Enterprise Services, which is a good (if not consistent) name.

What does Enterprise Services give me that basic .NET does not?
Enterprise Services offer a significant quality and productivity boost. Developers today still manage many aspects of their application such as object instances, transactions, concurrency, security, asynchronous calls, disconnected work, publishing and subscribing to events, application deployment and so on. These connectivity or "plumbing" issues have almost nothing to do with the functionality the end customer is paying for, and yet developers spend as much as 80% of their time on "plumbing" (and sometimes as high as 95%), instead of adding business value to their application. Not only that, but the majority of the bugs (and the time spent fixing them) are usually traced back to connectivity and plumbing defects, not to the business problem addressed by the application. .NET Enterprise Services can basically take care and manage these aspects of the application, and let the developers focus on implementing the business logic. You gain not only productivity and faster time to market, but also quality because Microsoft has done an excellent job in implementing these services, both in robustness and in performance.

I thought basic .NET has things like events, asynchronous calls, pooling, transactions, thread synchronization, security etc.
It does. However, each of the basic .NET services is limited or have some drawbacks compared with Enterprise Services. A few examples:

  • .NET Events support is certainly a step forward from COM connection points, because is eases the task of managing events and it off-shoulders from the developer the need to provide the mundane code for managing the list of subscribers. However, .NET delegate-based events still suffer from other drawbacks: The subscriber (or the client adding the subscription) must repeat the code for adding the subscription for every publisher object from which it wants to receive events. There is no way to subscribe to a type of event, and have the event delivered to the subscriber, regardless of who the publisher was. The publisher and the subscribers have coupled lifetimes — both publisher and subscriber have to be running at the same time. There is no way for a subscriber to say to .NET: "If any object fires this particular event, then please create an instance of me and let me handle it". Setting up connections has to be done programmatically. There is no administrative way for setting up connections between publishers and subscribers. .NET Enterprise Services offer a different event model which addresses these needs.

  • .NET built-in support for asynchronous method invocation standardizes asynchronous calls and saves developers a lot of error-prone plumbing code. However, there are other aspects of asynchronous calls essentials to Enterprise applications, such as disconnected work, error handling, auto-retry mechanism, and transaction support. .NET Enterprise Services has an advanced asynchronous invocation mechanism called Queued Components. Queued components use MSMQ to queue the call and transport it to the server component.

  • .NET provides automatic thread synchronization for context-bound objects, allowing them to share locks and reduce deadlocks. However, this synchronization is limited to threads in the same Application Domain (roughly the .NET equivalent of a process), and there are issues with reentrancy. In any case, it cannot share locks across app domains or machines. .NET Enterprise Services has an alternative mechanism that provides all that.

  • .NET has basic role-based security, but .NET definition of a role is a Windows user group. As a result, .NET basic role-based security model is only as granular as the user groups in the hosting domain. Often you do not have control over your end-customer's IT department. If you deploy your application in an environment where the user groups are coarse, or where the user groups do not map well to actual roles users play in your application, or if the group names are slightly different, then .NET basic role-based security is of little use to you. The Enterprise Services role-based security is in principal unrelated to Windows user groups, allowing you to define roles directly from the application's business domain, even if no corresponding user groups exist.

  • .NET has support for database connection pooling, but that pooling is of little use to you if the clients make infrequent use of the connection, but never return it to the pool. Enterprise Services have a way of returning the connection back to the pool when not in use, and just-in-time bringing it back when needed.

  • ADO .NET has support for transactions, by explicitly beginning one. It is very difficult to have multiple objects share that transactions, or access multiple databases all in the same transactions. Enterprise Services transactions make managing a distributed transaction as easy as a single object/single database case. In addition, Enterprise Services transactions can seamlessly enlist the database. Enterprise Services transactions are not limited to databases, and can use resources such as message queues.

How would you migrate existing COM-based COM+ applications to .NET?
Adopting a radically new technology such as .NET is never an easy endeavor for companies and developers. Most companies have considerable investments in existing code base and development skills. Unless companies have a compelling reason to move to .NET or a reasonable migration path, companies will avoid .NET. Because COM+ is .NET's component services, COM+ can offer such a migration path for companies and developers. Companies can start (or continue) their projects in COM, using COM+ as a supporting platform for Enterprise services, and then when the time comes to move to .NET, they start plugging into the same architecture .NET components, in a very seamless manner, reusing and interacting with their existing COM components.

What is next? Where is Enterprise Services heading?
Microsoft intends to re-implement COM+ in C#, to upgrade some of its internal plumbing issues. This will not affect developers using Enterprise Services today, because the attributes and the interfaces will remain the same. Microsoft keeps adding new services and capabilities to Enterprise Services. For example, in Windows XP, any serviced component can be exposes as a web service, even if it does not use the .NET basic web services facilities. This is an important benefit, because you can use the component internally today, and expose it as a web service when the need arises. It also allows you to incorporate legacy components in your new web-services based architecture.


Juval Lowy
Juval Lowy is a seasoned software architect and the principal of IDesign, a consulting and training company focused on .NET design and .NET migration. Juval is the author of COM and .NET Component Services (2001, by O'Reilly). Juval published regularity at Visual Studio and .NET magazines. Juval is a frequent speaker at the major international software development conferences. Juval chairs the program committee of the .NET California Bay Area User Group. Contact him at www.idesign.net