Enterprise Engineering Forum

企业工程论坛
Categorized as: 系统实现,系统架构   Tagged as: ,, ,

面向服务体系架构(SOA)和数据仓库(DW)的思考

Author: 肖建国,  Source: 企业工程论坛,  Published: 2010-10-01

Excerpt: 当前业界对面向服务体系架构(SOA)和数据仓库(Data Warehouse,DW)都介绍的很多,提出了很多优秀的解决方案,但是一般是把 SOA 和 DW 单独考虑,SOA 和 DW 有着共同的目标——系统整合,由于基于不同的技术思路,提出了不同的方案。本文将围绕 SOA 和 DW 相结合的思路,基于 IBM 的产品,规划统一的数据库,搭建企业级的技术架构。

概念

随着 IT 技术的发展,SOA 和企业架构(Enterprise Architechture,EA)逐步融合,形成了新的架构理论,但是与 DW 之间还没有很好的集成。下面首先来看看 EA、SOA 及 DW 概念。

企业架构的概念

企业架构(Enterprise Architecture,EA) 的概念产生于 1987 年,在 IBM 的一个内部刊物上发表的一篇文章”A Framework for Information Systems Architecture” by J.A. Zachman ( 扎克曼 ) 中提出。概念的提出是为了应对日益复杂的 IT 系统,以及高投资、低回报的问题。他认为使用一个逻辑的企业构造蓝图(即一个架构)来定义和控制企业系统及其组件的集成是非常有用的。为 此,Zachman 开发了信息、流程、网络、人员、时间、基本原理等 6 个视角来分析企业,也提供了与这些视角相对应的 6 个模型,包括语义、概念、逻辑、物理、组件和功能等模型。随着 EA 的发展,产生了很多的流派,当前主要的 EA 架构包含:通用框架 Zachman、TOGAF(The Open Group Architecture Framework)、以及适用于政府和军方的美国联邦政府的标准架构 FEA、美国国防部的 DoDAF 等。这些模型主要分成两派,如今正在逐步的融合在一起。随着企业架构的不断进化,企业架构理论越来越与战略和业务相融合,逐步形成了企业战略、业务架构、 IT 战略、IT 架构等四个层次的 IT 规划方法论。IT 架构包含数据架构、应用架构、技术架构和 IT 治理等四个方面的内容,其中技术架构包含集成平台、公共服务平台、基础平台(软件和硬件)和安全平台等,如下图所示:

图 1. 企业架构(EA)示例

本文以下主要从技术架构中的集成平台角度来看如何搭建应用集成平台和数据集成平台。

面向服务的体系架构

面向服务架构(Service Oriented ArchitectureSOA) 是一种架构 IT 系统的方法,它将应用和 IT 功能划分为单独的业务功能和模块,即所谓的服务。用户可以构建、部署和整合这些服务,且无需依赖应用程序及其技术平台,从而提高应用的灵活性。这种业务灵 活性可使企业和机构加快发展速度,降低总体拥有成本,及时、准确地获取信息,同时有助于实现更多的资产重用。而建设 SOA 体系架构就需要建立一个一致的架构框架,在这种框架中,可以快速地进行开发、集成和重用应用系统。而对于原有的应用系统来说,可以采用合适的技术手段进行 平滑的优化与过渡。

数据仓库

数据仓库(Data Warehouse,DW) 是一个面向主题、集成、时变、非易失的数据集合,是支持管理部门的决策过程(W . H . Inmon)。数据仓库具备以下四个关键特征:面向主题 (Subject Oriented) 的数据集合;集成 (Integrated) 的数据集合;时变 (Time Variant) 的数据集合;非易失 (Nonvolatile) 的数据集合。根据数据仓库所管理的数据类型和它们所解决的企业问题范围,一般可将数据仓库分为下列3种类型:操作型数据库(ODS)、数据仓库(DW)和 数据集市(DM)。

  • 操作型数据库(ODS) 既可以被用来针对工作数据做决策支持,又可用做将数据加载到数据仓库时的过渡区域。与 DW 相比较,ODS 有下列特点:ODS 是面向主题和面向综合的;ODS 是易变的;ODS 仅仅含有目前的、详细的数据,不含有累计的、历史性的数据。
  • 数据仓库(DW) 为通用数据仓库,它既含有大量详细的数据,也含有大量累赘的或聚集的数据,这些数据具有不易改变性和面向历史性。此种数据仓库被用来进行涵盖多种企业领域上的战略或战术上的决策。
  • 数据集市(DM) 是数据仓库的一种具体化,它可以包含轻度累计、历史的部门数据,适合特定企业中某个部门的需要。

主数据

主数据(Master Data,MD) 指系统间共享数据(例如,客户、供应商、账户和组织部门相关数据)。与记录业务活动,变动较大的交易数据相比,主数据(也称基准数据)变化缓慢,一般每年 的变化在 20 %左右。在正规的关系数据模型中,交易记录(例如,订单)可通过关键字(例如,订单或发票编号和产品代码)调出主数据。根据主数据管理实施的复杂程度,参 照 Jill Dyche, Evan Levy 的观点大体可以把主数据管理可以分为五个层次,其中 Level 3(通过集中的总线处理,类似于翻译器)可以实现企业内任意两个系统交换数据。Level 3 是将数据转换逻辑集中化和标准化,它支持主参照数据的分布式存在(即分布的主数据存储,集中而标准的主数据转换),Level 3 打破了各个独立应用的组织边界,使用各个系统都能接受的数据标准统一建立和维护主数据 (MDM ) 。而最高级别 Level 5 (企业数据集中),当主数据记录的详细资料被修改后,所有应用的相关数据元素都将被更新,本级别可以通过 SOA 的架构平台实现。

通过对以上几个概念的简单分析,可以发现,SOA 虽然解决了系统之间的数据实时交互的问题,但是数据的集中,大数据量的数据同步以及主数据管理等问题还没有解决,即使建立了 SOA 的应用架构,仍然需要进一步进行数据仓库的建设和主数据的管理等。于是有了建立统一的应用集成平台和数据(信息)集成平台的概念。

SOA 和 DW 结合的企业架构

把数据和服务作为企业的资产

通常,软件重用(Software Reuse)是利用事先建立好的软产品创建新软件系统的过程,早在 1968 年的 NATO 软件工程会议上就已经提出可复用库的思想。重用在形式上 可以分为二进制、源代码、设计、分析等四个层面的重用,其中基于二进制代码的重用最为重要,从当前来看,基于二进制和源代码实现重用的方式主要有函数库 (面向过程)、对象(面向对象)、服务(SOA)等方式。基于设计和分析实现重用的方式主要是通过模板进行定制,当前主要采用 MDA 的方式,由设计文档直接生产代码。

要实现基于二进制代码的重用,最重要的一个方法就是实现分离,通过分离,将共用的或者相关性不紧密的功能分离出来,如操作系统、数据库、应用 中间件、公共组件等,都是在软件发展历史过程中逐步从一个完整的一体化的系统中分离出来的。这也符合社会分工的要求,每个企业有多个开发商,即使同一个开 发商,由于需要多人的分工合作,这时分工不同部分之间的标准就显得尤为重要。因此,可以说软件的核心是重用,方法是分离,关键是标准。围绕这个思路,在本 架构中将企业的所有数据独立出来,基于数据架构,建设数据集成平台;将企业的所有应用组件分离出来,基于服务总线,建设应用集成平台。数据集成平台和应用 集成平台共同组成企业的业务基础平台。未来的企业只有一个数据库,一个应用,所有的用户登陆一个系统可以完成所有的工作,系统的开发则可以基于一个业务基 础平台,由多个厂商共同完成,形成一个企业的“云”,其中数据和 Web 服务是最核心的两个资产。

应用集成平台由企业服务总线(ESB)和公共的业务组件组成。ESB 将不同的组件互相衔接起来,在两个或更多的组件或系统之间实现无缝集成,使整个信息系统就像一个整体一样。通过统一购买、开发或者封装已有的组件和系统建 设公共服务组件,形成企业共享的公用服务平台,避免重复开发、重复购买、标准不一致等问题。其中公共服务组件包括了门户组件、统一认证组件、工作流组件、 GPS 组件、GIS 组件、BI 组件、通用报表组件等。

关于企业服务总线(ESB)和业务组件,相关的介绍很多,本文不做过多的描述,以下重点对数据存储层进行规划设计。

数据集成平台

对于一个企业来说,最理想的状况只有一个数据库,一个应用,但是需要考虑不同业务系统间的相互影响,例如:一个业务系统的性能问题会影响到其 它系统,业务的新增、变更都会对其它系统有一定的影响,争抢已有系统的 I/O、CPU 资源等,因此,一个数据库是逻辑上一个库,可以物理上分开部署,包括采用数据库分区和数据库集群等技术;应用可以通过集群的方式解决性能问题,应用集群运 行所有的业务组件,组件之间通过数据共享或者 Web 服务调用的方式实现互联。如果是遗留系统或者是产品化的系统,则通过主数据管理、SOA 集成以及数据仓库的 ETL 等实现集成,关于数据集成平台,如下图所示:

图 2. SOA 的 DW 架构

数据存储层规划

为了保证业务系统的性能同时实现数据的共享、数据分析的需要,将数据存储层的数据分为三个层次:私有数据层、共享数据层和分析数据层。共享数据层主要的目的是为了数据共享,考虑到性能问题,应避免直接基于共享数据层进行业务操作。

三个层次准确的命名应该是私有操作数据层、共享数据层、私有分析数据层

1、私有数据层:由一组业务专用数据库组成,这一层的数据集主要用于支撑企业的运营,是典型的操作型数据环境。包括经营、财 务、人力资源、资产管理等已有系统的数据库,其主要职能在于支撑企业日常的经营和管理活动的运营需要。未来新的业务组件基于共享数据层进行开发,不在共享 数据层的数据也在私有数据层,特别是新的业务组件自己内部处理过程中产生的数据。私有层的数据,其他的系统或者业务组件除了通过 web 服务调用之外不能直接访问。

2共享数据层:该部分整合所有企业内外数据源,基于企业完整的数据架构进行建设,是所有已有系 统和业务组件共享的数据库。共享层的数据结构清晰,基于业务对象,易于理解,和 Web 服务一样,是企业的资产,私有数据层的数据通过实时或者准实时的方式同步到共享层或者基于联邦技术直接基于共享层进行开发。共享层基于主题建模的明细数据 和部分汇总数据,是新的系统的业务数据库和数据计算、企业报表的数据源,是对外数据的统一接口。

共享数据层包含业务共享数据、主数据、系统数据、流程数据和元数据。其中业务共享数据主要包括基于主题的数据模型,是交易类的数据,特点是数 据变化快,数据量大;主数据是基础数据,数据变化慢,数据量小,但是查询量大;系统数据主要包含用户数据、功能数据、用户权限数据等,和门户系统结合;流 程数据是跨系统的流程数据,是未来工作流处理、流程监控,和审批平台的公共流程数据。

业务共享数据库定位为运营数据存储和业务支持,负责收集企业各系统中的数据,统一存储在业务共享数据库中,作为企业的共享数据。业务共享数据 库采集了企业各系统的业务数据,对源系统的数据质量进行审计监控,同时按照企业统一的主题域数据模型对数据进行整合转换,并为其它业务应用系统提供跨域的 数据共享。由业务共享数据库统一向各业务系统提供数据共享服务,同时业务共享数据库也可以作为新的系统开发的业务数据库。考虑到业务共享数据库是比较中立 的数据,在基于业务共享数据库进行新的系统开发的时候,建议跟业务无关的数据单独建表,并和业务共享数据库的数据区分开,作为新系统自己的数据,存放在私 有数据层。对于现有的系统,在升级改造的时候将现在的通过 ETL 抽取的方式改为由原系统直接集成的方式,将数据存放到业务共享数据库中。业务共享数据库也作为 DW 的理论上唯一数据源,为 DW 提供高质量的数据;DW 中的挖掘和分析结果也要回写到业务共享数据库中。

3、分析数据层:该层的数据集主要用于支撑企业的管理和决策需要,是典型的分析型数据环境。它从数据仓库中提取数据并整合管理 决策所需要的数据集。通过数据仓库的建设,对现有各类分布数据源进行数据集中,经过进一步对数据的清洗、过滤、转换后加载至数据仓库中,为数据的集中存储 管理和分析利用提供数据支撑环境。

以上通过基于软件重用的思想,描述了需要构建数据集成平台的概念,并对数据平台的功能和数据存储做了说明,通过分层的数据管理,建立企业统一的数据集成平台。

基于 IBM 产品体系的实现

技术架构概述

根据前文提到的业务基础平台,基于 IBM 的产品体系,在实际搭建的时候,需要的服务器包含数据库服务器(产品:DB2)、应用服务器(产品:WAS)、流程整合服务器(产品:WPS,实现服务总 线和流程编排)和信息集成服务器(产品:WII,实现数据的 SQL 复制或者 Q 复制),如下图所示(本方案是建议方案的一种,如 ESB 可以选择 WESB、DataPower 或 WebSphere Message Broker 等,需要根据不同企业特点进行选择):

图 3. 网络拓扑图

产品实现

数据库服务器(IBM DB2 Enterprise ServerDB2),DB2 在本方案中主要实现数据存储层的建立,包含私有层数据库、共享层数据库和分析层数据库。如前文所述,考虑到遗留系统、产品化软件,特别是性能问题,在实际 部署的时候需要考虑私有层数据库可以单独在一个表空间甚至是一个独立的磁盘中进行存储,保证业务组件能够不受其他业务组件的影响,数据存储层能够灵活的扩 展,适应大数据量、多系统的处理。

DB2 提供多平台支持,因此能够在各种系统平台上发挥该产品的功能。DB2 能够管理多种数据类型,并能联合各类 IBM 系列数据库上的关系型数据。DB2 允许数据库管理员把数据库划分成若干称作表空间 (table spaces) 的部分,表空间可以单独管理,这就大大增强了管理特大型数据库的能力,它能包含上兆兆字节数据。DB2 在 SMP(对称多处理器)或 MPP(并行节点机) 环境下,都可充分发挥其并行处理能力,特别是当数据量累计到一定程度,通过 Cluster(集群),作为并行关系数据库它允许把单个数据库映象散布到多个系统上,从而能利用所有系统的处理能力以满足用户对数据的需求。DB2 可以在并行处理的多个节点上同时运行某一查询,从而提高查询性能,必要时它可以重新编写查询以优化性能,从而保证了可以实现一个数据库的设计理念。

通过多种数据类型、多平台、表空间、集群处理、并行处理等技术,可以实现数据存储层的统一管理。

信息集成服务器(IBM WebSphere Information Integrator,WII)信息集成服务器实现信息总线功能,主要包含数据联邦和数据复制功能,通过数据联邦和数据复制实现私有层数据和共享层数据的同步。

联邦技术 能够统一地访问以任何格式(结构化的和非结构化的)存储的任何数字信息。WII 支持多种数据源,包括 DB2/390, DB2/400, DB2 UDB、Informix、Oracle、Sybase、SQL Server 等关系型数据库,也包括非关系型的文本文件和 Excel 文件。通过对各种数据源的支持,可以在逻辑上实现不同数据库的统一视图。

数据复制,在多个厂商的数据库产品之间实现复制,WII 使用基于 SQL 的复制架构,该架构可在管理计划、转换和分发拓扑结构中最大限度地提高灵活性和效率。在 SQL 复制中,WII 使用基于日志或基于触发器的机制捕获变更,并将其插入到关系分级表中。然后应用过程异步处理目标系统的更新。WII 可以广泛应用于填充仓库或集市、在不同应用程序之间维护数据一致性或者在总部和分支机构或零售商之间高效管理分发和合并。该技术采用经典的数据库复制体系 结构实现,IBM 的基于队列的新复制架构(简称 Q 复制技术),是一种高吞吐量、低延迟的复制方法,它使用 WebSphere MQ 的消息队列在源数据库与目标数据库之间,或者在源子系统与目标子系统之间传递事务。Q Capture 程序通过读取 DB2 的恢复日志来获取你所指定的复制源表的变化情况;继而,Q Capture 程序将事务作为消息,通过队列发送;最后,Q Apply 程序从队列中读取这些消息,并将其应用于目标表。

通过 WII,将分散的数据库以数据联邦或者数据复制的技术集成起来,实现数据层面的集成。

应用服务器(IBM WebSphere Application Server,WAS,WAS 所有业务组件的运行的容器,实现统一的应用集成平台。应用集成平台需要主要考虑应用集群技术。

WAS 完全提供了独立于硬件系统的集群功能。在 WebSphere 应用服务器中,提供了两种方式的 Cluster:垂直的方式和水平的方式。它们分别是为了适应不同的应用环境而设置的,垂直的 Cluster 允许在一台机器上实现动态负载均衡;而水平的 Cluster 允许在多台机器上实现动态的负载均衡。二者可以有机的协调工作,为复杂环境的应用实现负载均衡提供了强有力的保证。WebSphere 使用的是一种 Nanny — Administration Server — Application Server 的体系结构,使用该结构,所有的 Application Server( 应用服务器 ) 将由一个 Adminisration Server( 管理服务器 ) 来监视管理,一旦由于一个特殊的原因(例如进程被杀掉)导致应用服务器停止,管理服务器将自动重新启动该应用服务器;同样,Administration Server ( 管理服务器 ) 由一个“Nanny( 保姆 )”进程管理,该“保姆”进程一旦检测到管理服务器停止也将自动重新启动它。这样 WebSphere 从体系结构上就最大限度地保证服务器程序的可靠稳定运行。

通过 WAS 的独立硬件的集群功能,实现垂直或者水平的两种方式,从而保证业务组件统一管理。

流程整合服务器(IBM WebSphere Process Server ,WPS)服务总线和流程编排,实现基于 Web 服务的数据同步,业务组件之间的服务调用等。

WPS 是一个基于 WAS 的全面的面向服务的体系结构的集成平台。面向服务的体系结构提供了动态开发和修改集成应用程序的功能。通过面向服务的体系结构,可以将现有应用程序与更新 的应用程序相集成,以便它们透明地协同工作。WebSphere Adapters 包括特定于应用程序的适配器(例如:用于 Siebel、SAP 或者 PeopleSoft 的适配器),以及技术适配器(例如:用于关系数据库或者平面文件的适配器)。WebSphere Adapter 完全符合 JCA 1.5 的架构,可以方便地在 WPS 中使用。通过 IBM 提供的丰富的 WebSphere Adapter 产品,可以轻松地操作已有业务系统中的数据,从而实现对现有 IT 资产的重用。WebSphere Process Server 中的唯一体系结构允许将业务功能封装到各个模块,然后单独进行更新。例如,可以使用包含用于实际审批的人工任务的审批模块,随后使用包含业务规则的另一个 审批模块替换它。这一更改对于该模块的使用者是完全透明的。此外,封装的概念确保了数据和接口定义在使用它们的位置封装。例如,可以隐藏如何在模块内的后 端系统中表示使用者的细节,而模块本身将具有一般业务对象的通用接口作为数据公开。这一规范的数据表示还启用了任何给定集成应用程序中的高度重用。

通过 WPS,搭建企业服务总线,实现基于 Web 服务数据同步和组件之间的整合。

以上通过对技术架构总体概述以及采用对应的 IBM 相关产品的具体实现,根据 IBM 产品所具有的产品特性,论证了 SOA 和 DW 结合的企业架构实现的可能性。

总结

本文基于企业架构(EA)、面向服务体系架构(SOA)、数据仓库(DW)、主数据(MD)等概念,构建了数据集成平台和业务集成平台共同组 成的企业级业务基础平台,重点描述了基于 SOA 的数据集成平台中数据存储层的建设方案,提出了将数据和服务作为企业资产管理的思想,方案实现了数据和应用一体化设计,并在最后给出了基于 IBM 产品体系建设的建议方案和产品的定位。

(本文最初由 IBM developerWorks 中国网站发表(链接),此版本略有修改)

Copyright

  本发布物版权归原作者所有,经原作者许可在企业工程论坛(EE-Forum.org)公开发布,并允许个人及公益性机构非牟利性使用及传播。传播中需保持从标题、署名到各项内容及此声明包括链接地址等完整内容不变。引用或摘编文中内容或观点应符合公认准则。其它机构,或牟利性使用,请预先取得作者许可。保留一切未说明的权利。
  详细说明见: http://www.ee-forum.org/about/copyright ,管理者电子邮箱:admin(at)ee-forum(.)org

Cite Style

GB7714 style: 肖建国. 面向服务体系架构(SOA)和数据仓库(DW)的思考[EB/OL]. 企业工程论坛, http://www.ee-forum.org/wp/pub/davidxiaocn/2010-10-p1655.html, 2010-10-01[2017-10-21 06:22]

Chicago style: 肖建国, "面向服务体系架构(SOA)和数据仓库(DW)的思考", 企业工程论坛, http://www.ee-forum.org/wp/pub/davidxiaocn/2010-10-p1655.html(accessed 2017-10-21 06:22)

Posted by   2010-10-01(修订重发)   Hits 33368   Modified 2010-10-09(Locked)
Prev Post: 
Next Post: 

Related Entries:

基于SOA的组件化业务基础平台
一个模型驱动企业应用平台架构方案框架
什么是服务
基于SOA的业务流程管理(BPM)和工作流(WF)
企业应用与信息系统架构及模型驱动系统MDS(三)

17 Comments

  1. 本文的思路,和企业工程论坛以往一些文章,如《综合信息系统开发途径与策略分析》、《功能还是资源——信息系统的两种开发途径》、《以数据库为中心与面向数据库》等提出和探讨的思路相近或关联。

    这类思路目前在业界基本被各种“新潮流”淹没,常不为新锐们所理解乃至误解。一些走极端,或者难免哗众取宠之嫌的说法,喜欢把自己追捧的新思路和其它东西对立起来,动辄宣判“XX已死”(比如所谓“数据库已死”,或者把基于数据库的开发与较为新的应用开发/实现思路分裂、对立起来)。

    实际上,绝大多数情况下,技术的发展都是在继承与综合的基础上,即使是很久才可能遇到一次的真正的“革命”性的跃进也往往如此。

    留意本文提到了“企业架构”,但我认为其内容主要探讨的是应用系统的技术架构,文中“SOA 和 DW 结合的企业架构”这个命题是暧昧和容易引发误解的——文章在这个标题下讨论的就是企业应用的技术架构而非企业架构。

  2. 企业内部使用的话,也许没必要这种服务架构,
    企业间使用的话,服务架构有必要,但数据是个问题,这种应用环境下,可以绝对的说,谁提供了服务,这些服务相关的数据就放到谁那,首先是私有,其次才是有条件的共享。里面还是问题多多的。

    • 我的看法是,从企业内部对这类架构的需要,或许更能联系到深入的问题。

      有些老生常谈的话题,比如所谓“数据孤岛”问题(在《功能还是资源——信息系统的两种开发途径》从“信息孤岛、断层与冗余”角度进行了一些表述),要想真正突破,都与此有关吧。

      企业应用因为无法实现在一个理想化的集成应用系统中解决所有问题——恐怕每家企业应用供应商都知道这个梦想(这更折射在那些超级企业的产品战略中),但那恐怕永远是一种天方夜谭。所以必须有一种“公共的”、开放的架构。其中“数据”的独立性,是早晚要迈的一道门槛。

      • 《以数据库为中心与面向数据库》一文,思路颇为相近。

        这个思路除了来源与SOA、DW的概念之外,还有一个在80年代的企业数据库的概念〔即认为一个企业应该只有一个数据库〕,因为过于庞大,失败了,而共享库是走了一个中间路线。

    • 这个架构,主要是考虑了几个方面:
      1、SOA的服务,对于处理大数据量,并不擅长,所以现在企业内部存在众多的中间表。共享库是解决了中间表的问题
      2、SOA往往和DW是分开的,并没有很好的解决,这个架构实际上是借鉴了SOA和DW的思路,SOA和DW应该是结合的,而不是各自为政。现在很多方案两者几乎没有什么关系
      3、“这些服务相关的数据就放到谁那”存在的一个问题,就是一旦换掉原系统,原有的数据就需要整理,甚至可能变为无效数据。共享库让数据成为企业的资产

      • 一句话:业务数据是属于企业(用户)而不是应用系统的,必须能够独立于应用。但是几十年来,信息工程思路式微了,信息资源管理始终是偏房,这个门槛始终没法迈过。当然,有些人不那么想迈过的。

  3. 特别值得一提的,比DW更广点看——关系数据库,乃至“数据库”(database)这个概念最初的提出与设想——这个思路的基本思想就是数据/信息的独立性……

    • 我主要想强调SOA会不会造成数据的私有化。
      比如,我的应用中缺个收款,我可以连接到支付宝,我要是缺个补货单,我就可以选用第三方的补货单服务,这样的话,交易信息、补货信息都归第三方各自所有,势必会造成数据的私有化。这个是显而易见的,比如淘宝,永远都不会真正开放会员、交易数据的,这是它活下去的根本。所以,基于SOA的应用朝这个方向发展,不知道未来,数据私有化了之后,还会什么样?
      也请余老师发表高论。

      • 从这个点切入讨论很有意思。

        从某种角度看,SOA表现为一种“解耦”机制,例如具体的操作(比如,某客户端功能)和所涉及的数据(比如,某数据库中的数据)之间的解耦。

        这种解耦,对数据私有化和共享两方面都可以提供帮助:前者例如,现有(遗留)系统的数据是高度私有化的,可以通过SOA实现集成;后者例如,基于公共数据库及其基本操作(服务),通过SOA,支持各种可能功能的动态连接。

        所以问题在于架构师如何运用SOA,我认为它比目前业界主流们所表现出来的理解更基本。

        • 就电子商务这个应用领域来说,我觉得未来也许会朝着私有化的方向发展:我随便拿个电脑就可以开店,我没电脑,用手机也能开店,交易数据都在我这里,我可以方便地加入到某个品牌的销售网络里,也可以单干,我的数据我全部拥有,不会再受谁的制约。

          • 我觉得你这个说法的背景需要澄清:所谓“私有”,到底是“谁”有?客户端程序?乙方电脑上的公共服务系统?第三方电脑上的某个系统?

            这里“私有”这个词的操作语义其实是含糊的。传统的(比如C/S架构应用),你若想使用别的应用所拥有的数据,亦可以直接连接到它的后台数据库上。但即使仅仅是读取数据,亦难免遇到许多问题,所以很少允许这样做。

            按照SOA,则应在数据库上创建一个通用/开放的“数据服务”,其它应用可以按协议使用这个服务。

            所以说“解耦”比说“私有”更好一些。这里的一个关键是,在哪个位置上解耦。

          • 关于私有,看是针对谁,对于外人来说,支付宝数据是私有的,但是服务是开放的。但是对于一个企业来说,企业内部的数据应该是共享的,比如,我想查看所有的支付记录,除非是有一个服务是可以提供所有的支付历史数据。〔这样的问题如何提供大数据?如果数据量大可以解决性能问题,也就是说其实际上是共享了数据的,只不过是通过服务提供〕

            支付宝是不肯能提供数据结构给别人的,但是在企业内部是需要一个共享数据的。

            网上开店,是不需要了解数据的,但是如果企业自己搭建一个架构,是需要了解数据的。

          • 这就是“私有”这一笼统说法背后具体的操作语义。这涉及数据的拥有权(资产意义的)、操作的权限(业务授权意义的)、程序的访问途径(软件意义的)、甚至还有数据维护权(所谓DBA),以及数据存储层面的,等等,它们都是可分开而又关联着的。在这些错综复杂的关系中,我认为有一个要点,就是面向数据还是面向功能。

            这是一个“深刻”的分水岭。我认为肖君的思路,也指向这个问题(或者至少是隐藏着这样的背景)。

            顺便说:面向对象(OO)在这里其实是充满暧昧的;面向服务(SOA)同样如此,面向数据还是功能,和对OO、SOA的深层次理解密切相关。

  4. 还是你们说的严谨透彻,下面这句说的很好:
    “按照SOA,则应在数据库上创建一个通用/开放的“数据服务”,其它应用可以按协议使用这个服务。”

    我说的私有,是指用户使用第三方提供的服务,产生的数据往往归服务提供方所有(被第三方私有)。之所以用“私有”这个词,是因为讨论的问题是电子商务发展的方向而不侧重系统构造。

    说到解耦,从实现角度,SOA,我想它就是对传统的web应用的改造,在数据访问层这个位置做了分离,使其不再是直接访问本地数据库,而是对远程服务(可以简单的认为是对传统web应用的数据访问层的一个服务包装)的调用,被调用的目标数据库和那些服务放在一起。

  5. 网上开店,也需要了解数据的。
    比如一个品牌企业,必须通过数据了解顾客的消费趋向。所以,往往自己建站,就是为了完全拥有这些数据。

    这种需求对电子商务乃至系统的构造的演变,我看的不是很明朗。

    • 我觉得,现在,特别是互联网环境下企业应用的开放性和多样性,造成类似问题变得难解。系统的边界、相互的关系空前复杂。这时,从纯技术的立场出发,很容易迷失方向。

Leave a Response

You must be logged in to post a comment.