深入了解组成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应用中，目前的处理方法是可能的，也经常是人们所需要的。您能够以这种方法建立应用模式，使模式更符合业务流程。在我们定制的汽车行业的例子中，您能够以这样的方式设计应用，使得跟踪底盘的模块和跟踪引擎的模块能够同时出现。更好的，对这两个独立的零件的处理通过对话组可以相互联系。