作为微软新
代企业级应用平台旗舰产品的
SQL Server 2005
有太多精彩值得我们关注
而SOA(面向服务架构)对于新代面向同步和异步应用、基于以因特网平台为主请求/响应模式分布式计算来说无疑是场革命数据库作为基于面向服务数据库架构(SODA)构建分布式架构个战略组成部分的举足轻重本系列文章中我们将试图剖析SODA背后相关概念并进而观察微软如何以其力图“撼动未来”SQL Server 2005适应这种新型架构、SOA架构出现当我们把上世纪 9十年代占主流
客户机-服务器和N层应用
架构用于开发今天大规模因特网电子商务站点时这些方案遇到了严重问题—可伸缩性和可用性其中个主要问题就是数据越来越倾向于存储在个大规模、高度集中数据库中而且所有客户端组件都可以对的实现直接访问此时几乎所有和这些数据库相关通信都是以SQL语句(或存在于个存储过程中批语句)形式执行;于是客户端将接收到个特定于要解决任务数据集合而今
当我们试图把“遗留”系统加入到较新应用中时又遇到了其它问题在经过多年来使用各种专利性技术和平台发布大范围系统后整个世界可谓“遍布”这种能够较好地实现“自身”工作系统;但是这些系统却往往缺乏清晰思路来实现和其它应用交互—悉知如今连接环境正变得越来越方便因此实现今天应用所要求灵活性已经变得相当困难B2B(业务到业务)应用甚至于使得事情进步复杂化
这要求必须满足特定标准并使用可靠思路方法来实现业务传输电子化非常明显满足今天全球业务环境需要不断演变系统都要求实现某种新架构这种架构必须能够高效地使用“遗留”系统并能提供个灵活商业基础框架为了满足这些需要
最近 3到 5年间已经出现了种“新”大规模、松耦合、分布式系统架构特别是作为因特网电子商务站点已经成长为其主要商业运作模式面向服务架构(SOA)已经开始作为主流松耦合、以服务为中心架构出现事实证明基于SOA应用更能经得起失败并且更为容易地按比例调整规模—通过使用多种思路方法添加必要资源来满足不断发展要求;而且它们也允许把“遗留”系统轻松地集成到现有B2B及其它系统中2、 面向服务架构对数据
要求在
个SOA应用中SOA服务提供者、服务消费者及其它组件都会将数据处理作为其自身角色个“自然”特征典型情况下个SOA应用仍然使用中央数据库来存储和保护数据;但是也有可能使用许多这种大型数据库来存储各类数据—例如单独存储销售、生产和操作数据以及每部分中特定数据子集等每个服务提供者和消费者都可能需要对数据或其自己特定数据存储进行本地缓冲此外跨越应用远距离部分传输消息本身常常就是些值得加以存档而备以后使用数据根据数据在系统中
特征我们可以按下列 4种方式对的进行划分:•①引用数据—用于创建服务请求(例如
个产品目录)它必须是以种为所有部分可用格式存在而且以种恒定不变方式(例如个目录日期)加以标识•②活动数据—是短暂
数据用于执行个特定活动例如个产品列表(用于从库存中检索购买项)既然它是私有于服务所以该格式不需要被其它模块所理解•③资源数据—是
种长期存在数据这种数据为个服务(例如顾客数据和帐户数据)内部使用•④服务交互数据—用于服务间
通讯这必须是以种为所有部分都能理解格式进行并且必须长期保持不变例如在服务的间以个订单表单形式进行通讯如果该订单被丢失那么它必须能够被以和以前相同形式重新生成并且被再次转换下图1展示了
些可能构成个松耦合应用(基于SOA原则进行构建)端点其中服务消费者可能代表个客户端应用;而个服务器应用(例如个Web服务器)或者是任何其它类型应用将把消息发送给个服务提供者在复杂系统中可能通过个消息路由器最初接收消息然后应用特定逻辑把该请求路由到适当服务提供者然后该服务提供者接收此消息并加以处理—解包并重新格式化它执行任何要求实现工作最后可能把个响应发送回服务消费者
图1.
个面向服务构架应用局部示意图上图1中向我们提供了
个重要细节—事务中每个结点都在以各种形式接收、存储和传输数据有时这些数据是“短暂”而有时每个结点可能会把数据存储到个缓存Cache或其自己本地数据库中基于在
个应用中这些新数据处理方式如今处于SOA应用核心位置数据库面临着些和以往N层应用区别挑战但是数据致性仍然同以往样重要;不过现在又出现了其它要求:1.数据库操作处于
种新环境—数据请求经由基于XML消息而不是通过专用连接方式进行;2.缓冲数据仓库部分需要了解何时刷新数据更为有效
而不是根据某个固定时间表实现刷新;3.数据库不得不参和以
种固定顺序发生“对话”;4. 存在复杂
逻辑必须宿主在数据库中(或宿主在这些数据库附近)今天
XML成为种应用于新代分布式系统良好消息格式这种格式能够为几乎任何系统容易地分析并通过某种模式建模语言来定义这些数据适当结构于是交换消息系统可以把信息依附到条XML消息中;结果当这些消息“流经”系统时数据将“汇集”于消息中系统只需分析和处理它们能够理解部分而忽略掉其它内容简言的设计XML目是为了作为种灵活格式来支持分布式系统微软
架构师们正是看到了这种结构化趋势及时地推出了新代SQL Server 2005以满足这种新挑战;而同时SQL Server 2005仍能继续支持许多现有非SOA应用本文中我们将全面探讨如何在个使用SQL Server 2005SOA应用中应用本地Web服务存取数据库改变通知Service Broker以及SQLXML等技术【阅读提示】本文将略去介绍SOA
基本知识同时也没有概括SQL Server 2005所有新特征而是假定你已经熟悉这些内容3、 SQL SERVER 2005适应SOA数据要求
随着我们对SOA概念
不断深入有个问题越来越明晰:组成整个系统每个组件都会把接收、处理和传送数据作为自身主要功能的即使个服务提供者对于条发送自某个服务消费者消息响应只是简单地进行“位”设置(置为“on”或“off”)而根本不必和个数据库交互此提供者也必须处理该消息中数据以便确定相应任务事实上现代商业应用通常会广泛地和数据打交道;所以对于个SOA组件来说常常会存取个本地或集中数据库或经常 2者兼有SQL Server 2005提供了
组新特征来进步方便集成化结构化设计—支持把数据库作为个SOA服务提供者使用微软SQL Server 开发小组称这组新特征为“面向服务数据库架构”(或简称为“SODA”)直接在数据库引擎中实现SOA特征存在如下重要理由:
- 调整系统规模即使在最大企业SOA应用中单个服务也可能按几乎任何规模被例子化;个使用不太频繁服务有可能具有比个典型小型部门数据库更少活动和SQL SERVER集成到起意味着个服务可以利用所有本地支持来适应从嵌入式设备到最为丰富企业数据库服务器而不必改进管理复杂性服务逻辑代码可以在任何规模下执行而任何实现都可以在发布时刻被调整到个单独中间层中借助于SQL SERVER 2005服务逻辑可以在数据层上运行或者被发布到中间层中如果你仔细地设计个应用那么你会注意到如何调整问题将会是种发布决策而不是项设计或开发时刻决策
- 按比例调整你可以通过许多方式来按比例调整以数据中心计算通常以按比例调整数据库或通过使用面向服务架构方式来分布这些处理按比例调整数据库将会导致个数据库簇—而它是紧耦合;而相比的下面向服务方案导致更为松弛耦合度直接通过数据库支持SOA构建有助于减少在个真正网格方案中组件处理问题
- 消息作为数据各种请求和响应消息都成为些“有趣”数据—把它们存档到个数据库中可能有重大价值保持这些消息长时间可用则为我们提供了种历史数据从而便利了以后审计和事务分析消息存储在表格中并且有系统目录视图可用所以你可以很容易地使用Transact-SQL来观察任何系统部分状态
优点也只有这样它才有理由充当个SOA应用中个独立服务提供者为此它必须能够实现类似个服务提供者行为对于SQL Server 2005(或任何数据库引擎)来说
要承担起作为个独立SOA服务角色它必须实现若干超出其本地数据处理能力特征:- 端点(End Po
)支持SODA提供者必须提供通信支持以接收和传输消息典型情况下这可以通过个TCP套接字HTTP GET或PUTSOAP端点或其它类型端点实现 - 过程服务请求大多数SOA消息要使用XML方式加以格式化;因此服务提供者必须能够处理并且可能要把打包数据转换成其它形式以满足组成服务组件需要它还必须能够参和复杂对话和会话—而它们将作为相互依赖消息由其它组件接收或发送到这些组件
- 服务逻辑宿主提供者必须能够执行要求任何复杂程度逻辑来处理消息并提供必要响应而且还可以协调若干其它服务输入;而这可能要求普通应用服务器任务例如对资源进行“池”存储激活以及按规模调整处理逻辑
各种新特征为这些功能提供了支持;此外还提供了其它基础性结构来支持数据管理例如个服务提供者必须安全地加入到个SOA系统中并且能够对客户端实现认证而且提供凭证来实现对其它实体认证提供持久性参和会话和事务及其它应用级特征SQL Server 2005建立在SQL Server 2000关系数据库引擎特征的上
以及自从它最初发行版本以来所开发新技术(例如SQLXML 3.0通知服务以及其它工具)从而全面实现了面向服务数据库架构4、小结
本篇中
我们仅粗略地分析了SOA出现缘由及其对数据存储新要求并进而简要概括了SQL Server 2005对这种新式数据要求所提供支持在下篇中我们将展开SQL Server 2005对SOA架构支持全面探讨
最新评论