DAT221面向服务的数据库结构SODA=Service-Oriented-Microsoft.PPT

DAT221??面向服务的数据库结构 (SODA=Service-Oriented Data Architecture) How SQL Server 2005 Fits into SOA World Courtesy of David Campbell General Manager SQL Server Microsoft Corporation 内容 数据的自然规律 面向服务的数据 (data in service world) SODA 简介 SQL 2005 中和 SODA 有关的功能 Q A 数据的大势: 分久必和,和久必分 过去 30 年的趋势是将数据整合一起来展现 (data consolidation) SOA 和 分布式系统倾向于将数据分开 面向服务结构(SOA)中的数据 SOA 在数据上的操作 打破数据的整体性 数据分布得更广 认识到数据的分类 对不同的数据的不同操作 SOA → 事件驱动的系统 松藕式联结 不同种类的系统 时间 加密 一致性 vs 距离 事务操作 (Transaction) 将数据库从一个统一状态带向另一个统一状态 跨越空间和时间实现这一点是困难的 可尝试的方法 2-phase commit Optimistic CC Replication Resilience and Correctness 五十年代的订单处理 参考(引用)数据 用于产生服务要求 有被各方接受的格式 任何人都可以读目录 有自己的名字(Has a stable identifier) 例: 2005年3月份产品目录 服务要求引用 例: 2005年3月份产品目录,第64页,第23项 可被无限的复制和缓存(cached) 不需要100%的反映真实情形 客户可以用3月份的目录在4月1日定货 有关行动的数据 通常只在商业行为其间才有意义 (订货, 往来, etc.). 数据生命较短. 可能被存来作商业报表. 格式一般是内部的 Generally keyed to business activity 订单#268缺货 可被分区 不需移动数据就可分区 (Ephemeral – evens out over time) 有关资源的数据 数据生命比较长. 库存单位, 客户, 帐户… 格式和改动归服务内部 并发性极强 某货物的库存情况可以被多个订单所改动 重新分区将需要移动数据 Re-partitioning requires moving entries 服务中互动的数据 服务之间唯一的交流方法 格式必须被各方知道 每一方都能读懂订单 Everyone can read and interpret the “order form” 可能会遗失 信件, 电子邮件, 互联网, 等. 加入遗失, 应送出另一份 这一份最好是原件的拷贝 (exact same) 不同数据类型的观察 不同类型的数据有不同的特点 Data Semantics Constraints Intra-service data is different from inter-service data Must be understood by all parties Intra-service data controlled and manipulated by service logic May be stored manipulated in Relational, XML or Objects Consider different forms Reference, Activity, Service Interaction Resource 部署方案一Single Tier Client/Server 所有数据一起改动 服务互动数据间接而来 订单数据从表格来 所有数据被当作一种来处理 部署方案二Multi-Tier 参考/引用数据被克隆和缓存 行动数据和后台进程 “紧藕合” 应用程序以对话形式“Session” 连接到应用程序服务器上 部署方案三完全分布式的连接应用程序 数据库扮演什么角色? 在SOA中数据库的角色? 参考/引用数据的缓存管理 服务互动数据 (Message) 的处理 行动数据的管理 连接对话 → 事件驱动 需要面向服务的数据库 Need Service Oriented Database Architecture (SODA) 面向对话的数据库 输入数据和事件被应用程序处理 被动的数据 数据和逻辑, 行为的绑定比较少 面向服务的数据库 服务逻辑和下列绑定: 服务 Services 查询提示 事件 Events 服务逻辑被下列触发: 数据的改动 消息(message)的来临 定时器 数据变成主动 SODA 必须有如下功能