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格式。?
