数据服务简介
原文： http://www.infoq.com/cn/articles/narayanan-soa-data-services?utm_source=bshare&utm_campaign=bshare&utm_medium=sinaminiblog&bsh_bid=148096884
数据服务是一种软件服务，它封装了企业相关的关键数据实体的操作。企业数据被存储在多个系统中，要想与之交互需要多个接口或多种机制。此外，数据服务还要给不同渠道（分支机构、在线业务、呼叫中心）和机制（事件驱动、随需应变、批处理）提供服务，这也给数据服务带来了挑战。对于数据消费者，要是没有一个抽象层将之与这种复杂性相隔离，企业中数据源和数据消费者之间的集成将会以一种意大利面式的点对点集成而收场。
数据服务让消费者无需去访问或者更新多个数据源，更重要的是，当消费者需要操作多个数据源时，数据服务有助于维持数据的完整性。此外，它们还能够帮助构建可被多个项目和创新利用的可重用数据服务。数据服务还能够执行关键的治理职能——它们有助于度量指标的集中化、监视、版本管理、数据类型的重用，以及执行数据可视化和访问规则。
数据服务带来的额外好处有：数据源抽象、聚合数据提供者、重用（以通用的、可互操作的、灵活的消费模式）、与逻辑数据模型保持一致、支持服务的多版本、提供增值特性，以及单点交互。因此，数据服务为企业改进业务需求提供了一个可持续的基础。
数据服务的基本原理
数据源的抽象：数据服务将消费者和物理数据源隔离了开来。这使得数据提供者改变数据结构（添加/删除表、列或其他数据库对象）、数据格式（从纯文本变到XML）、数据持久化机制（从单个数据库变到多个数据库、改变数据库提供商、添加表分区）、数据交换协议（从ODBC驱动改到OLE DB驱动），都不会对每个消费者产生不利影响。任何这些参数的变化都只会影响数据服务的代码，不会要求每个消费者改变其数据访问逻辑。
聚合：数据服务允许提供者使用一个或多个数据源来构造业务实体。这种思想不仅适用于同构数据源，也适用于异构数据源。例如，聚合可以在两个数据库之间进行，亦可以在一个数据库和一个XML文档之间进行。这让数据服务可以将结构化的数据和半（或非）结构化的数据组合起来。例如，数据服务能够聚合文本数据（如来自某个数据源的免责信息）和来自另一个数据源的Party Profile数据。针对消费者的需要，提供者还可以使用不同数据源构造出Party或者Account数据消息，然后跟目标消息聚合在一起。这让消费者不需要查询、访问多个数据源和执行聚合就可以得到自己想要的信息。而且，通过执行聚合，数据服务为消费者提供了更简单的编程接口去完成数据的访问、错误处理和维护。
重用：数据服务可作为操作企业数据的可重用构建单元。在企业数据上执行CRUD（增、查、改和删）和查找操作的数据服务本来就是可以跨多个项目重用的。 数据服务（又称实体服务[Entity Services]）因为几个特性使其具有可重用性：通用的天性、平台互操作性，以及支持多种消费模式。数据服务逻辑可应用于多个业务流程，这极大地推动了重用。例如，Find Party服务可以应用于：在给零售账户上已授权个人进行委派时查找Party，以及在数据合并活动中合并重复资料时查找Party。数据服务既具有跨平台的互操作性，也可以通过多种传输协议（如HTTP和JMS）使自己被其他消费者使用。它们还可以通过主流的信息交换模式被访问：即发即弃，请求-应答和发布-订阅。因而，消费者可以根据自己的需要来访问这些服务，如通过用户界面或需要可靠消息传输的异步流程。
跟逻辑数据模型保持一致：通过保持数据结构和各种数据属性行为中的一致性，数据服务提供了与逻辑数据模型实体（如Profile、Account等）保持一致的能力。若没有数据服务，每个消费者就只能以自己特有的方式来解释物理数据属性，随之而来的额外风险就是消费者和底层数据结构的提供者直接耦合在了一起。数据服务允许跨模式重用数据类型和跨服务操作重用模式。由于模式是根据信息架构定义/支配的逻辑数据模型而定义的，数据服务提供了与这些逻辑模型的对齐。这就允许数据服务可以使用逻辑数据值和逻辑数据属性（而不是系统特定的值和属性）。为什么这很重要？因为在使遗留系统退役的过程中，最大的障碍是多个消费应用程序中到处散布和使用的物理遗留值和属性。这让数据的每个消费者都和遗留系统发生了紧耦合。数据服务通过跟逻辑数据模型保持一致，有效地将消费者和遗留值与属性进行了解偶。
支持服务的多个版本：数据服务允许提供者选择暴露服务的一个或者多个版本。这使得数据服务提供者可以给规模较小的目标消费群提供试点服务或者服务的新版本。这也可以让数据服务提供者方便地在服务新版本中提供新特性，不用强迫所有消费者同时升级。同理，这也允许数据服务消费者可以优雅地迁移到数据服务的新版本上去。
提供增值功能：除了操作数据实体的基本功能之外，数据服务还提供了增值服务，例如数据缓存（为频繁访问的数据提供高效/快速的访问）、过滤（例如，客户只想接收某数据实体相关的发布信息），以及订阅管理（针对客户的发布注册管理）。
交互单点：对消费者来说，数据服务扮演了与数据实体交互的单点。它们可以使用一致的隐喻/机制来操作不同数据域中的企业数据（Profile数据，Account数据，交叉引用，关系等）。这也简化了认证（验证消费者的证书）和鉴权（如，消费者是否有权执行服务？消费者能否看到机密数据的属性？）的执行。这种交互单点也允许组织在多个数据服务中拥有可重复的消费者集成流程。
数据服务的范围
数据服务主要关注数据实体上的动作——仅此而已。由此，数据服务的范围包括：数据实体上的各种操作，聚合多个不同数据源的数据，使用多种协议简化消费多个平台的数据接口，逻辑接口和物理提供者接口之间的映射，以及数据服务错误的优雅错误处理。数据供给和大数据提取的转换也能够使用数据服务，尽管这些领域一般会使用ETL和数据profiling工具。业务流程编排逻辑和业务规则执行路线不在数据服务范围之内，因为它们抑制重用。特殊用户界面屏幕/应用相关的逻辑也超出了数据服务的范围。
数据服务的开发
数据服务的开发奉行“契约优先”的方法，服务契约——输入模式和输出模式——是根据需求开发出来的。模式设计需要遵循几个指导方针和最佳实践，在此有必要重温其中的关键内容：
模式属性/类型/元素的设计要结合信息架构功能发布和治理的逻辑数据模型。这保证了系统或技术相关的标识符/值不会暴露到公共模式契约之中。为了确保模式和组织的战略方向保持一致，需要使用标准的编码值，在适当时可增加新的标准遍码值。
检查现有契约是否有重用的机会。业务实体模式也能由信息架构功能治理，标准的企业数据实体要尽可能的被重用。例如，Get Product和Create Product数据服务Web方法都能够使用同一Product模式。这同样适用于发布服务的设计——在发布数据实体时重用模式，其过程不同于应调用请求而暴露模式。这不仅能够节省时间，还能够保证数据服务消费者在准备数据服务的输入或解析数据服务的输出时，对数据实体有一个一致的定义。
在为数据服务消费者设计WSDL契约时，需要导入模式，其目的是为了让WSDL文档和被用来实现数据编配的接口保持一致。这也保证了WSDL文档是轻量级和模块化的。
应该使用工具（如Web服务互操作[WS-I]WSDLValidator）来验证模式和WSDL文档，确保数据服务契约没有使用妨碍互操作性和数据服务重用的平台/提供商/技术相关的结构。
一旦确定契约，为了实现它，就要设计数据编配。数据编配将包含以串行、并行或者二者组合执行的数据服务提供者组件模块。在开发流程中的这一步将确切决定所需调用、调用顺序，哪些调用并发进行，以及哪个调用依赖之前的调用等。
数据服务的消费模式：
计算环境：数据服务可在多数平台上被消费。大多数消费者会使用：.NET公共语言运行时（CLR），java虚拟机运行环境（JRE），大型机系统和Unix/Linux。总而言之，这种计算环境可以是任何能执行Web服务调用的环境；可靠队列中的消息能够被发送或者接收的环境。
传输协议：数据服务可以通过可靠的（如MQ Series上的JMS）或非可靠的（如HTTP）消息传输协议被消费。某些数据服务可能只能由基于这种功能的某些传输工具提供。
消息交换模式：数据服务可以通过四种主要的消息交换模式被访问：请求-应答（严格SLA）、请求-应答（宽松SLA ），即发即弃和发布-订阅。
作者简介
Vijay Narayanan就是我，目前是软件开发团队的队长，负责为金融服务公司构建可重用的数据服务和业务流程自动化组件。我从事过多个软件项目，从单独的用户系统到大型、分布式、多服务的多用户平台。在http://softwarereuse.wordpress.com/上，我有一个关于软件重用的博客。
查看英文原文： Introduction to Data Services
数据服务是一种软件服务，它封装了企业相关的关键数据实体的操作。企业数据被存储在多个系统中，要想与之交互需要多个接口或多种机制。此外，数据服务还要给不同渠道（分支机构、在线业务、呼叫中心）和机制（事件驱动、随需应变、批处理）提供服务，这也给数据服务带来了挑战。对于数据消费者，要是没有一个抽象层将之与这种复杂性相隔离，企业中数据源和数据消费者之间的集成将会以一种意大利面式的点对点集成而收场。
数据服务让消费者无需去访问或者更新多个数据源，更重要的是，当消费者需要操作多个数据源时，数据服务有助于维持数据的完整性。此外，它们还能够帮助构建可被多个项目和创新利用的可重用数据服务。数据服务还能够执行关键的治理职能——它们有助于度量指标的集中化、监视、版本管理、数据类型的重用，以及执行数据可视化和访问规则。
数据服务带来的额外好处有：数据源抽象、聚合数据提供者、重用（以通用的、可互操作的、灵活的消费模式）、与逻辑数据模型保持一致、支持服务的多版本、提供增值特性，以及单点交互。因此，数据服务为企业改进业务需求提供了一个可持续的基础。
数据服务的基本原理
数据源的抽象：数据服务将消费者和物理数据源隔离了开来。这使得数据提供者改变数据结构（添加/删除表、列或其他数据库对象）、数据格式（从纯文本变到XML）、数据持久化机制（从单个数据库变到多个数据库、改变数据库提供商、添加表分区）、数据交换协议（从ODBC驱动改到OLE DB驱动），都不会对每个消费者产生不利影响。任何这些参数的变化都只会影响数据服务的代码，不会要求每个消费者改变其数据访问逻辑。
聚合：数据服务允许提供者使用一个或多个数据源来构造业务实体。这种思想不仅适用于同构数据源，也适用于异构数据源。例如，聚合可以在两个数据库之间进行，亦可以在一个数据库和一个XML文档之间进行。这让数据服务可以将结构化的数据和半（或非）结构化的数据组合起来。例如，数据服务能够聚合文本数据（如来自某个数据源的免责信息）和来自另一个数据源的Party Profile数据。针对消费者的需要，提供者还可以使用不同数据源构造出Party或者Account数据消息，然后跟目标消息聚合在一起。这让消费者不需要查询、访问多个数据源和执行聚合就可以得到自己想要的信息。而且，通过执行聚合，数据服务为消费者提供了更简单的编程接口去完成数据的访问、错误处理和维护。
重用：数据服务可作为操作企业数据的可重用构建单元。在企业数据上执行CRUD（增、查、改和删）和查找操作的数据服务本来就是可以跨多个项目重用的。 数据服务（又称实体服务[Entity Services]）因为几个特性使其具有可重用性：通用的天性、平台互操作性，以及支持多种消费模式。数据服务逻辑可应用于多个业务流程，这极大地推动了重用。例如，Find Party服务可以应用于：在给零售账户上已授权个人进行委派时查找Party，以及在数据合并活动中合并重复资料时查找Party。数据服务既具有跨平台的互操作性，也可以通过多种传输协议（如HTTP和JMS）使自己被其他消费者使用。它们还可以通过主流的信息交换模式被访问：即发即弃，请求-应答和发布-订阅。因而，消费者可以根据自己的需要来访问这些服务，如通过用户界面或需要可靠消息传输的异步流程。
跟逻辑数据模型保持一致：通过保持数据结构和各种数据属性行为中的一致性，数据服务提供了与逻辑数据模型实体（如Profile、Account等）保持一致的能力。若没有数据服务，每个消费者就只能以自己特有的方式来解释物理数据属性，随之而来的额外风险就是消费者和底层数据结构的提供者直接耦合在了一起。数据服务允许跨模式重用数据类型和跨服务操作重用模式。由于模式是根据信息架构定义/支配的逻辑数据模型而定义的，数据服务提供了与这些逻辑模型的对齐。这就允许数据服务可以使用逻辑数据值和逻辑数据属性（而不是系统特定的值和属性）。为什么这很重要？因为在使遗留系统退役的过程中，最大的障碍是多个消费应用程序中到处散布和使用的物理遗留值和属性。这让数据的每个消费者都和遗留系统发生了紧耦合。数据服务通过跟逻辑数据模型保持一致，有效地将消费者和遗留值与属性进行了解偶。
支持服务的多个版本：数据服务允许提供者选择暴露服务的一个或者多个版本。这使得数据服务提供者可以给规模较小的目标消费群提供试点服务或者服务的新版本。这也可以让数据服务提供者方便地在服务新版本中提供新特性，不用强迫所有消费者同时升级。同理，这也允许数据服务消费者可以优雅地迁移到数据服务的新版本上去。
提供增值功能：除了操作数据实体的基本功能之外，数据服务还提供了增值服务，例如数据缓存（为频繁访问的数据提供高效/快速的访问）、过滤（例如，客户只想接收某数据实体相关的发布信息），以及订阅管理（针对客户的发布注册管理）。
交互单点：对消费者来说，数据服务扮演了与数据实体交互的单点。它们可以使用一致的隐喻/机制来操作不同数据域中的企业数据（Profile数据，Account数据，交叉引用，关系等）。这也简化了认证（验证消费者的证书）和鉴权（如，消费者是否有权执行服务？消费者能否看到机密数据的属性？）的执行。这种交互单点也允许组织在多个数据服务中拥有可重复的消费者集成流程。
数据服务的范围
数据服务主要关注数据实体上的动作——仅此而已。由此，数据服务的范围包括：数据实体上的各种操作，聚合多个不同数据源的数据，使用多种协议简化消费多个平台的数据接口，逻辑接口和物理提供者接口之间的映射，以及数据服务错误的优雅错误处理。数据供给和大数据提取的转换也能够使用数据服务，尽管这些领域一般会使用ETL和数据profiling工具。业务流程编排逻辑和业务规则执行路线不在数据服务范围之内，因为它们抑制重用。特殊用户界面屏幕/应用相关的逻辑也超出了数据服务的范围。
数据服务的开发
数据服务的开发奉行“契约优先”的方法，服务契约——输入模式和输出模式——是根据需求开发出来的。模式设计需要遵循几个指导方针和最佳实践，在此有必要重温其中的关键内容：
模式属性/类型/元素的设计要结合信息架构功能发布和治理的逻辑数据模型。这保证了系统或技术相关的标识符/值不会暴露到公共模式契约之中。为了确保模式和组织的战略方向保持一致，需要使用标准的编码值，在适当时可增加新的标准遍码值。
检查现有契约是否有重用的机会。业务实体模式也能由信息架构功能治理，标准的企业数据实体要尽可能的被重用。例如，Get Product和Create Product数据服务Web方法都能够使用同一Product模式。这同样适用于发布服务的设计——在发布数据实体时重用模式，其过程不同于应调用请求而暴露模式。这不仅能够节省时间，还能够保证数据服务消费者在准备数据服务的输入或解析数据服务的输出时，对数据实体有一个一致的定义。
在为数据服务消费者设计WSDL契约时，需要导入模式，其目的是为了让WSDL文档和被用来实现数据编配的接口保持一致。这也保证了WSDL文档是轻量级和模块化的。
应该使用工具（如Web服务互操作[WS-I]WSDLValidator）来验证模式和WSDL文档，确保数据服务契约没有使用妨碍互操作性和数据服务重用的平台/提供商/技术相关的结构。
一旦确定契约，为了实现它，就要设计数据编配。数据编配将包含以串行、并行或者二者组合执行的数据服务提供者组件模块。在开发流程中的这一步将确切决定所需调用、调用顺序，哪些调用并发进行，以及哪个调用依赖之前的调用等。
数据服务的消费模式：
计算环境：数据服务可在多数平台上被消费。大多数消费者会使用：.NET公共语言运行时（CLR），java虚拟机运行环境（JRE），大型机系统和Unix/Linux。总而言之，这种计算环境可以是任何能执行Web服务调用的环境；可靠队列中的消息能够被发送或者接收的环境。
传输协议：数据服务可以通过可靠的（如MQ Series上的JMS）或非可靠的（如HTTP）消息传输协议被消费。某些数据服务可能只能由基于这种功能的某些传输工具提供。
消息交换模式：数据服务可以通过四种主要的消息交换模式被访问：请求-应答（严格SLA）、请求-应答（宽松SLA ），即发即弃和发布-订阅。
作者简介
Vijay Narayanan就是我，目前是软件开发团队的队长，负责为金融服务公司构建可重用的数据服务和业务流程自动化组件。我从事过多个软件项目，从单独的用户系统到大型、分布式、多服务的多用户平台。在http://softwarereuse.wordpress.com/上，我有一个关于软件重用的博客。
查看英文原文： Introduction to Data Services