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