NServiceBus——让创建企业级.NET 系统更加容易

NServiceBus 是一个开源的通信框架，它能够帮助开发人员在搭建企业.NET 系统时避免很多典型的常见问题。同时，该框架也提供了一些可伸缩的关键特征，比如对发布 / 订阅的支持、集成的长时间工作流及深入的扩展能力等。据作者说，其本意是为构建分布式应用软件创建一个理想的基础设施。

NServiceBus 在 2006 年一月发行了第一个版本，随后在三月份就在一个大型的分布式系统中得到了应用。为此，InfoQ 特地找到机会和 NServiceBus 的原创者 Udi Dahan 进行了交流。

开发缘由：

开发 NServiceBus 的动力主要有两个。首先，我希望让开发人员在使用异步消息传递机制（无论是否使用 Web Service）时，能够以一种固定的方式编写其服务层。其次，我也希望能够定义一个支持发布 / 订阅语义的通讯 API 模式——这样无论传输接口是否支持发布 / 订阅，程序均可自由地进行移植。当然，避免使用集中的分发模块也非常重要，否则就无法实现良好的可伸缩性。最后，NServiceBus 还为长时间运行的工作流确定了一个确定的形式，并能够与异步消息传递连接起来。

对于使用 SOA 协议构建系统的开发人员来说，基于用 NServiceBus，而不是一些其它的技术或者所谓的“企业服务”框架的理由主要在于：

基于 NServiceBus 开发的系统将很难对其可伸缩性造成负面影响。因为异步消息传递模式的地位非常重要，所以开发人员将在大多数 Web Service 实现中都能潜意识地避免暂时耦合。而使用其它的技术则很难避免这类情况的发生，比如开发人员容易破坏系统的可伸缩型性和易用性——更为致命的是，这类失误只能在程序部署后才能被发现。 NServiceBus 的另一个独到之处就是它将所有的工作流代码完全地从技术实现中独立了出来。这样就让我们很容易地对工作流类做单元测试，进而允许关键业务流程的迭代开发。这些可移植的.NET POJO（Plain Old Java Object）让开发者可以根据实际需要灵活地选择工作流的运行平台。

我们注意到 NServiceBus 将能够配合 MSMQ 使用。之所以这样实现，Udi Dahan 给出了如下说明：

NServiceBus 的核心并不依赖于 MSMQ。NServiceBus 可扩展性允许我们插入自行编写的通信传送器,、订阅存储器和工作流的实现。我已经基于 MSMQ 实现了一个传送器，还有一个则借助了 WCF 的 NetTCP。开发人员既可以使用这些现有组件，也可以根据需要进行自定义。我们知道当前的许多 SOA 产品都与 HTTP 紧密耦合，因此 NServiceBus 的这种实现方式也将是个另辟蹊径的设计。 之所以选择使用 MSMQ，是因为它是微软公司的两大主流的通讯技术之一（另一个是 SQL Server Service Broker）。MSMQ 允许双方在离线的状态下进行通信，且它提供了一整套易于使用的 API，并已经集成到了.NET 框架中，这一点要比 Service Broker 好得多。我个人认为支持离线通信是任何 SOA 基础框架都必须考虑的关键部分——因为 Tenet of Service Autonomy 并不能保证当前通信的另一端处于可用状态。

NServiceBus 是一个开源的产品，基于 Creative Commons Attribution 3.0 License 发布。该框架已经被封装成数个.NET 程序集，允许在任何符合许可协议的应用程序或客户端中使用。

限于采访时间，我们最后则让 Udi 对那些不熟悉 SOA 或者想更多的了解 SOA 实现的读者说说他的想法：

如果你正在开发提供服务这一类型的应用程序，且还不熟悉 SOA 的话，你需要知道 SOA 和你到目前为止所做的事情有很大的区别——你无需再重复地书写类似的代码。与其在使用某项技术遇到困难时步履维艰，不如先花些时间理解高层的消息传递模式，以避免日后的返工。

Udi 在前不久也曾被 DotNetRocks 采访。采访内容包括 SOA 以及 NServiceBus 等。若想了解更多 Udi，你也可以访问他的Blog 。

查看英文原文： NServiceBus - Makes Building Enterprise .NET Systems Easier