NServiceBus

NServiceBus是dotnet世界里面最流行的开源企业服务总线.  它具有以下特点: 
     1.强大,轻量级 
     2.可插拨,简单易用 
     3.支持企业级开发 
    零安装，在五分钟内就可以实现订阅/发布,如果你正在使用WCF,BizTalk，WebSphere or Sonic，你应该考虑一下NServiceBus: 
     1.NServiceBus and WCF 
     2.NServiceBus and BizTalk 
     3.NServiceBus and WebSphere/Sonic 
     NServiceBus开始于2006年，并且一直在持续的改进，而且社区很活跃，作者更新的也很快.而且NServiceBus已经被多个大公司应用到正式的实际生产项目中，还是经受过正式项目的考验的，在这里可以查看一下NServiceBus的性能。 
     现在NserviceBus将要发布2.0版本，开发使用起来相当友好和方便，插拨性相当强，甚至连容器都可以替换。 
     Learn more about NServiceBus...  
     官方地址:http://www.nservicebus.com/

     相关的资源 
     1.NServiceBus——让创建企业级.NET系统更加容易   
     2.NService yahoo group 
     3.官方文档

NServiceBus 是 .NET 平台上最受欢迎的一个开源 ESB 框架。有较完善的文档及示例代码。

目前，.NET 平台上开源的 ESB 框架，大多基于消息队列来实现。NServiceBus 同样也使用消息队列机制来实现消息的传递，例如可以使用 MSMQ。由于消息队列天生就是异步传输的，所以 NSB 也同样只支持异步消息，是一种‘发送即忘却’的模式。（As a general purpose communications technology, WCF does not enforce the queued messaging paradigm. NServiceBus does, and the architectural implications are profound.）。

NServiceBus 相对于 WCF 的优势在于：事件驱动的架构（发布、订阅）、更好地支持长时间运行的工作流。

缺点一：只支持异步的消息机制的问题是，无法进行传统的的数据查询。（To allow clients to perform queries, it is best not to use NServiceBus. Messaging is designed for non-blocking operations, and queries are (for the most part) operations for which the user wishes to wait.）

如果一定要使用 NSB 来实现数据查询，那么只能通过 CQRS 来进行系统的设计：

缺点二：NSB 的服务可以轻易集成到 WCF 中使用 MSMQ 实现，但是反之则不行。也就是说，已经使用 WCF 开发的服务，是无法使用 NSB 来完成简单的迁移的。（原因也主要是因为 NSB 的异步机制。）

相关资源：

infoq 官方采访介绍：NServiceBus——让创建企业级.NET系统更加容易

NServiceBus---最流行的开源企业服务总线 for .Net

NServiceBus 开源通讯框架（几种通信模式）

NServiceBus 安装与调试

NServiceBus Overview

NServiceBus And WCF

简单DEMO

=======================================================================================================

【笔记】学习NServicbus

NserviceBus的配置相关：（从官网翻译的）
=====================================================
NServicebus的配置
 1.MsmqtransportConfig,这个配置定义了一些消息在传输过程当中的属性。
    例如，发送消息要开启几个队列；以及最大的重试次数(发送消息失败之后会重试继续发几次？)。这个配置默认是没有的，我们需要在<configsections>里面配置。
<section name="MsmqTransportConfig" type="NServiceBus.Config.MsmqTransportConfig, NServiceBus.Core" />
 <MsmqTransportConfig NumberOfWorkerThreads="1" MaxRetries="5"/>这个配置里面的两个属性
maxretries表示消息处理失败在移交到errorqueue之前会重试几次。这个值如果没有提供的话，默认就为5.
 2.MessageForwardingInCaseOfFaultConfig.这个配置主要是定义消息无法处理的时候或者处理失败的时候将把消息移交到哪里(那个消息队列)去。一般默认的是移交到本机名字叫error的消息队列里，但是我们也可以把这个处理失败的消息移交到远程服务器的消息队列里去。如过是本机消息队列的话一般是这么配置<MessgaeForwardinginCaseOfFaultConfig ErrorQueue="error">（这表示消息处理失败的时候将把消息移到本机的error消息队列里。）如果是远程的话，errorQueue的值一般这么配置，都是基于"queueName@remoteMachineName"这个模板的。就是"消息队列名称@机器名称"。
      如果你没有定义或者配置错误队列的地址，那么NServicebus将启动失败，并且报“Could not find backup configuration section 'MsmqTransportConfig' in order to locate the error queue“的异常。
=====================================================
NServicebus的异常处理：
     NServiceBus自带了一套异常处理机制，你不需要自己去捕获或者处理异常。当异常出现的时候你只需要把异常抛出，当NServiceBus捕获到异常之后，他会自动的去重试处理这个消息5次(这个次数是自定义的)，如果5次之后还没有处理成功，就会把这个消息转移到error队列里了。这样我们就可以关注error队列，一旦这个里面有了消息，则表示有处理失败的消息了。我们可以针对error队列里的消息进行单独的处理。另外我们也可以利用工具 ReturnToSourceQueue.exe，这个工具可以把error队列的消息遣送回到它原先的队列里去，让队列再处理一遍。

【笔记】NServiceBus-作为接口的消息

1.发送消息的时候尽量使用类

发送命令(消息)的时候建议使用类而不是接口，因为这样的话你可以在类的构造函数里面写一些你的判断逻辑了，这样也不容易导致你发送无效的消息到客户端；

2.接受消息的时候尽量使用接口(消息的event或者叫消息类型)

　　a>由于接受到的消息(服务端发过来的)都是以前发生过的事情了(意思就是之前发送的时候已经验证过了)，所以接受的时候不需要太多的验证；

　　b>另一个使用接口的原因就是接口的易扩展性和多重继承的优势；这是接口非常实用的一个特征，可以让我们在升级系统的时候不会影响到消息的订阅者；

　　c>例如你在1版本中有一个消息的事件a，你到2版本的时候想加一个事件b，这个时候你可以让b继承Ib以及Ia（继承a的接口和b的新写的接口），这样就不会影响到a订阅者的使用。

　　　　另外，如果你有一个class Test:Ia,Ib,Ic  当你发送了一个Test类型的消息之后，订阅Ia,Ib,Ic三个事件的客户端都会收到这个消息。

　　　　这一点是类所做不到的。

【笔记】学习NServiceBus-如何定义你的输入队列的名称？

我最近学习NServicebus，没有章节，我只是部分一部分的在官网看的，觉得好的有意义的就看看，并且记录下来。所以，你会发现我每一次记录都不太连贯。

NServicebus是一个很强大的东西，我也只是看了我工作当中用到的那部分，并且在这也只是记录一下。请勿拍砖，请多指教。

------------------------------------------------------------------------------------------------------------------

NServicebus允许其他技术的节点除了MSMQ(我也不懂这句是什么意思)。

下面就让我们一个一个来看：

　　

　　1.如果用户没有指定实现了这个接口IConfigureThisEndpoint的命名空间，那么NServicebus在运行时会采用NServicebus的主机做为默认的命名空间。

　　　NServiceBus推荐把配置文件放到你的项目的根目录，并且endpoint跟你的项目名称取一样那个的。

　　

　　2.如果在调用NServiceBus.Configure.With()方法的时候没有定义自己的命名空间，如果你的项目是web项目的花，global.asax.cs的命名空间将可能是你的全局命名空间。

　　3.你可以设置终结点名称使用EndpointName属性，在MessageEndpointMappings上。

　　4.你可以写一个类实现INameThisEndpoint接口，通常这个类的名称叫EndpointConfig。

　　5.如果在安装服务的时候为服务指定了一个显示名称，如果你没有指定endpoint，那么这个显示名称就会成为你的默认endpoint。

　　6.在安装的时候你可以指定一个endpoint名称，以这种方式/serviceName:"MyEndpoint".

你能看到有好多种方式定义你的endpoint，如果上面的方法都满足不了你的需求，那么你可以Configure.DefineEndpointName(()=>{})定义你自己的规则.