基于音讯的使用程序并不是一个新概念，但不断以来，从头编写这样的使用程序都相当困难。我将在一系列三篇文章中讨论一个建立异步音讯使用程序的新平台，本文为第一篇，我将在其中说明基于音讯的使用程序这一概念，以及一个建立包含在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使用程序以松散连接的使用程序而开发，它具有高度可扩展性，并提供其它音讯平台所不具备的功用，如音讯组协调和锁定。这些使用程序充分支持事务，并能够跨越数据库实例和服务器。

　　后续讨论

　　在这个系列的下一篇文章中，我将引见Service Broker使用程序组件，并探讨它们之间如何交互以构成一个Service Broker使用程序模型。