本文我们粗略地分析了SOA出现的缘由及其对数据存储的新要求，并进而简要概括了SQL Server 2005对这种新式数据要求所提供的支持。
作为微软新一代企业级应用平台旗舰产品之一的SQL Server 2005，有太多的精彩值得我们关注。而SOA(面向服务的架构)，对于新一代面向同步和异步应用的、基于以因特网平台为主的请求/响应模式的分布式计算来说，无疑是一场革命。数据库，作为基于面向服务的数据库架构(SODA)构建分布式架构的一个战略组成部分之一，举足轻重。本系列文章中，我们将试图剖析SODA背后的相关概念，并进而观察微软如何以其力图“撼动未来”的SQL Server 2005适应这种新型架构。
一、SOA架构的出现
当我们把上世纪九十年代占主流的客户机-服务器和N层应用程序架构用于开发今天大规模的因特网电子商务站点时，这些方案遇到了严重的问题—可伸缩性和可用性。其中一个主要的问题就是，数据越来越倾向于存储在一个大规模、高度集中的数据库中，而且所有客户端组件都可以对之实现直接访问。此时，几乎所有与这些数据库相关的通信都是以SQL语句(或存在于一个存储过程中的批语句)形式执行的;于是，客户端将接收到一个特定于要解决的任务的数据集合。
而今，当我们试图把“遗留”系统加入到较新的应用程序中时，又遇到了其它的问题。在经过多年来使用各种专利性技术和平台发布大范围的系统后，整个世界可谓“遍布”这种能够较好地实现“自身”工作的系统;但是，这些系统却往往缺乏清晰的思路来实现与其它应用程序的交互—悉知，如今的连接环境正变得越来越方便。因此，实现今天的应用程序所要求的灵活性已经变得相当困难。B2B(业务到业务)应用甚至于使得事情进一步复杂化，因为这要求必须满足特定的标准并使用可靠的方法来实现业务传输的电子化。非常明显，满足今天全球业务环境需要的不断演变的系统都要求实现某种新架构，这种架构必须能够高效地使用“遗留”系统并能提供一个灵活的商业基础框架。
为了满足这些需要，最近三到五年间已经出现了一种“新的”大规模、松耦合、分布式的系统架构，特别是作为因特网电子商务站点已经成长为其主要的商业运作模式。面向服务的架构(SOA)已经开始作为主流的松耦合、以服务为中心的架构出现。事实证明，基于SOA的应用程序更能经得起失败，并且更为容易地按比例调整规模—通过使用多种方法添加必要的资源来满足不断发展的要求;而且，它们也允许把“遗留”系统轻松地集成到现有B2B及其它系统中。
二、 面向服务架构对数据的要求
在一个SOA应用程序中，SOA服务提供者、服务消费者及其它组件都会将数据处理作为其自身角色的一个“自然”的特征。典型情况下，一个SOA应用程序仍然使用中央数据库来存储和保护数据;但是，也有可能使用许多这种大型的数据库来存储各类数据—例如单独存储的销售、生产和操作数据以及每一部分中的特定数据子集等。每个服务提供者和消费者都可能需要对数据或其自己特定的数据存储进行本地缓冲。此外，跨越应用程序的远距离部分传输的消息本身常常就是一些值得加以存档而备以后使用的数据。
根据数据在系统中的特征，我们可以按下列四种方式对之进行划分：
•①引用数据—用于创建服务请求(例如一个产品目录)。它必须是以一种为所有部分可用的格式存在，而且以一种恒定不变的方式(例如一个目录日期)加以标识。
•②活动数据—是短暂的数据，用于执行一个特定的活动，例如一个产品列表(用于从库存中检索购买项)。既然它是私有于服务的，所以该格式不需要被其它模块所理解。
•③资源数据—是一种长期存在的数据。这种数据为一个服务(例如顾客数据和帐户数据)内部使用。
•④服务交互数据—用于服务间的通讯。这必须是以一种为所有部分都能理解的格式进行，并且必须长期保持不变。例如，在服务之间以一个订单表单形式进行通讯。如果该订单被丢失，那么它必须能够被以与以前相同的形式重新生成并且被再次转换。
下图1展示了一些可能构成一个松耦合的应用程序(基于SOA原则进行构建)的端点。其中的服务消费者可能代表一个客户端应用程序;而一个服务器应用程序(例如一个Web服务器)，或者是任何其它类型的应用程序，将把消息发送给一个服务提供者。在复杂的系统中，可能通过一个消息路由器最初接收消息，然后应用特定的逻辑把该请求路由到适当的服务提供者。然后，该服务提供者接收此消息并加以处理—解包并重新格式化它，执行任何要求实现的工作，最后可能把一个响应发送回服务消费者。
最新评论