SQLServer2005基于消息的利用程序先容

基于消息的利用程序并不是一个新概念，一直以来，从头编写这样的利用程序都相当艰苦。我将在一系列三篇文章中讨论一个建创新步消息利用程序的新平台，本文为第一篇，我将在其中阐明基于消息的利用程序这一概念，以及一个建立包含在SQL Server 2005中的这些利用程序的新型基础程序。

基于消息的利用程序先容

处理消息的利用程序是大体上会成功的利用程序。实际上，大多数大型利用程序都利用了某种类型的消息处理。这种处理可能相当简略，例如，把一个文件放在网络共享中，以便另一个利用程序能够处理这个文件；之后，你就可以检查网络共享，看文件是否得到处理。

固然这不是一个非常复杂的消息利用程序，但其背后的概念是一样的：提交一条消息，利用程序履行其工作。然后，再检查看是否收到确认消息已得到处理的信息。这种处理方法拥有很多奇特的长处：

延期处理：有时候，要想在给定的时间处理某个任务的所有工作是不切实际的。很多时候，当你的利用程序能够处理的任务达到一个瓶颈点时，最好把剩下的任务交给另一个利用程序进行处理。

在线购置机票就属于这种情况。当你到一个网站购置机票时，你输进诸如出发城市、达到城市、旅行日期和随行乘客人数之类的信息。在你输进信用卡信息后，你将收到一封确认电子邮件。在后台，某种类型的消息已被提交给另一个履行恳求的服务进行处理。假如不能满足订票恳求，你收到的电子邮件就会阐明这一点。
这种处理的利益在于它减轻了后台数据库系统堵塞的压力。而且，假如请求顾客长时间等候网站的确认，大多数顾客都会感到非常不满。另外，假如所有处理任务都在一个单功效事务中完成，就可能产生严重的逝世锁情况，从而负面影响在网站上购置机票的顾客的购置体验。

散布式处理：一般来说，最好尽可能敏捷地处理一项任务。但是，有时候很难断定有多少待处理的任务、完成这些任务需要耗用多少资源。下面我们看一个这种处理的实例。

超市中有很多结账通道。通道的数目一般根据超市的资源来配备。有时，例如星期六下午，结账通道变得十分拥挤，顾客必需排队等候。只要超市的资源没有耗尽，超市就能分配更多收银员给顾客结账。这样既可加快结账速度，又不至于影响超市的总体运作。
同样的道理，消息利用程序也以类似的方法运作。假如你的利用程序布满了待处理的恳求，通常应当增加另外一条处理队列来缓解系统的总体处理压力。
微软消息队列

现在你可能已经领会到基于消息的利用程序带来的价值，你也许想知道为什么你没有经常听说这种利用程序。重要的原因在于，开发这种利用程序是一个非常艰苦的任务。假如你打算编写自己的基于消息的利用程序，你要用大部分时间来开发处理消息的基础架构。

好消息是，你不再需要开发自己的消息基础架构。微软消息队列（MSMQ）供给一个开发这类利用程序的框架。它使得利用程序可以在不同种类的网络间进行通信，并且需要保证消息传送（guaranteed message delivery）、路由和可配置安全。MSMQ利用程序一般在以Visual Basic、C#或C 编写的利用程序中开发，不过也可以用其它程序语言编写。这些利用程序在处理通常需要几步完成的任务时表现优良。这时，一个任务的每个步骤需要逻辑达到任务的下一个步骤，如一个业务工作流畅用程序。

数据库——不再只是用于存储数据

过往20年来，我们对关系数据库系统的依附程度明显增加。最初，存储数据并对数据进行某种处理，是建立贸易关系数据库系统的重要目标。随着关系数据库系统的发展，其功效和复杂性的变更，它的重要用处已由单一数据存储转变为更加主流的贸易智能目标、更加复杂的ETL处理、数据报告、数据通知；在SQL Server 2005中，它甚至已具备编写在数据库引擎中履行的.NET CLR语言代码的才能。因此，完整可以确定地说，数据库引擎已不再仅用于数据存储。

Service Broker

微软认为，答应你在数据库内建立基于消息的利用程序，这样才有意义。Service Broker是SQL Server 2005中新添加的基础程序，重要用于在数据库引擎内建立基于消息的利用程序。这些利用程序在数据库引擎内应用新的TSQL结构而开发。

Service Broker利用程序以疏松连接的利用程序而开发，它具有高度可扩大性，并供给其它消息平台所不具备的功效，如消息组和谐和锁定。这些利用程序充分支撑事务，并能够跨越数据库实例和服务器。