`

数据服务笔记

 
阅读更多
<iframe align="center" marginwidth="0" marginheight="0" src="http://www.zealware.com/csdnblog336280.html" frameborder="0" width="336" scrolling="no" height="280"></iframe>

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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


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.业务级封装

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

3.数据的异构联合视图

在上面的基本服务提供了基本的分散数据源的集中统一访问点之后， 数据联合模式 ，将分散在位置透明的多种数据源(DB，WebService)，多个数据表中的数据，联合成一个更大的有业务意义的信息视图，支持其即时联合查询与有限的更新能力。

4.数据的拉取整合同步

数据整合模式 ，支持连接于数据总线上的数据服务进行纵向的整合。

比如，当多个自治的独立异构数据源(地域分公司，并购企业)中，都存在核心的业务实体--主数据(如客户，订单)，可进行叠加转换后，提供统一的只读数据集。

整合的方式有两种，一种是各数据源主动调用总数据集的基本服务接口进行发布。而另一种模式则是数据总线主动对各数据源进行拉取。

5.Google Base

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

看看GBase的Demo页面 ，一个很REST的简单直接操作HTTP/REST方案，另外也有Java/C#版的稍嫌冗繁的API，但都逃不开手工或使用client API读取XML，转化为语言对象的动作。

6. BEA Data Service Platform

支持基本服务接口，输出Web Service，SDO，JDBC(只读)等操作接口，偏重于基于XQuery的异构数据横向联合查询。

7.其他参考资料

 


分享到：
| JavaEE事务扫盲笔记之一扫扫到尾
评论
发表评论

您还没有登录,请您登录后再发表评论

相关推荐

Magicbox
Global site tag (gtag.js) - Google Analytics