数据服务笔记

扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条

数据服务是专门化的Web服务，实际上占了Web服务很大的一部分。但在这些Web服务中，数据服务与业务服务的界限通常并不清晰；

作者：江南白衣来源：CSDN 2008年1月30日

1.Overview

      数据服务是专门化的Web服务，在Web服务占了很大的地盘。
      因此，有企业服务总线(ESB)，也会有数据总线，两者是SOA下的两大总线，概念与功能上基本能一一对应，都是提供集中、星型的访问服务。
      数据vs信息。数据一般指单体的表，而信息指有业务含义的多个数据表的组合。数据服务的主体一般是"信息"。

2.数据的基本服务接口

通过元数据定义，将一个或多个数据表组合为信息视图，暴露为服务，提供CRUD接口和更新通知机制。

     除了让数据总线直接访问数据库外，数据源还可能是业务系统的WebService/EJB等接口，这一点上极具SOA的意义，业务系统下的数据库极有可能在物理上或逻辑上不允许总线对其直接访问和更新。

     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.接口粒度：

可以每个业务实体一个接口，下属SCURDI操作，也可以使用同一个操作接口，使用REST定位对象类型。

REST的"层次式定位"比单纯的"数据类型"更适合复杂的数据环境。无论是最后是采用SOAP还是REST格式，采用RPC风格与强数据类型都会频繁增加或改动接口。

5.权限规则引擎：

在表级、列级权限控制的基础上，还需要灵活的规则引擎来实现行记录级的权限控制。

6.业务级封装

在规范数据接口之上，可以封装可重用的业务级接口。