博客园_wengmj's blog

SQL Server 2005 Service Broker

2011-12-26T15:57:00Z

SQL Server 2005 Service Broker

SQL Server 2005

发布日期 : 11/4/2004 | 更新日期 : 11/4/2004

Roger Wolter

适用于：

Microsoft SQL Server 2005

Transact SQL (T-SQL) 语言

摘要：本文概述了如何利用 SQL Server 2005 中新增的 Service Broker 功能，加快并简化基于异步排队操作的 SQL Server 应用程序的开发过程。（请注意，在示例文件中，程序员的注释使用的是英文，本文中将其译为中文是为了便于读者理解。）

本页内容

引言
 为什么排队应用程序难于编写？
为什么要在数据库中进行消息传送？
Service Broker 编程
 Service Broker“Hello World”
示例
 结论

引言
SQL Server 2005 的一个主要成就是可以实现可靠、可扩展且功能完善的数据库应用程序。与 .NET Framework 2.0 公共语言运行库 (CLR) 的集成使开发人员可以将重要的业务逻辑与存储过程合并，而 T-SQL 和 XML 中的新增功能扩展了数据操作的可用范围以及开发人员可用的存储功能。另一个重要功能是 SQL Server Service Broker，它为数据库应用程序增加了可靠、可扩展、分布式异步功能。

为什么要编写异步排队操作？
在开发 SQL Server 2005 时，我们与成功开发过大型可扩展数据库应用程序的人员进行了交谈。结果发现他们几乎所有的应用程序中都有一个或多个操作是以异步排队方式执行的。股票交易系统中的结算活动是排队的，这样可以在后台进行结算，在前端处理其他交易。订单输入系统中的发货信息放在一个排队中，稍后将由另一台服务器（通常位于其他位置）上运行的发货系统读取。旅行预订系统在客户填写完路线后再进行实际的预订，并在预订完成后发送确认电子邮件。在所有这些示例中，许多工作都是通过异步方式完成的，从而提高了系统的响应速度，因此用户无须等待工作完成就可以收到响应。
在大多数大型系统中，经过仔细分析后都可以发现，许多处理都可以通过异步方式完成。虽然应用程序中的排队任务无须立即完成，但系统必须确保这些任务能够可靠地完成。Service Broker 使异步排队任务的执行可靠并且易于实现。
使应用程序中的部分任务异步执行的另一个优势是这些任务的处理工作可以在资源可用时完成。如果订单输入系统中的发货任务可以从队列中执行，发货系统就无需具有处理峰值订单负载的能力。在许多订单输入系统中，峰值订单率可能是平均订单率的两倍或三倍。由于订单输入系统必须具有处理峰值负载的能力，因此大量处理能力在很大一部分时间内都处于闲置状态。如果在出现峰值时对异步任务进行排队并在空闲时执行，将显著提高系统的利用率。
返回页首

为什么排队应用程序难于编写？
既然异步排队应用程序具有许多优势，为什么不以这种方式编写所有应用程序？这是因为编写异步排队应用程序相当困难！许多尝试在应用程序中使用数据库表作为队列的开发人员发现，实际操作远比想象的困难。作为队列的表中包含多个进程，包括同时插入、读取和删除几条记录。这将带来并发问题、降低系统性能并导致频繁死机。尽管许多开发人员都成功地解决了这些难题，但实际操作却非常困难。Service Broker 通过使队列成为 SQL Server 2005 数据库中的第一级数据库对象解决了这些问题。编写队列的大多数难题都已解决，因此开发人员可以专注于编写异步应用程序，而不是编写排队基础结构。本文的其余内容将讨论编写排队应用程序涉及到的难题，并解释 Service Broker 如何帮助您解决这些难题。

消息的完整性
在许多异步排队应用程序中，排队的消息实际上是有价值的业务对象。例如在订单输入系统中，如果将发货信息放入队列中以便稍后处理，那么丢失排队的数据将意味着无法按订单发货。许多可靠的消息传送系统都将消息存储在文件系统中，因此磁盘驱动器的损坏将导致消息丢失。Service Broker 将消息存储在隐藏的数据库表中，因此 SQL Server 为保护数据而提供的所有数据完整性功能同样可用于保护排队的消息。如果使用数据库镜像进行故障恢复，当因数据库故障而转移到第二个数据库后，所有消息都会转移到第二个数据库中，这样 Service Broker 应用程序将继续运行而不会丢失任何数据。

多读取器队列
多读取器队列是一种扩展异步应用程序的最有效的方式。为证明这一点，我将通过大家都熟悉的两个示例说明如何进行排队。

在杂货店排队
大多数杂货店都可以增设多个队列。每个收银台都有其自己的队列，因此要购买某些商品，您需要选择一个队列。如果您像我一样，大多数时候选择的队列中都有一个满载而归的顾客排在您前面，他/她购买的很多商品都需要核实价格，而且要使用第三方远期支票进行付款。在轮到您结帐之前，可能在您开始排队时还没有出门的顾客都已经为他们购买的商品付完了款。这个例子说明了使用多个队列时的一个问题：即，如果排在前面的任务需要很长时间才能处理完，后面的任务将无法得到及时处理。
使用多个队列的另一个主要问题是，添加一个队列后需要在各队列之间重新分配任务，在队列之前来回移动任务可能会浪费很多时间。还以上面的杂货店为例，当一个新的收银台开始工作时，想象一下许多顾客推着购物车蜂拥而至的场面吧。

在机场排队
虽然航空公司并非高效率的典范，但大多数售票点的工作效率都比杂货店要高，这是因为多个票务代理都在为一个队列服务。由于只有一个队列，因此您不必担心排错了队。如果某个乘客占用了较长的时间，其他票务代理仍可以继续为其他乘客服务（假定有多个票务代理）。
具有多个读取器的一个队列也可以轻松扩展。如果队列太长，可以增加代理而不必打断队列。某些代理也可以在接待完当前乘客后离开，而不会在队列中造成混乱。
尽管可能会偏离主题，但我们仍以机场队列为例来说明基于队列的应用程序的另一个常见问题。假定排在一个队列中的几个人属于一个团队，比如说，我和我的家人正在登记准备去旅行。再假定我的家人由于到达时间不同而分散排在一个队列中。如果我们希望坐在一起，那么代理将需要预留一排坐位。如果我和妻子同时来到不同的票务代理处，则我可能预订了第 4 排的 5 个座位，而我的妻子预订了第 47 排的 5 个座位。这是多读取器队列的一个主要问题：即，如果在不同的线程中同时处理相关的消息，将很难进行协调。请想象一下同时处理订单标题和订单内容的情景。处理订单内容的读取器会认为没有相关的订单标题，因为订单标题还未读入数据库。为了正确工作，订单内容必须多次重新查找订单标题，以确保订单标题只是被延迟而不是不存在。
一种更简单的方法是让第一个到达售票处的乘客将所有相关乘客都叫到前面来，以便由一个售票处为所有这些乘客提供服务。 Service Broker 的功能与此类似，它在接收到一条消息后锁定相关的其他消息。持有锁定的读取器可以接收队列中属于同一组的所有其他消息，而其他读取器都不能读取这些消息。在提交事务之前，消息将一直保持锁定状态。该锁定称为“会话组”锁定。会话组是开发人员定义的相关消息组。例如，处理特定订单所需的所有对话（订单标题、订单内容、库存、发货、帐单等等）可能被放入同一个会话组中。从其中一个会话读取消息时，将锁定会话组中的其他消息，这样只有持有锁定的读取器可以处理队列中的所有相关消息。请注意，只锁定一个组中的消息，这一点非常重要。尽管可以同时处理上百个组，但任一时刻一个线程只处理一个组。在提交或回滚线程创建的事务之前，组将一直处于锁定状态。
我想通过这个例子说明的最后一个问题是，当持有会话组的事务被提交后，该会话组中的另一条消息到达时会发生什么情况。还以售票处为例，当我的家人都登记后，我的一个孩子才到达机场。由于原始事务已经结束，最后一位乘客可以由任一票务代理服务。只有在原始代理留下便条，说明该组中其他人员的位置时，新代理才能知道如何为最后一位乘客安排座位。同样，当处理相关消息组的事务完成时，必须记录会话的“状态”以便当该组中下一条消息到达时，接收该消息的队列读取器了解上一个事务停止时的位置。因为这是数据库应用程序，所以存储该状态的位置应该是一张数据库表。Service Broker 提供了一个会话组 ID，可以使用它来方便地将会话状态和会话中的消息相关联。这是与会话组中每条消息一起显示的唯一标识符。如果唯一标识符用作存储状态的表中的密钥，则消息处理逻辑可以很容易地找到与接收到的每条消息相关联的状态。另外，因为每次只有一个队列读取器可以处理来自特定会话组的消息，所以开发人员不必担心同时有两个事务更新状态行从而导致丢失状态信息。
以上示例说明，多读取器队列是扩展大型应用程序的一种简单而有效的方法。Service Broker 提供的会话组锁定机制使编写使用多读取器队列的应用程序像编写使用单读取器队列的应用程序一样容易。

分布
前面讨论的队列都假定位于一个数据库中。为了开发适用于多种业务情况的松散耦合的分布式数据库应用程序，我们需要进行扩展，以包括分散在网络中（通过可靠的消息传送进行通信）的多个数据库中的队列。我们需要可靠的消息传送，因为如果使用数据库确保队列中消息的完整性，但消息却在传送到其他数据库的过程中丢失，所有工作都将是徒劳的。
Service Broker 使用称为“对话协议”的可靠消息传送协议来确保发送到远程队列的消息按顺序到达并且仅到达一次。正如对话是双向会话一样，对话协议同时支持双向的消息传送。
对话消息具有标题，可确保消息按正确顺序安全地传送到正确的目标位置。它包含序列号、消息所在对话的标识符、要发送到的服务的名称、安全性信息以及用于控制消息传送的一些其他信息。当目标位置成功接收到消息后，它将发出确认，以便源位置知道已成功传送了消息。如果可能，确认信息将包含在另一条消息的标题中发送回源位置，以尽可能减小消息的数量。如果源位置在某一时限内没有收到确认，将重新发送该消息直到成功传送。
消息传送系统在传送较大的消息时经常会遇到问题。发送以 GB 为单位的消息会花几分钟时间，从而会占用一段时间的网络连接。如果发生网络错误导致重新发送消息多次，将会严重影响网络性能。为了解决此问题，Service Broker 对话协议将大型消息拆分成多个较小的片段，然后再单独发送每个片段。如果发生网络错误导致重新发送，则只重新发送传送失败的消息片断。因此，Service Broker 最大可以支持 2GB 的消息，而许多可靠的消息传送系统只能发送 100MB 或更小的消息。

事务性消息传送
“仅一次”消息处理需要使用事务性消息。为了说明此问题，假定某个应用程序在处理消息的过程中发生了错误。当应用程序重新启动时，它如何才能知道是否要处理发生错误时正在处理的消息呢？数据库中可能已经更新了消息处理的结果，因此重新处理消息可能产生重复的数据。唯一安全的处理方式是使接收消息成为更新数据库的同一事务的一部分。在系统崩溃时数据库更新和消息接收都回滚，因此数据库和消息队列的状态与系统崩溃前的状态相同。
因为所有 Service Broker 操作都在数据库事务环境中发生，所以保证了消息传送操作的事务完整性。典型的 Service Broker 消息处理事务包括以下步骤：
开始事务。
从会话组中接收一条或多条消息。
从状态表中检索会话的状态。
处理消息并根据消息内容对应用程序数据进行一项或多项更新。
发送一些 Service Broker 消息：即，将响应发送到传入的消息或将消息发送到处理传入消息所需的其他服务。
如果此会话组包含其他消息，则读取和处理此会话组中的其他消息。
使用新的会话状态更新会话状态表。
提交事务
Service Broker 事务性消息传送的一项重要功能是在任何时间如果崩溃或应用程序发生错误，事务将回滚并且一切都返回到事务开始时的状态，即状态不变、应用程序数据不变、消息未发送并且接收的消息返回到队列中。这使此类应用程序中的错误处理非常简单。

队列读取器管理
在 Service Broker 应用程序的消息处理过程中，队列读取器首先从队列接收消息。由于消息始终从队列中拉出，因此在消息到达队列时接收应用程序必须正在运行。许多异步消息应用程序都面临着一个问题，即如何确保队列读取器在需要时处于运行状态？有两种传统的方法：让队列读取器成为连续运行的服务，或者使用触发器，在每条消息到达时，都将触发消息传送系统。Windows NT 服务方法是指即使在不处理消息时也运行应用程序。由于队列读取器频繁开始和停止，触发器方法可能会遇到性能问题。
Service Broker 采用称为激活的中间状态方法来管理队列读取器。为设置激活，DBA 将存储过程与 Service Broker 队列相关联。当第一条消息到达队列时，激活逻辑将启动指定的存储过程。存储过程负责接收和处理消息，直到队列为空。队列为空后，存储过程可以终止以节省资源。
如果 Service Broker 确定消息添加到队列的速度比存储过程能够处理的速度快，激活逻辑将开始其他的存储过程，直到存储过程能够处理传入的消息或者达到了为队列配置的存储过程的最大数量。由于为队列提供服务的队列读取器数量随着传入消息速率的更改增大或减小，因此所有时间都将运行适当数量的队列读取器。
返回页首

为什么要在数据库中进行消息传送？
关于 Service Broker 的一个常见问题是“为什么要将消息传送功能内置在数据库中？数据库外部难道没有足够可靠的消息传送系统？”
我希望前面的信息已经说明了为什么要在数据库引擎中内置 Service Broker，下面提供了要在数据库中传送消息的一些其他理由：
消息和数据的单客户端连接。除了上一部分中提到的统一编程模型，还具有一些其他显著的优势：
当在任何可以连接到数据库的客户端上运行时，应用程序可以通过事务接收消息。当接收程序与队列在同一计算机上运行时，许多消息传送系统只允许事务性接收。
与在数据库中不存储消息的消息系统不同，事务性消息传送不需要分布式事务或两阶段提交。
数据和消息之间集成的管理、部署和操作。用于保护和管理数据库数据的所有工具和技术同样适用于消息：
备份和恢复数据库还可以备份和恢复消息队列。
如果使用群集或数据库镜像来保护数据库以避免出现故障，则您的消息享有相同的保护。
由于队列具有相关的视图，因此确定队列中的操作非常简单。要了解队列中有多少条消息吗？请从队列中选择 **count(*)。要了解有多少条消息尚未传送吗？请从sys.transmission_queue** 中选择 *。如果消息中包含 XML 数据，则可以使用 XQuery 进行搜索。可以使队列中的消息与状态信息甚至数据表相结合，以确定订单输入系统中特定订单的完成状态。
将消息传送功能内置在数据库中还有一些显著的性能优势。
正如前面所述，事务性消息不要求两阶段提交。
消息更新、状态更改和数据更新都记录在同一事务日志中，因此在提交事务时只需写入单个日志。
可靠的消息传送通常将消息从传送队列传送到接收队列。如果 Service Broker 检测到接收队列与传送队列位于同一数据库实例中，则消息直接放入接收队列中，从而节省了额外的输入/输出并减少了事务提交的次数。
返回页首

Service Broker 编程
Service Broker 功能通过 SQL Server 中的新对象启用，这些新对象可以由一组 T-SQL 扩展来创建和操作。为了数据库程序员的方便，使用了他们熟悉的用于配置其他数据库对象的 CREATE、ALTER 和 DROP DDL 语句来配置 Service Broker 应用程序。用于创建 Service Broker 对话以及在对话中发送和接收消息的命令是 Transact SQL 语言的 DML 扩展。接收命令的语法与选择命令相似，它返回包含消息的行集，就像选择命令返回包含行的行集一样。熟悉 Transact SQL 编程的开发人员会发现学习 Service Broker 编程非常容易。用于为 Service Broker 编程的客户端 API 与用于为所有数据库编程的 API 相同，例如 OLEDB、ODBC、ADO、ADO.NET 等等。下面是 Service Broker 使用的对象。

队列
Service Broker 使用队列在消息发送程序和消息接收程序之间提供松散耦合。发送程序可以使用 SEND 命令将消息放到队列中，然后应用程序继续操作并依靠 Service Broker 来确保消息到达其目标位置。
队列允许较大的计划灵活性。例如，发送程序可以发送多条消息以供多个接收程序并行处理。接收程序可能在消息发送很长时间后才处理消息，但由于传入消息进行了排队，因此接收程序可以按其自己的速率处理消息，而且发送程序无须等待接收程序完成处理便可继续操作。

对话
Service Broker 还实现了对话，对话是两个端点之间的双向消息流。对话中的所有消息都进行了排序，而且对话消息总是按照发送的顺序传送。该顺序在事务、输入线程、输出线程以及系统崩溃和重新启动过程中都保持不变。有些消息系统可以确保单个事务中发送或接收的消息顺序，但不能确保多个事务中的顺序，因此 Service Broker 对话具有独特的优势。
对话是一种会话类型。Service Broker 会话是持久可靠的通信通道。在以后的 SQL Server 版本中，Service Broker 将包括一对多的单向会话，也称为可靠的“发布-订阅”。在 SQL Server 2005 中，对话是唯一的会话类型，因此这两个术语同义。
每条消息都包括唯一标识与它相关的对话的会话句柄。例如，某个订单输入应用程序可能同时使用发货应用程序、库存应用程序和帐单应用程序打开了对话。因为每个应用程序中的消息都具有唯一的会话句柄，所以可以轻松地确定发送每条消息的应用程序。

消息类型
当前，所有 Service Broker 消息都与特定的消息类型相关联。消息类型是与消息一起传送的标签，因此接收消息的应用程序可以确定所接收消息的类型。此外，如果消息包含 XML 文档，则消息类型可以与 XML 架构集合相关联。如果为某个消息类型指定了架构集合，则所接收的该类型消息将在收到时根据架构集合进行验证，而没有通过架构验证的消息将会被拒绝。

规范
Service Broker 规范是一个消息类型集合。一个对话总是与一个规范相关联，而规范定义哪些消息类型可以通过对话发送。

服务
Service Broker 服务将一个或多个规范与一个队列相关联。规范定义可以将哪些消息类型发送到队列。服务名称用于建立对话的端点。服务名称用作实际队列的别名，因此您可以编写引用服务名称的 Service Broker 程序，然后在部署应用程序时将它与实际队列相关联。
返回页首

Service Broker“Hello World”

大多数编程语言书籍都以“Hello World”示例开始，因此我们也在 Service Broker 中使用 Hello World 作为示例。为简化示例，我使用可以从 SQL Server Management Studio 查询窗口运行的 T-SQL 进行编写。大多数 Service Broker 应用程序将作为普通的数据库应用程序，这些应用程序由通过 ADO 或 ADO.NET 与数据库进行通信的可执行程序和使用 T-SQL 或 .NET 语言编写的 SQL Server 存储过程构成。

要发送和接收消息，必须首先创建向 Service Broker 描述应用程序的消息传送部分的元数据对象。在 SQL Server 2005 中，使用新添加的 DDL 语句来创建、修改和删除 Service Broker 元数据。

-- 创建要使用的数据库
Create Database HelloWorldDB
go
Use HelloWorldDB
go
-- 创建要使用的两种消息类型。我们要使用的消息将是
-- 字符串而不是 XML - 因此无需进行验证
CREATE MESSAGE TYPE [HelloWorldRequest] VALIDATION = NONE 
CREATE MESSAGE TYPE [HelloWorldResponse] VALIDATION = NONE 

--  创建一个限制此对话框中消息类型
--  的规范。请求由对话框的初始化程序发出
--  响应消息由对话框目标发送。
CREATE CONTRACT [HelloWorldContract]
   ( 
[HelloWorldRequest] SENT BY initiator,
[HelloWorldResponse] SENT BY target
   )
-- 创建对话框在其间通信的两个队列。A
-- 对话框请求两个队列。
CREATE QUEUE [HelloWorldTargetQueue]
CREATE QUEUE [HelloWorldInitiatorQueue]
-- 创建命名对话框端点的服务。服务会将
-- 会话端点连接到队列。
CREATE SERVICE [HelloWorldRequestService] ON QUEUE [HelloWorldTargetQueue]
   ( 
[HelloWorldContract] 
   )
CREATE SERVICE [HelloWorldResponseService] ON QUEUE [HelloWorldInitiatorQueue]
go

现在已经设置了元数据，可以发送消息了。请注意，由于初始化程序和目标服务位于同一 SQL Server 实例中，因此消息将直接转到目标队列而不会通过传送队列传送。由于 Service Broker 内置在数据库中，因此可以进行此项性能优化。

Use HelloWorldDB
go

SET NOCOUNT ON
DECLARE @conversationHandle uniqueidentifier

Begin Transaction
-- 开始 Hello World 服务的对话

BEGIN DIALOG  @conversationHandle
FROM SERVICE    [HelloWorldResponseService]
TO SERVICE      'HelloWorldRequestService'
ON CONTRACT     [HelloWorldContract]
WITH ENCRYPTION = OFF, LIFETIME = 600;

-- 发送消息
SEND ON CONVERSATION @conversationHandle 
MESSAGE TYPE [HelloWorldRequest] (N'Hello World')

commit

让我们查看目标队列以确保成功发送了消息。

Use HelloWorldDB
go

-- 检查目标队列以确认消息已送达
select * from [HelloWorldTargetQueue]
go
-- 将消息主体转换为字符串，以便我们查看其中包含的内容
select cast(message_body as nvarchar(MAX)) from [HelloWorldTargetQueue]
go

现在可以从目标队列中接收消息并将响应发送回初始化程序。

-- 使用 Receive 命令可从队列接收消息

-- 声明变量以存储接收到的数据
SET NOCOUNT ON
DECLARE @conversationHandle uniqueidentifier
declare @message_body nvarchar(MAX)
declare @message_type_name sysname;

-- Service Broker 命令总是位于事务中
Begin Transaction;

-- Receive 命令的格式类似于一个选择列表。首先列出
-- 要获取的列，然后指定要从中获取消息
-- 的队列
RECEIVE top(1) -- 只接收一条消息，因此我们可以直接保存到变量中。
@message_type_name=message_type_name,  
-- 接收的消息类型
@conversationHandle=conversation_handle, 
                                       -- 对话的标识符 
-- 我们通过下列语句接收该消息
@message_body=message_body         
                                       -- 作为 
-- varbinary(MAX) blob 的消息内容
FROM [HelloWorldTargetQueue]

print @message_body

-- 如果这是一条 hello world 消息，则用相应的问候语回答
if @message_type_name = N'HelloWorldRequest'
Begin
SEND ON CONVERSATION @conversationHandle 
-- 使用下列消息接收语句的相同会话
MESSAGE TYPE [HelloWorldResponse] 
(N'Hello From '+@@servername )
-- 这是我们希望从初始化程序接收的唯一消息，因此
-- 现在可以安全地结束对话。
END CONVERSATION @conversationHandle
End
-- 提交事务
-- 如果此时我们回滚，所有内容将退回到
-- 我们开始时的状态 – 消息会返回到队列，并且没有发送响应
Commit
go
-- 确认我们从队列中删除了消息
select cast(message_body as nvarchar(MAX)) from [HelloWorldTargetQueue]
go

响应已在对话中发送回初始化程序队列，现在检查响应是否成功到达：

Use HelloWorldDB
go

select cast(message_body as nvarchar(MAX)) from [HelloWorldInitiatorQueue]
go

... 最后接收并显示响应消息：

RECEIVE  
cast(message_body as nvarchar(MAX))
FROM [HelloWorldInitiatorQueue]

现在已经成功地向 Service Broker 发送了消息并收到了响应。如果希望查看刚刚运行的命令的详细说明，请参见 SQL Server 联机书籍所提供的丰富消息。如果希望扩展此示例以在两个数据库之间使用，您需要添加从发起程序服务器到目标服务器的路由和从目标返回到初始化程序的路由。Service Broker 路由将 BEGIN DIALOG CONVERSATION 命令中指定的服务名称映射到发送消息所需的实际网络地址信息。有关路由和安全性的详细信息，请参见 SQL Server 联机书籍。

返回页首

示例
现在您已经看到了 Service Broker 是如何工作的，下面将介绍可以使用 Service Broker 开发的部分应用程序。

订单输入
许多程序都使用订单输入作为示例，因为大多数人都了解该过程。即使没有开发过订单输入系统的开发人员至少都使用过订单输入系统进行订货。
基于 Service Broker 的订单输入系统使用队列来将系统的子系统连接到一起。这不仅增加了并行度并且提高了效率，而且使配置和体系结构具有非常大的灵活性。
在本示例中，Service Broker 用于连接四个松散耦合的服务以处理每个订单。在订单输入服务将订单标题和订单内容插入到数据库中时，它根据计费、发货、库存和信贷限额服务对消息进行排队以完成对订单的处理。Service Broker 允许四项服务并行运行，从而缩短了系统的响应时间。
根据系统的业务需求，订单输入服务可以等待收到所有四项服务的响应后返回到用户，也可以在提交初始事务后立即返回而在后台执行其余的服务。实现每个操作都会对订单输入服务进行一些更改。每种情况中的其他服务保持不变。
使用 Service Broker 链接服务还提供了几个部署选项。所有五项服务可以在同一台服务器上运行，也可以根据需要分散在五台服务器（在服务的负载平衡时可以为更多的服务器）上运行以提供所需的效率。服务可以部署为存储过程或外部应用程序。这种灵活性对 ISV 非常有用，ISV 可以根据客户对性能、冗余和效率的需求创建单个代码库并在各种配置中进行部署。
图 1 ：使用 Service Broker 链接五项订单输入和处理服务

并行存储过程
最初发明触发器时，数据库公司通常对库存表使用触发器，在库存量太低时自动发出订单。虽然这是一个很好的概念，但是只有很少的系统使用了触发器，因为在触发器中执行大段代码的额外开销会使数据库的更新速度非常慢。Service Broker 允许触发器对要完成的工作进行排队，以便触发器可以完成和允许提交初始事务，从而使这类应用程序可以被广泛采用。然后，排队的工作在单独的事务中完成，甚至可以在不同的数据库中完成。SQL Server 2005 对“查询通知”和“事件通知”使用此模型。
Service Broker 还允许存储过程并行开始几个其他的存储过程。此功能可以显著缩短响应时间。例如，某个呼叫中心应用程序对传入的呼叫使用呼叫方 ID 查寻有关正在呼叫的客户的所有信息，因此客户服务代表可以获取所有相关信息。在许多情况下，必须从不同系统上的不同数据库中获取这些信息。可以使用远程查询获取所有这些信息，但响应时间可能太长。Service Broker 可以同步将请求排队到所有远程服务并在其输入队列上等待结果。因为并行处理所有请求，所以总响应时间将缩短。
图 2 ：并行处理示例

批处理
批处理系统中经常会使用 Service Broker 应用程序。大多数批处理由许多小型的半独立处理构成，必须对这些半独立处理进行计划和协调。独立执行子过程允许每个子系统按其最佳速度执行，因此可以提高效率。
在本示例中，将会不间断地在输入队列上累计对批计划过程的输入，包括预购、预测、返回等等。当计划引擎运行时，它阅读队列中的输入、进行分析、然后将请求排队到处理计划输出的子过程。输出队列允许在一台服务器或多台服务器上并行地单独执行子过程。这允许根据需要扩展任意多台服务器以满足处理负载的需求。
图 3：大批量处理示例

旅行预订
以前，我经常为硕士研究生讲授分布式数据库类。我曾经使用的一个分布式事务的示例是旅行社在同一事务中预订了飞机票、旅馆房间和租车服务，因为客户在无法进行航空旅行时不会预订旅馆。像许多示例一样，直到有一天一位来自真正旅行社的程序员来到了教室里，我们才了解真实的情况。他告诉我真正的旅行社不是这样工作的。在预订旅馆房间时，航空公司不允许任何人锁定其预订表格和座位安排。预订根据当前的可用性完成，并且如果在实施预订时已经没有空余的座位或房间，将给客户打电话以确保新的预订满足客户需求。
在旅行预订 Web 站点示例中，预订根据有关航空公司和旅店可用性的数据表来完成。这些表包含来自航空公司或旅馆的信息。信息会经常更新，但总是会有一点过时。实际的预订在客户预约旅行后才发生，并可能在客户取消旅行后被取消。
这种延迟的活动非常适合 Service Broker 体系结构。记录客户旅行安排的事务将消息提交到进行实际预订的后端服务。预订服务读取队列中的消息并在单独的事务中处理每个预订。预订服务通过各种协议与预订航空公司和旅馆服务的系统进行通信。这些通信可能包括 Web 服务、SNA、HTTP、EDI、传真、Service Broker 等等。由于对到预订服务的输入进行了排队，因此这些协议的不同滞后时间不会带来问题。如果队列太长，Service Broker 激活可以启动更多的队列读取器来处理负载。如果负载达到预订服务器能够处理的最大值，则可以通过向路由表添加行来添加更多的服务器。
在成功完成特定路线的所有预订后，会将一条消息排队到 SQLiMail 服务器以向客户发送确认电子邮件。如果一项或多项预订未能完成，将通知客户服务代表来帮助重新预订旅行。
“处理更新”服务在后台运行，并定期从旅馆和航空公司接收可用性信息。这些信息被转换为常见的 XML 格式，然后通过通知服务发布到 Web 集群中的服务器以更新旅馆和航空公司的可用性表。
松散耦合的 Service Broker 体系结构允许通过加载软件、配置数据库和订阅可用性反馈来将 Web 服务器添加到服务器集群。可以编写脚本以使进行操作时只需最少的手动干预。为向预订服务添加更多后端服务器，必须安装和配置该服务，然后必须将新的服务器地址添加到 Web 服务器中的路由表。
图 4 ：旅行预订示例
返回页首

结论
SQL Server 2005 Service Broker 是用于生成分布式异步数据库应用程序的新平台。SQL Server 数据库中包括的可靠异步消息功能使您可以生成各种以前难以生成甚至无法生成的数据库应用程序。SQL Server 2005 集成了 Service Broker 以及 CLR 和 XML 数据类型等其他开发人员功能，成为生成高度可扩展数据库应用程序的一个主要平台。
参考资料
A First Look at SQL Server 2005 for Developers
© 2004 Microsoft Corporation 版权所有。保留所有权利。使用规定。

从队列中检索一个或多个消息。根据队列保持设置的不同，可以从队列中删除消息或更新队列中消息的状态。

语法

[ WAITFOR ( ]
    RECEIVE [ TOP ( n ) ] 
        <column_specifier> [ ,...n ]
        FROM <queue>
        [ INTO table_variable ]
        [ WHERE {  conversation_handle = conversation_handle
                 | conversation_group_id = conversation_group_id } ]
[ ) ] [ , TIMEOUT timeout ]
[ ; ]

<column_specifier> ::=
{    * 
  |  { column_name | [ ] expression } [ [ AS ] column_alias ]
  |  column_alias = expression 
}     [ ,...n ] 

<queue> ::=
{
    [ database_name . [ schema_name ] . | schema_name . ]
        queue_name
}

参数

WAITFOR: 指定如果当前没有消息，则 RECEIVE 语句将等待消息到达队列。

TOP( n ): 指定要返回的最大消息数。如果未指定该子句，则返回所有满足语句条件的消息。

*: 指定结果集包含队列中的所有列。

column_name: 要包含在结果集中的列的名称。

expression: 列名、常量、函数或由运算符连接的列名、常量和函数的任意组合。

column_alias: 替换结果集内列名的可选名。

FROM: 指定包含要检索的消息的队列。

database_name: 包含从中接收消息的队列的数据库的名称。如果未提供 database_name，则默认为当前数据库。

schema_name: 从中接收消息的队列所属架构的名称。如果未提供 schema_name，则默认为当前用户的默认架构。

queue_name: 从中接收消息的队列的名称。

INTO table_variable: 指定从已收到的消息选到列的表。

WHERE: 指定用于已收到的消息的会话或会话组。如果省略，则从下一个可用会话组返回消息。

conversation_handle = conversation_handle: 指定用于已收到的消息的会话。提供的 conversation_handle 的数据类型必须为 uniqueidentifer 或可转换为 uniqueidentifier 的类型。

conversation_group_id = conversation_group_id: 指定用于已收到的消息的会话组。提供的 conversation_group_id 的数据类型必须为 uniqueidentifier 或可转换为 uniqueidentifier 的类型。

TIMEOUT timeout: 指定语句等待消息的时间（以毫秒为单位）。该子句只能与 WAITFOR 子句一起使用。如果未指定该子句，或者超时值为 -1，则等待时间没有限制。如果超时时间已到，则 RECEIVE 返回一个空结果集。

备注

重要提示：
如果 RECEIVE 语句不是批处理或存储过程中的第一条语句，则前面的语句必须以 Transact-SQL 语句终止符分号 (;) 终止。

RECEIVE 语句将从队列读取消息并返回结果集。返回的结果集包含零行或多行，每行包含一个消息。如果未使用 INTO 子句，并且 column_specifier 没有为局部变量分配值，则该语句将结果集返回到调用程序。

RECEIVE 语句将从队列中删除已收到的消息，但队列指定消息保持时除外。当队列的 RETENTION 设置为 ON 时，RECEIVE 语句将 status 列更新为 1，并使消息留在队列中。当包含 RECEIVE 语句的事务回滚时，该事务中队列的所有更改也会随之回滚，并将消息返回到队列。

RECEIVE 语句返回的所有消息都属于同一个会话组。 RECEIVE 语句将锁定返回的消息所属的会话组，直到包含该语句的事务完成为止。将 RECEIVE 语句返回的结果集进行隐式排序。对于给定的会话，RECEIVE 语句将返回 status 为 1 的消息，并将消息按 message_sequence_number 的升序排列。

RECEIVE 语句的 WHERE 子句可能只包含使用 conversation_handle 或 conversation_group_id 的搜索条件。搜索条件不能包含队列中的任何其他列。 conversation_handle 或conversation_group_id 不能为表达式。如果未指定 WHERE 子句，则 RECEIVE 语句将从下一个可用会话组返回消息，而不考虑当前连接在其他会话组上持有的锁。当 WHERE 子句未指定conversation_handle 时，RECEIVE 语句将从会话组返回消息，而不考虑每个消息所属的会话。如果 WHERE 子句中指定的会话句柄或会话组标识符不存在，或者未与指定的队列关联，则 RECEIVE 语句将返回一个错误。

如果 RECEIVE 语句指定的队列的队列状态设置为 OFF，则该语句将失败，并返回一个 Transact-SQL 错误。

指定 WAITFOR 子句后，该语句将等待指定的超时时间，或等到结果集可用为止。如果在语句等待时删除队列或队列的状态设置为 OFF，则该语句立即返回一个错误。如果 RECEIVE 语句指定了会话组或会话句柄，并且用于该会话的服务被删除或移动到另一个队列，则 RECEIVE 语句将报告一个 Transact-SQL 错误。

RECEIVE 在用户定义函数中无效。

下表列出了队列中的列：

列名数据类型说明
status
tinyint
消息的状态。对于由 RECEIVE 命令返回的消息，状态总为 0。队列中的消息可能包含下列值之一：
0=就绪1=已收到的消息2=尚未完成3=发送后予以保留的消息
priority
tinyint
0. 标识只是为了提供一些信息。不提供支持。不保证以后的兼容性。.
queuing_order
bigint
消息在该队列中的序号。
conversation_group_id
uniqueidentifier
此消息所属的会话组的标识符。
conversation_handle
uniqueidentifier
此消息所属的会话的句柄。
message_sequence_number
bigint
会话中的消息的序列号。
service_name
nvarchar(512)
要进行会话的服务的名称。
service_id
int
要进行会话的服务的 SQL Server 对象标识符。
service_contract_name
nvarchar(256)
会话遵循的约定的名称。
service_contract_id
int
会话遵循的约定的 SQL Server 对象标识符。
message_type_name
nvarchar(256)
说明消息的消息类型的名称。
message_type_id
int
说明消息的消息类型的 SQL Server 对象标识符。
validation
nchar(2)
对消息使用的验证。
E=空N=无X=XML
message_body
varbinary(MAX)
消息的内容。

列名	数据类型	说明
status	tinyint	消息的状态。对于由 RECEIVE 命令返回的消息，状态总为 0。队列中的消息可能包含下列值之一： 0=就绪1=已收到的消息2=尚未完成3=发送后予以保留的消息
priority	tinyint	0. 标识只是为了提供一些信息。不提供支持。不保证以后的兼容性。.
queuing_order	bigint	消息在该队列中的序号。
conversation_group_id	uniqueidentifier	此消息所属的会话组的标识符。
conversation_handle	uniqueidentifier	此消息所属的会话的句柄。
message_sequence_number	bigint	会话中的消息的序列号。
service_name	nvarchar(512)	要进行会话的服务的名称。
service_id	int	要进行会话的服务的 SQL Server 对象标识符。
service_contract_name	nvarchar(256)	会话遵循的约定的名称。
service_contract_id	int	会话遵循的约定的 SQL Server 对象标识符。
message_type_name	nvarchar(256)	说明消息的消息类型的名称。
message_type_id	int	说明消息的消息类型的 SQL Server 对象标识符。
validation	nchar(2)	对消息使用的验证。 E=空N=无X=XML
message_body	varbinary(MAX)	消息的内容。

权限

若要接收消息，则当前用户必须对队列有 RECEIVE 权限。

示例

A. 接收会话组中所有消息的所有列

下面的示例接收 ExpenseQueue 队列中下一个可用会话组的所有可用消息。该语句将消息作为结果集返回。

RECEIVE * FROM ExpenseQueue ;

B. 接收用于会话组中所有消息的指定列

下面的示例接收 ExpenseQueue 队列中下一个可用会话组的所有可用消息。该语句将消息作为包含 conversation_handle、message_type_name 和 message_body 列的结果集返回。

RECEIVE conversation_handle, message_type_name, message_body
FROM ExpenseQueue ;

C. 接收队列中的第一个可用消息

以下示例将 ExpenseQueue 队列内的第一个可用消息作为结果集接收。

RECEIVE TOP (1) * FROM ExpenseQueue ;

D. 接收指定会话的所有消息

以下示例将 ExpenseQueue 队列内指定会话的所有可用消息作为结果集接收。

DECLARE @conversation_handle UNIQUEIDENTIFIER ;

SET @conversation_handle = <retrieve conversation from database> ;

RECEIVE *
FROM ExpenseQueue
WHERE conversation_handle = @conversation_handle ;

E. 接收指定会话组的消息

以下示例将 ExpenseQueue 队列内指定会话组的所有可用消息作为结果集接收。

DECLARE @conversation_group_id UNIQUEIDENTIFIER ;

SET @conversation_group_id = 
    <retrieve conversation group ID from database> ;

RECEIVE *
FROM ExpenseQueue
WHERE conversation_group_id = @conversation_group_id ;

F. 接收到表变量

以下示例将 ExpenseQueue 队列内指定会话组的所有可用消息接收到表变量。

DECLARE @conversation_group_id UNIQUEIDENTIFIER ;

DECLARE @procTable TABLE(
     service_instance_id UNIQUEIDENTIFIER,
     handle UNIQUEIDENTIFIER,
     message_sequence_number BIGINT,
     service_name NVARCHAR(512),
     service_contract_name NVARCHAR(256),
     message_type_name NVARCHAR(256),
     validation NCHAR,
     message_body VARBINARY(MAX)) ;

SET @conversation_group_id = <retrieve conversation group ID from database> ;

RECEIVE TOP (1)
    conversation_group_id,
    conversation_handle,
    message_sequence_number,
    service_name,
    service_contract_name,
    message_type_name,
    validation,
    message_body
FROM ExpenseQueue
INTO @procTable
WHERE conversation_group_id = @conversation_group_id ;

G. 接收消息并无限期等待

下面的示例将接收对 ExpenseQueue 队列中下一个可用会话组的所有可用消息：该语句将等到至少一个消息变为可用为止，然后返回一个包含所有消息列的结果集。

WAITFOR (
    RECEIVE *
    FROM ExpenseQueue) ;

H. 接收消息并等待指定的时长

下面的示例将接收对 ExpenseQueue 队列中下一个可用会话组的所有可用消息：该语句将等待 60 秒，或直到至少一个消息变为可用为止，这两个条件以先发生者为准。如果至少一个消息可用，则该语句将返回一个包含所有消息列的结果集；否则，该语句返回一个空结果集。

WAITFOR (
    RECEIVE *
    FROM ExpenseQueue ),
TIMEOUT 60000 ;

I. 接收消息，修改列的类型

下面的示例将接收对 ExpenseQueue 队列中下一个可用会话组的所有可用消息：当消息类型声明该消息包含一个 XML 文档时，该语句便将消息正文转换为 XML。

WAITFOR (
    RECEIVE message_type_name,
        CASE
            WHEN validation = 'X' THEN CAST(message_body as XML)
            ELSE NULL
         END AS message_body 
         FROM ExpenseQueue ),
TIMEOUT 60000 ;

J. 接收消息，从消息正文中提取数据，检索会话状态

以下示例将接收 ExpenseQueue 队列内下一个可用会话组的下一个可用消息。当消息的类型为 //Adventure-Works.com/Expenses/SubmitExpense 时，该语句将从消息正文中提取雇员 ID 和一个项列表。该语句还会从 ConversationState 表中检索会话的状态。

WAITFOR(
    RECEIVE 
    TOP(1)
      message_type_name,
      COALESCE(
           (SELECT TOP(1) ConversationState
            FROM CurrentConversations AS cc
            WHERE cc.ConversationHandle = conversation_handle),
           'NEW')
      AS ConversationState,
      COALESCE(
          (SELECT TOP(1) ErrorCount
           FROM CurrentConversations AS cc
           WHERE cc.ConversationHandle = conversation_handle), 
           0)
      AS ConversationErrors,
      CASE WHEN message_type_name = N'//Adventure-Works.com/Expenses/SubmitExpense'
          THEN CAST(message_body AS XML).value(
                'declare namespace rpt = "http://Adventure-Works.com/schemas/expenseReport"
                   (/rpt:ExpenseReport/rpt:EmployeeID)[1]', 'nvarchar(20)')
         ELSE NULL
      END AS EmployeeID,
      CASE WHEN message_type_name = N'//Adventure-Works.com/Expenses/SubmitExpense'
          THEN CAST(message_body AS XML).query(
                'declare namespace rpt = "http://Adventure-Works.com/schemas/expenseReport" 
                     /rpt:ExpenseReport/rpt:ItemDetail')
          ELSE NULL
      END AS ItemList
    FROM ExpenseQueue 
), TIMEOUT 60000 ;

本文链接

招聘

2010-03-16T11:40:00Z

http://job.cnblogs.com/enterprise/2320/

本文链接

讲软件作坊和正规军的差异之前，先来谈谈少林寺（转）

2010-03-09T05:19:00Z

这个实在有点无厘头，少林寺那是和尚练功夫的地方，跟研发能扯上什么鸟关系？且听我慢慢道来。
　搞研发的，做事情一定要严谨，讲什么话都得有依据，既然和武林的事情有关，就拿金庸先生的小说来说事儿，看的人多嘛。
　看过金先生小说的同学肯定都知道，武林中潮起潮落，高手辈出。有时候华山派领袖武林（《参见碧血剑》），有时候武当派独领风骚（参见《倚天屠龙记》），有时候邪派里面也会出很多的高手（比如东方不败）。但是，不管如何，少林寺始终都在武林中占据了显赫的位置。比如《倚天屠龙记》里面张无忌领袖群雄抗击元兵那一段，400多个能通过跳墙考核的高手里面，少林寺倒占了8、90个。鄙人是个金迷，金先生的几本大部头的小说里面（比如《天龙八部》、《笑傲江湖》等），少林寺始终是武林中举足轻重的力量，而其它各个门派，当然也会出现不世出的高手，但相比少林寺而言，可持续性发展上明显就有差距，出两个高手就兴旺了，高手一挂，整个门派也就衰了。

为什么少林寺能做到可持续发展？少林派和其他门派最大的差异是什么？
　关于这个问题，我们先来看个现象。少林寺有一个专门保存少林寺的组织资产（各种武经）的场所—藏经楼。少林寺历届高僧但有心得，一定要记录下来拿到藏经楼去归档，并且立下严规，不能泄示为外人。关于这一点，《天龙八部》里面做了最好的阐述。萧峰之所以成为孤儿，波罗星之所以被扣留少林不得离开，都是因为要保卫这个核心资产的缘故。相比之下，其它门派在对组织资产的管理上落后就太多了。比如丐帮，乔峰、洪七公和黄蓉任帮主的时候好生兴旺，可是一旦换成史火龙，张无忌一己之力就打得丐帮一败涂地。丐帮尤其有个相当莫名其妙的规矩，一定要会打狗棒法和降龙十八掌的高手才能执掌丐帮，那不是说一个公司的总经理一定要精通VC2008吗？时间一长，不败才怪呢。相比之下，玄慈老方丈的武功不算顶尖高手，可是少林寺仍然被公认是中原武林的泰山北斗，始终享有“天下武功出少林”的美誉。

因此，笔者认为答案在于：少林派是所有门派里面最最注重把个人能力转化为组织资产的一个门派，少林寺从没有把希望建立在一两个英雄身上，他们依靠的，是藏经楼和一整套的相关管理制度，几百上千年的积累下来，少林寺就成了武林中长盛不衰的力量。这个，就是少林寺的核心竞争力所在。可笑日月神教的东方不败，任我行之流，以为练练葵花宝典、吸星大法之类的功夫就可以搞定少林寺，谬矣。我刚开始编软件只知道天天啃代码的时候，身边一位师兄曾经给我说过一段话，至今印象深刻。大意是讲洋人其实比中国人来讲是很笨的，但有一桩好处，他们很注意积累，总是注重在前人的基础上前进一点点，这么着一代一代积累下来，时间长了，就很可观了。而中国人总是喜欢推到重来，个体很容易成为高手，但是组织能力不能得到同步的提升。短期冲刺起来很厉害，时间越长，差距越大。依靠的是乔峰这样的大英雄，还是依靠一整套成熟的制度带来的持续发展和积累？组织的资产有没有得到很好的沉淀和管理？所谓作坊式的开发组织和正规军之间的差别，大抵不过如此而已。搞软件研发管理的，嫌啃CMMI那堆文件太晦涩的话，不妨去研究研究少林寺是如何管理的。我常想，玄慈老方丈和金庸先生如果到一个现代IT企业去做CEO，多半也是能够胜任的。O(∩_∩)O哈哈~。

少林寺的组织机构对研发企业组织结构的启示－罗汉堂是一个产品开发部门继续少林寺的话题，这次谈谈少林寺的组织结构。在不同的时期，少林寺的组织结构有些差异，但大致上核心的结构如下：少林寺＝藏经楼＋戒律院＋达摩院＋般若堂＋罗汉堂＋知客院。藏经楼非常重要，笔者已经在前面的文章“从少林寺的核心竞争力看软件作坊和正规军的差异”中谈过了；戒律院是管纪律的；知客堂负责江湖上其它门派的接待、纠纷处理之类的琐事。这些都略过不谈。剩下二堂一院则是少林武学的核心所在。其中，达摩院的主要职能是钻研本派的武功绝学；般若堂的职责是钻研天下各门各派的武学；罗汉堂则负责传道授业，发现人才，并根据弟子们的资质、特点向达摩院或般若堂输送人才。笔者仔细研究了达摩、般若和罗汉二堂一院，发现这个设置非常科学，所谓“天下武功出少林”，皆源自于此。现代研发企业若想长盛不衰，在组织架构设置上非得学学少林寺的经验不可。

 我们先来分析一下罗汉堂，罗汉堂有几个特点，非常像公司里面的产品开发部门。
 其一，罗汉堂里面的弟子学的都是成熟的武功，注意，一定是成熟的，这是很重要的！为什么一定要强调成熟呢？道理是很显然的，成熟就意味着可靠，成熟就意味着风险小，成熟就意味着优点缺点一目了然，成熟还意味着很多，就不一一总结了。学习研究过研发管理的TX一定知道，产品开发非常强调要采用成熟技术，这是 IPD研发管理理论的核心理念之一。现如今很多咨询公司都在满世界推销IPD，我们公司就被忽悠了好几百万走。人家少林寺坚持了几千年的东西，花几百块钱买几套金先生的小说就可以学的到，非要花几十上百万买，你说冤不冤？其二、少林寺进罗汉堂的门槛比较低。这个道理很显然，成熟嘛，自然可以搞得懂的人就多，所以对人才层次的要求也比较大众化。什么事情都有个量的要求，如果少林寺只有几三五个顶尖高手，没办法做到长盛不衰。单说一个武功推广就没法搞。任何公司要把产值做大，就必须有足够多的人手。做产品有很多琐碎的事情，靠几个高手高手高高手，累死了能干多少活？这个世界的人才永远是个金字塔型的，越往上走人总是越少，成本也成几何级地提高。一个公司要做大，一定要想法子把对人才档次的需求降下来。其三、罗汉堂的武僧人数是最多的，远远超过达摩院和般若堂。列位看官且想想，公司里面搞产品开发的部门，是不是人数最多的部门？而搞产品开发的高手，是不是不断地被抽出来，向管理岗位、想预研部门输送？
 像不像？越想越像，太像了！

尽管罗汉堂早就给我们揭示了研发企业中产品开发部门的工作特点，可是还是有那么多的企业还是热衷于在产品开发中使用最新最好的技术。包括笔者所在的公司，不少人嘴上讲起研发管理头头是道，一到实际的项目开发中就孜孜不倦的期望个个工程师都是张三丰老道和天才少年张翠山，随便想想就能搞出个倚天屠龙级别的产品来大卖特卖，岂不谬哉？可见学会知识容易，改变行为模式，却是何其难哉！先写到这里，达摩堂和罗汉堂的分析下次再谈吧。

前面已经提过，《天龙八部》里面讲过枯荣老和尚一把火烧掉了“六脉神剑”剑谱的事情。之前天龙寺的几个高僧讨论过要不要用剑谱和鸠摩智交换少林72绝技，枯荣老和尚说我们自己的一阳指习练下去永无止境，何必要眼红别个的武学？于是给否决了。相比之下，少林寺的态度大不一样。记不住是《天龙八部》还是《倚天屠龙》里面写的，少林弟子行走江湖，回寺后都要到般若堂禀告经历见闻，别派武功只要有一招一式可以采纳，般若堂高手就记录下来。记录下来，目的自然是要研究学习，广大少林武学。

光是靠成熟技术吃老本，坐吃山空总有吃尽的时候。少林寺要是只有一个罗汉堂，慢说只有72绝技，就算有720绝技，一样会被淘汰。因此一定要从机构设置上保证组织创新的活力！少林寺的达摩院和般若堂，可不就是为创新而设的吗？列位看官，般若堂是不是天天忙着掌握业界动态，跟踪业界的先进技术，而达摩堂，可不就是在创新发展自己的核心技术吗？创新可不就这么搞的吗？这可不就是预研部门的职责吗？一种产品，从开始出现商机，少则两三年，多则十来年其市场也就萎缩了。因此，不管是少林寺还是现代研发企业，一定要不停地创新。微软要是一个 Windows95卖到现在，恐怕早就倒闭到了。Bill Gates一直说，Microsoft从辉煌到破产只有18个月的时间，讲的就是这个道理。因此，微软把研发精英集中到一起，组建了微软研究院。多年来，微软研究院战功卓著，搞出了.net、WinCE等对微软具有战略意义的绝技。笔者真的很怀疑，Gates是不是跟少林寺的老和尚学过一手。少林寺博采众长，不停地做加法；天龙寺固步自封，坚决地做减法。境界上的差异，何止是嵩山到大理的距离可以弥补得了的？少林寺的成功，表明上看是易筋经和72绝技的成功，实则是理念和文化的成功啊！

本文链接

Archive: Java Technology Products Download

2010-03-02T07:16:00Z

So long, old friend...

http://java.sun.com/products/archive

本文链接

博客园_wengmj's blog

SQL Server 2005 Service Broker

多读取器队列多读取器队列是一种扩展异步应用程序的最有效的方式。为证明这一点，我将通过大家都熟悉的两个示例说明如何进行排队。

规范Service Broker 规范是一个消息类型集合。一个对话总是与一个规范相关联，而规范定义哪些消息类型可以通过对话发送。

示例现在您已经看到了 Service Broker 是如何工作的，下面将介绍可以使用 Service Broker 开发的部分应用程序。

招聘

讲软件作坊和正规军的差异之前，先来谈谈少林寺（转）

Archive: Java Technology Products Download

多读取器队列
多读取器队列是一种扩展异步应用程序的最有效的方式。为证明这一点，我将通过大家都熟悉的两个示例说明如何进行排队。

规范
Service Broker 规范是一个消息类型集合。一个对话总是与一个规范相关联，而规范定义哪些消息类型可以通过对话发送。

示例
现在您已经看到了 Service Broker 是如何工作的，下面将介绍可以使用 Service Broker 开发的部分应用程序。