编写软件基础结构的代码，是最有价值、最有意思、最具挑战性的工作之一。软件基础结构往往需要包括复杂的事务系统（包括分布式事务，甚至要包括事务补偿处理而不仅仅是简单的回滚操作）、足够的权限点粒度、基于角色的安全验证框架、透明地支持基于异步队列的互操作过程、自适应的线程模型、完整的过程和控制模型以及一个可以支持不同级别的间接调用（来自进程内、本地和远程的调用）的宿主环境等等。与此同时，我们的客户往往不希望看到我们把时间花费在这样的工作上，毕竟客户的业务并不直接体现在软件的基础结构中。甚至有人可能认为手工实现这样的框架结构意味着项目的失败，因为这样的基础结构理应有一种惯用的实现，而不是每次都由您自己手工编写。

这就是企业服务（Enterprise Services）的由来。它是微软的应用程序服务器提供的一种功能（主要是指COM+框架）。是的，微软并没有过多地谈论它们的操作系统与应用程序服务器之间的关系，但事实上，服务器版的Windows系统本质上就是应用程序服务器。注意，我们不是在讨论文件服务器或者是打印服务器。如今，Windows系统（甚至包括Windows CE）都已经内置了一些特别的部件，这些部件在别的平台上会被称为应用程序服务器，并且它们通常会被单独出售。

在Windows平台上，应用程序服务器部件并不是操作系统的主要组成部分。由于它们本质上就是Windows系统的一些免费的部件，所以你根本没有必要为它们的价格而担忧。它们都是现成的一些Windows常用部件而已。

不幸的是，这些年来我注意到只有少数开发者使用过这些标准化服务，并没有把它们当作应用程序架构的基础设施。大部分软件工程师仍然在用他们自己的代码来处理这些基础问题。很难说这样做就是不对的，毕竟这并不是什么难事。对于一个事务管理系统来说，有80%的部分是较容易实现的，但以我的经验看来，剩下的20%则非常难以实现，甚至近乎不可能做到。另外一方面，对于事务管理系统这样的基础设施，只有100%实现了所有特性后才能充分发挥它的价值。（否则，难道你愿意去客户那里解释，在某些特定的情形下，你建立的记账程序在没有报告错误的情况下也有丢失数据的可能？我想这绝对是个糟糕的体验。）同样，在安全性、可扩展性、队列组件等方面也一样，它们作为基础服务设施，必须100%完备才行。

也许你和我一样，大概也想通过简单而自然的方式学习新技术：到互联网上找一些示例，运行之，改进之，研究系统究竟是如何运作的，从而得到更深刻的理解，然后再继续研究，最终完全理解整个系统。不过，对于企业服务来说，你大概不能按照这样的路线来学习和开发。你可以创建你的第一个组件，然后标记为[assembly: Activation (ActivationMode.Server)]，你会注意到，与原先想象的不同，系统在后台做了很多的事情。

请允许我为它简单说几句：企业服务框架做得已经很好了，它为复杂的现实提供了非常简单的接口。一直以来，你经常需要处理分布式应用程序的复杂性。这不是企业服务框架的问题，事实上，这种复杂性来自于高可扩展性分布式应用程序本身——这又是另外一个复杂的话题。而高度抽象的企业服务框架同时也具备良好的易用性，这使你必须知道比表面更深的知识。这就是为什么这样的书籍如此重要的原因。

在.NET技术早期，我就已经认识Christian了。事实上，那时候.NET的名称还只是NGWS（Next Generation of Windows Services），而C#则还只是代号Cool。如今，Christian已经成了著名的作家、卓越的培训师和具备丰富实际经验的高级咨询顾问。他也是我很好的朋友，值得信赖的同事。在这个世界上，只有很少几个人能把企业服务解释得足够清楚，Christian就是其中之一。他能抽出时间来编写这本书，实乃广大开发者的福音。

Ingo Rammer
Vienna, Austria
http://www.thinktecture.com