在设计Enterprise Services时建构者犯的最大的错误之一就是假设它的目的就是为现有的未被管理化的COM+和MTS功能提供包装。这是一个普遍的假设，在现有的Enterprise
Services只对未管理化的COM+提供了一个管理化的界面的情况下。
然而，微软公司则对Enterprise Services持不同的看法。在他们的眼中，Enterprise Services是COM+和MTS的替代品。微软公司对于新版本的.NET Framework有两个主要的目标，从Windows .NET Server 2003的1.1版本开始：第一，所有现有的COM+功能都将转换成为管理化代码；第二，所有新的分布式系统管理功能都将在.NET的Enterprise Services之中实现。事实上，COM+ 1.5版本（与Windows XP一起发行）将很可能是COM+的最后一个未管理化的版本。
微软公司对Enterprise Services作为它的分布式系统开发平台十分重视，所以你要了解清楚微软指的是什么服务。Enterprise Services支持分布式环境下的资源管理，这个功能包括对分布式处理，基于任务的安全问题和对象包装，对象pooling，即时激活(JITA)，队列部件和松耦合事件等的支持。当共同使用这些功能时。就可以实现一个完整的服务器应用软件处理模型。
Enterprise Services中最令人困惑的部分就是什么时候使用他们。如果你现有的系统广泛地使用COM+，在将你的应用软件导向.NET时，你会很自然地想要使用Enterprise Services。但是如果你现在不使用COM+，你将如何开始，从何处获利？
要了解你如何开始你的Enterprise Services，让我们来看一看你需要如何在三种不同的情况下实现处理支持：传统的分布式应用软件，Web服务和ASP.NET应用软件。对开发者在COM+之中和.NET之中如何进行处理作出区分是十分重要的。在COM+之中，开发者人工地开始一个处理过程并核查条件以确定此处理过程是否应该继续还是终止，但是.NET可以通过使用属性中的显露声明来自动地确定处理的继续和终止。换句话说，你可以认为.NET中的分布式处理是自动的或声明式的处理过程（开发者仍然可以在需要的情况下人工地选择继续还是终止）。
对于一个传统分布式应用软件来说，开发者需要创建一个服务器对象然后对客户机编码来调用这个服务器对象。这里是一个C# 中的服务器对象的简单实现：
using System;
using System.EnterpriseServices;
[assembly : ApplicationName("TxDemo")]
[Transaction]
public class Account : ServicedComponent {
[AutoComplete]
public void Credit() {
// do some work
} }
在这个例子中我们应该注意三点。第一，using System.EnterpriseServices声明，使你可以对Enterprise Services名称空间的属性进行访问。第二，Account类从现有的ServicedComponent类作继承，它获得了可以被Enterprise Services管理的能力。最后，Transaction和AutoComplete属性从这个类处理中使得对象得到例示。AutoComplete属性在Credit函数中告知Enterprise
Services来继续进行工作，除非出现错误时，这样工作将被终止。你还可以通过AutoComplete执行处理过程来找出例外情况并抑制他们的发生（例如并不把它放置到调用堆栈中）。
这里是在客户机应用软件中使用Credit对象时所需要的代码：
public Class AccountClient {
private void Transactions_Click() {
Account account = New Account();
order.Credit()
} }
注意客户机并不知道服务器对象使用处理管理。
