Service Broker
这个是从sqlserver2005里加进来的一个东东，还是有点复杂的，最近弄了弄，做个记录吧。以后也不用去翻书查了。
先简说一下servicebroker是个什么东东。懒得写了，就直接把书里的一段话给摘过来吧：SQL Service Broker is one of the best recent features in SQL Server 2005 because it makes it
possible to write queuing and message-based applications. With Service Broker, database
developers can write asynchronous applications to communicate between databases or servers and
can easily build distributed, secure, and reliable applications.
简单来说，它就是个消息队列，并且可以用来写分布式的异步的应用程序。
ServiceBroker的结构：
这东西的建立还是有点复杂的，说具体东西前，先说下它基本构成：message type，然后是根据message type创建的contracts，接着是queue，最后是基于queue和contracts建立的service，以上的message type，contract，queue，还有service是service broker的基本构成。另外servicebroker是可以在同一个sqlserver实例上两个数据库间进行，也可以在两个sqlserver实例 间进行(当然这个的配置会比前者麻烦的多，但也只有这种的模式才更有意义)，所以实现servicebroker至少需要两个数据库，一个发起数据库，一 个目标数据库。
1. Service Broker概述
Service Broker（简称SSB）是基于数据库引擎提供的一个强大的异步编程模型，通过Service Broker，开发人员无需编写复杂的通信和消息程序，即可在数据库实例之间完成高效可靠的异步通信。
Service Broker具有如下特点：
数据库集成
完全基于数据库引擎，无需任何开发。对象和数据也存储于数据库中，可以应用标准的数据维护方法（例如备份/还原数据）。
自动激活
可以为接收消息的Service配置消息处理存储过程，当收到消息时，自动激活该存储过程处理收到的消息。
相关消息锁定
同一会话组的消息可以保证由同一个消息处理过程处理。这在处理如订单这类，可能包含订单主表、订单明细等多条消息的情况下非常有用
排序和协调消息
在传递大内容的消息时，Service Broker会自动分拆消息，并且在接收端自动组合消息，无需编写额外的代码来保证这些分拆后的消息能够按照正确的顺序还原
松耦合与工作负荷灵活性
消息发送和接收可以随时被中断，恢复时将自动恢复消息处理，在自动激活的消息处理中，可以设置并发的线程数，以控制消息处理的速度。消息传递可以通过多个路由到达目的端，也可以避免因为某部分网络或者服务器负载过重导致消息无法及时到达目的地。
Service Broker通常用于：
异步触发器
大规模批处理
可靠和异步处理
完整的Service Broker如图所示。包含三层架构：
Service Broker对象
位于用户数据库内。一个标准的Service Broker对象由Service（服务，是消息发送和接收处理接口、Queue（队列，存储发送和接收的消息）、Contract（约束，确定这个Service Broker对象可以处理的消息规则）、Message Type（消息类型，确定具体的消息结构）。
数据库级Service Broker对象
同一数据库内的Service Broker对象之间可以直接传递消息。如果要与其他数据库的Service Broker对象传递消息，则必须在数据库中创建路由（Route）来标识本数据库外的Service Broker对象（体现在用于接口的Service上）；如果Service Broker对象位于其他实例，则除了跌幅外，还可能需要创建用于身份验证的远程服务绑定（Remote Service Binding）。
服务器级Service Broker对象
当要与本实例外的Service Broker对象传递消息的时候，必须要在实例之间建立消息通道。实例级的Service Broker Endpoint用于完成此项工作，为了保证消息传输的安全性，还需要配置用于Service Broker Endpoint安全的相关对象。
图一
如果想了解有关Service Broker更为详细的信息，可以参考联机帮助：
http://msdn.microsoft.com/zh-cn/library/bb522893.aspx
如果想自己动手配置一下Service Broker，可以参考联机帮助上的教程：
http://msdn.microsoft.com/zh-cn/library/bb839489.aspx
2.关于Service Broker
SQL Server 2005中的新内容Service Broker，可用来建立以异步消息为基础的应用。Service Broker应用是一个或者多个程序的集合，能够完成一套相关的任务。为了更加深入的了解其涵义，让我们来看看组成应用的各个对象。
消息器
消息是Service Broker应用中信息传递的基本单元。在Service Broker内部，消息是按发送顺序进行接收,并且保证每个消息只会发送和接收一次。而且消息保证不会丢失。有时，某个消息已被发送，但是没有马上收到。当发生这种情况时，Service Broker会保存消息并尝试再次发送。消息带有确认信息以确保经他们传递的信息就是他们所等待接收饿。可以传递的消息最大可达2G。
会话
当消息在Service Broker应用中传递使使用会话（或者对话）方法。会话一般针对特别任务生成，当任务完成以后就会被删除。会话才是Service Broker最主要的信息交换结构，而不是消息。会话发生在两个服务端点之间：发起会话的服务(发起方)，以及接受会话需求的服务（目的方）。
队列
在Service Broker应用中，消息以队列方式保存等待接受处理。在内部，Service Broker队列是一种特殊的表格，能够通过指明队列名称的SELECT语句进行查看，不能在队列中执行INSERT, UPDATE, 或者DELETE语句。保存在队列中的消息即使重新启动服务器也不会丢失。
服务
服务程序是读取并处理队列中的消息的程序。这种服务可以是特定的存储程序，或者连接数据库的不同程序。每个服务必须与队列相关。正如先前所提到的，会话发生在服务之间。
会话组
会话组用来接连消息的处理过程并使之相互关联。每个会话是会话组中的一份子。主要的概念是有些消息与其他消息相关，会话组将这些相关的会话按照要求的顺序结合在一起。事实上，所进行的处理具有对会话组里的全部消息的高级连续访问权限，直到处理完成。
Service Broker 应用还有很多其他相关的部分。以上提到的各个部分在Service Broker起主要作用。您对它们越熟悉，您就会更熟练的掌握Service Broker应用的编写。现在，我们来看如何使用Service Broker应用来实现业务交易。
业务处理
业务流程中的任务很少按照同步进行。这些流程经常由彼此独立的任务组成，但是很可能同时发生，可能重叠，可能需要流程中别的步骤的支持。这种情况经常出现在生产产品的过程中，特别是客户订制的生产过程，比如汽车生产。
当有人预订一辆定制的汽车，汽车各个部件的生产过程并不彼此依赖。例如，这些部件可以同时生产。但是在最后阶段，当进行组装时你会遇到下面的问题：
·取决于前一步骤的步骤。
·如果出现错误会对整个项目的成功起绝对性影响的步骤。
·需要购买者补充信息的步骤。
除了这种情况以外，如果潜在购买者取消了订单，那么进行补偿的程序也要符合逻辑。您可能对有类似特征的业务流程比较熟悉。
当数据库执行这样的流程时，经常按一系列数据库交易进行处理，每个交易都有单独的基本任务。当其中一个数据库交易被接受或退回时，这一系列相关的业务交易通常都无法以此方法完成。这些交易必须被设计成失败时，通过逻辑判断退回业务交易。整个业务程序都很难进行，因为这些独立的交易实际上是于彼此相关的，他们都包含同样的总体目标。这是Service Broker这样的队列结构的实际价值所在。
在Service Broker应用中，目前的处理方法是可能的，也经常是人们所需要的。您能够以这种方法建立应用模式，使模式更符合业务流程。在我们定制的汽车行业的例子中，您能够以这样的方式设计应用，使得跟踪底盘的模块和跟踪引擎的模块能够同时出现。更好的，对这两个独立的零件的处理通过对话组可以相互联系。