今天,大多数 SOA 设计技术都是以定义服务为中心的。它们使用面向服务的分解原则,以业务流程为基础、企业业务 / 功能模型,要求的长期架构性目标和现有企业功能的重用。这种方法通常将现代企业最重要的资产之一——企业数据事后整合。
典型的 SOA 实现有效地引入了两种不同的数据模型——被服务接口暴露的“外部数据”和被服务实现使用的企业数据——“内部数据”。尽管典型的 SOA 实现在服务接口后面隐藏了企业数据,它仍然需要解决下面的数据存取问题:
- 统一多应用系统间的数据。今天的企业数据一般分散在多个应用系统,这些数据在应用系统之间常常存在重复。这种应用间的数据冗余造成了不准确的企业数据描述,以及应用间需要的定期数据同步。此外,数据描述自身也因应用的不同而不同。这导致通常很难去调和单个应用系统的数据描述。随着单个应用的独立发展和进化,问题变得更加复杂。
- 服务对企业数据的所有权。问题在于功能和数据的分解完全由不同的规则驱动。功能分解是基于企业业务流程——企业功能;然而,数据分解基于企业数据的分类法——企业数据模型的基础。
- 接口定义。服务接口倾向于粗粒度的设计;而数据接口则倾向于细粒度的设计。
有好几种设计模式旨在使 SOA 实现支持企业数据,下面是三种最重要的。
- 使用业务服务协调企业数据支持。这是今天 SOA 实现的主流模式,与所有的 SOA 实现都合作得很好。在这个模式里,企业数据存取已经合并到业务服务实现中。数据通过集成层存取,服务实现自身负责定义和支持对特殊数据集的验证、存储、检索规则。
- 将企业数据存取封装为业务服务。克服上一个模式缺点的一种方法就是将企业数据存取当作第一级的业务服务。在这种方式下,业务服务的一种特殊类型——数据服务——封装了所有企业数据存取、同步、验证、转换需要的逻辑。
- 企业数据总线。从大多数方面来说,这个模式类似上面描述的企业数据存取服务。与将数据存取提升为第一级的业务服务不同的是,在这个方法中,这个模式作用在集成层上,它提供了任意服务直接访问企业数据任意部分的功能。这种实现增加了额外的一层——企业数据总线,它提供对包含于企业应用或是应用下属数据库中的企业数据的存取。这也修改了企业组件层的实现;在这种实现中它不再包含“包装器”组件。这种情况下,业务组件将仅仅由基于现有功能实现的服务功能组件和使用企业数据总线的数据存取组件组成。
阅读全文:在SOA 中整合企业数据 - - - - - -
译者简介:王志雄,长期从事软件开发工作,项目集中在 EAM 和设备点检管理领域。2004 年转入 JAVA 领域,曾经在项目中使用过 Hibernate、Struts、Spring 等。关心软件技术和相关工具的动态,将其中成熟的技术和工具应用到实际的项目之中。关心开源软件的发展动态以及软件过程和敏捷开发的实践探索。
评论