b. 数据服务的范围：数据服务主要关注数据实体上的动作——仅此而已。由此，数据服务的范围包括：数据实体上的各种操作，聚合多个不同数据源的数据，使用多种协议简化消费多个平台的数据接口，逻辑接口和物理提供者接口之间的映射，以及数据服务错误的优雅错误处理。数据供给和大数据提取的转换也能够使用数据服务，尽管这些领域一般会使用ETL和数据profiling工具。业务流程编排逻辑和业务规则执行路线不在数据服务范围之内，因为它们抑制重用。特殊用户界面屏幕/应用相关的逻辑也超出了数据服务的范围。
c. 数据服务的开发：数据服务的开发奉行“契约优先”的方法，服务契约——输入模式和输出模式——是根据需求开发出来的。模式设计需要遵循几个指导方针和最佳实践，在此有必要重温其中的关键内容：
1. 模式属性/类型/元素的设计要结合信息架构功能发布和治理的逻辑数据模型。这保证了系统或技术相关的标识符/值不会暴露到公共模式契约之中。为了确保模式和组织的战略方向保持一致，需要使用标准的编码值，在适当时可增加新的标准遍码值。
2. 检查现有契约是否有重用的机会。业务实体模式也能由信息架构功能治理，标准的企业数据实体要尽可能的被重用。例如，Get Product和Create Product数据服务Web方法都能够使用同一Product模式。这同样适用于发布服务的设计——在发布数据实体时重用模式，其过程不同于应调用请求而暴露模式。这不仅能够节省时间，还能够保证数据服务消费者在准备数据服务的输入或解析数据服务的输出时，对数据实体有一个一致的定义。
3. 在为数据服务消费者设计WSDL契约时，需要导入模式，其目的是为了让WSDL文档和被用来实现数据编配的接口保持一致。这也保证了WSDL文档是轻量级和模块化的。
4. 应该使用工具（如Web服务互操作[WS-I]WSDLValidator）来验证模式和WSDL文档，确保数据服务契约没有使用妨碍互操作性和数据服务重用的平台/提供商/技术相关的结构。一旦确定契约，为了实现它，就要设计数据编配。数据编配将包含以串行、并行或者二者组合执行的数据服务提供者组件模块。在开发流程中的这一步将确切决定所需调用、调用顺序，哪些调用并发进行，以及哪个调用依赖之前的调用等。
d. 数据服务的消费模式：数据服务的消费需要从几个角度来审视：
1. 计算环境：数据服务可在多数平台上被消费。大多数消费者会使用：.NET公共语言运行时（CLR），java虚拟机运行环境（JRE），大型机系统和Unix/Linux。总而言之，这种计算环境可以是任何能执行Web服务调用的环境；可靠队列中的消息能够被发送或者接收的环境。
2. 传输协议：数据服务可以通过可靠的（如MQ Series上的JMS）或非可靠的（如HTTP）消息传输协议被消费。某些数据服务可能只能由基于这种功能的某些传输工具提供。
3. 消息交换模式：数据服务可以通过四种主要的消息交换模式被访问：请求-应答（严格SLA）、请求-应答（宽松SLA ），即发即弃和发布-订阅。
=============================================================
作者简介：
Vijay Narayanan，目前是软件开发团队的队长，负责为金融服务公司构建可重用的数据服务和业务流程自动化组件。我从事过多个软件项目，从单独的用户系统到大型、分布式、多服务的多用户平台。在http://softwarereuse.wordpress.com/上，我有一个关于软件重用的博客。
原文标题：数据服务简介 ，查看英文原文：Introduction to Data Services。
==============================================================
当前位置：