|
|
基于消息的应用程序并不是一个新概念，但一直以来，从头编写这样的应用程序都相当困难。我将在一系列三篇文章中讨论一个建立异步消息应用程序的新平台，本文为第一篇，我将在其中说明基于消息的应用程序这一概念，以及一个建立包含在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应用程序模型。
|
|
