1.Overview

       数据服务是专门化的Web服务，在Web服务中实际占了很大的一部分。
       但在这些Web服务中，数据服务与业务服务的界限通常并不清晰；接口粒度通常为特定数据类型，容易发生更改且业务服务耦合了某个特定的数据服务；还有基础设施的重复建设。
       所以有了专门的数据总线。

• SOA中的数据，第1部分：将数据转换成信息(dev2dev) 
• 信息服务模式，第 2 部分: 数据整合模式 ，第1部分：数据联合模式 ，第 3 部分：数据清理模式 (IBM DW)  
• Incorporating Enterprise Data into SOA(InfoQ) 

2.数据的基本服务接口

      通过元数据定义，将一个或多个数据表组合为业务信息视图，并暴露为服务，提供CRUD操作接口和更新通知机制。
    
      1.对外接口，除了传统的WebService接口外：

• REST，轻量级面向资源接口，层次式URL定位对象，CRUD操作走HTTP原语，数据服务似乎是REST最贴切的用武之地。
• JSON/POX(Plain Old XML)，尽量简化的数据传输量。
• RSS/ATOM Feed，轻量级信息发布订阅格式。
• Ajax，对REST/JSON的支持使得Ajax已呼之欲出。
• IBM/BEA的SDO规范，虽然看上去很美，但由于数据的跨平台性，没有MS的加入等于白搭。

      2.查询语言的设计：

• 直接SQL
• JPA的JQL、Salesforce的SOQL、Facebook的FQL等自设计的面向对象的查询语言
• Google Base的简单按属性匹配。

      3.数据更新通知机制：

• SalesForce的带时间窗参数(beginTime,endTime)的服务端查询接口
• 客户自行实现接收通知的Web Service给服务端调用
• 使用跨平台的消息中间件 。并进行封装屏蔽底层消息中间件的存在，只向用户提供有限的API。

      4.粗粒度接口：

         REST的"层次式定位"比单纯的"数据类型"更适合复杂的数据环境。无论是SOAP还是REST，都不应采用RPC风格与强数据类型。

      5.权限规则引擎

3.数据的整合同步

     数据纵向整合，客户端真正将数据"插"到总线上，通过元数据定义他们所提供的数据库、WebService和Data Feed数据，供服务端主动进行"拉"的动作。

      比如，当多个自治的独立异构数据源中(地域分公司，并购企业)，存在核心的业务实体--主数据(如客户，订单)，进行叠加转换后提供统一的只读数据集。因为各异构数据源对相同的主数据可能不一致、不完整、可能有完全不同的表现形式，所以存在有数据抽取转换的过程。

      整合的周期可是是定时(天/周)，或者数据源变更事件时发生。

4.数据的异构联合视图

      数据横向联合将分散在位置透明的多种数据源，多个数据表中的数据，联合成一个大的有业务意义的信息视图，支持其即时联合查询。

5.参考方案

• BEA的AquaLogic Data Services Platform ，   偏重于横向联合的即时查询。
• IBM的WebSphere Information Services Director ，待研究。
• JBoss MetraMatrix  ( 深入JBoss MetaMatrix ) ，类似BEA，JBoss收购后还没发布。
• Apatar ，待研究。
• Apache Abdera  ATOM/APP协议的实现，ROME 希望在2.0中将其整合-- Abdera项目简介(IBM DW) 

6.Google Base

Google Base 是Google的公共数据库服务，大家可以使用公共对象类型或者设定自己的类型，然后使用GData API  对自己存放在GBase里的数据进行增删改查操作。

GData 系列API，可以将Google的各项数据通过RSS/ATOM扩展的数据查询读取(可按属性查询)，或通过REST版的Atom Publish Protocol进行增删改。

看看GBase的Demo页面 ，一个很REST的简单方案，另外也有Java/C#版的稍嫌冗繁的API。Google中的各项数据，如日志，邮件等，也基于GData协议提供了封装的API。

另外URL里加一个参数，还可以返回JSON格式。