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

作者 Robert Bazinet 译者 陈黎夫 发布于 2007年9月18日

领域

语言 & 开发,

企业架构

主题

ESB ,

SOA Appliance ,

.NET ,

SOA平台 ,

SOA

标签

基于组件的架构 ,

业务架构 ,

微软 ,

SOA实施

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

• 更早的 >