1.Overview
数据服务是专门化的Web服务，在Web服务占了很大的地盘。
因此，有企业服务总线(ESB)，也会有数据总线，两者是SOA下的两大总线，概念与功能上基本能一一对应，都是提供集中、星型的访问服务。
2.数据的基本服务接口
通过元数据定义，在一个或多个数据源中，将一个或多个数据表组合为信息视图，暴露为服务，提供CRUD接口和更新通知机制。
这里指的数据，除了直接的数据表暴露外，更可能是一个有业务意义的信息视图。
数据总线的数据源除了数据库外，还可能是业务系统的WebService/EJB等接口，这一点极具SOA的意义，业务系统极有可能在物理上或逻辑上不允许总线对其数据库直接访问和更新。而其他如Excel形式的数据源反倒不那么重要。
1.CRUDSI操作接口：
对信息暴露标准的Create，Update，Delete，Retrive，Search与Information接口。
除了最传统的WebService接口外，还可能有下面的传输协议与数据格式：
- REST，轻量级面向资源接口，数据服务似乎是REST最贴切的用武之地--层次式URL定位对象，CRUD操作的HTTP原语。
- JSON/POX(Plain Old XML)，尽量简化的数据传输。
- RSS/ATOM Feed，轻量级的信息发布订阅格式。
- IBM/BEA的SDO规范，虽然看上去很美，但由于数据传输的跨平台要求，没有MS的加入等于白搭。
- 虚拟JDBC Driver，支持ADO.net的WebService，尽量减少旧系统改造的成本。
2.查询语言：
- 直接的SQL92语言。
- 针对XML结果集的XQuery。
- 自设计的面向对象的查询语言，JPA的JQL、Salesforce的SOQL、Facebook的FQL等，能更好的表达信息视图中的对象嵌套关系，如post.comments。
- Google Base的简单按属性匹配查询--Fillter模式。
3.数据更新通知机制：
- SalesForce的带时间窗参数(beginTime,endTime)的服务端查询接口，如id[] getUpdated(objectType,beginTime,endTime)。
优点-最为简单；缺点-实时性低，要达到高实时性时资源损耗严重；
- 客户自行实现接收通知的Web Service，供服务端调用。
缺点--客户需要实现Web Service Server，而服务端需要自行实现订阅，可靠性保障等消息中间件功能。
- 使用跨平台的消息中间件，客户通过MOM的客户端接收消息。而且封装屏蔽底层消息中间件的存在，只向用户提供有限的API。
优点-效率高，且对客户端要求低。缺点-免费又服众的跨平台中间件难觅。
4.权限规则引擎：
在表级、列级权限控制的基础上，还需要灵活的规则引擎来实现可定义的行记录级的权限控制。
5.业务接口封装
在标准的数据接口之上，可以封装可重用的面向业务的接口(此时与业务接口的界限将变得模糊)。
3.数据服务的高级需求
- 分布式实时联合视图 (Data Federation Service)
数据横向联合模式
，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持经优化的即时联合查询与有限的更新能力。
数据纵向整合模式，支持连接于数据总线上的数据服务进行纵向的整合， 多用于用于BI,Warehouse。
比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。
整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行ETL拉取。
- 全文索引：支持相关性排序、模糊搜索，或者多个关键字搜索的搜索。
- 数据分析：支持数据挖掘，仪表板报告等。
4.其他更强悍的需求
5. 轻量级的数据服务
6. 其他实现项目
6.1 BEA Data Service Platform
支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。
6.2 其他
