数据服务笔记

最新推荐文章于 2024-02-05 09:04:24 发布
最新推荐文章于 2024-02-05 09:04:24 发布
阅读量693 收藏
点赞数
文章标签： webservice 消息中间件 rest salesforce soa jboss
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/huangkelong/article/details/2279258
版权

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.其他参考资料

 


huangkelong
关注
王道数据结构笔记
weixin_44582953的博客
03-23 3583
王道数据结构笔记2.2 线性表的顺序表示顺序表的实现——动态分配顺序表的特点总结 2.2 线性表的顺序表示 顺序表的实现——动态分配 由于需要将数据复制到新的区域因此时间开销大 #include <stblib.h> #define InitSize 10 //默认最大长度 typedef struct{ int *data; //指示动态分配数组的指针 int MaxSize; //顺序表的最大容量 int length; //顺序表的当前长度 }SeqList; void In
数据结构高分笔记part1
10-30
1. **基本概念**：首先，笔记可能会定义数据结构的基本概念，如什么是数据、数据元素、数据对象、数据结构和抽象数据类型（ADT）。它会解释数据结构是如何组织和存储数据的，以及如何通过不同的方式访问和操作这些...
数据挖掘笔记1
2301_80618119的博客
01-22 2114
把服务器当作一种资源，随着访问需求变化，从云计算的服务商地方租，使利用率变高。一个一个单独的elements/items，两两去聚。聚类：把一堆数据分为一组一组的（没有标签）把问题进行切分，分配到不同的处理器上。
数据结构期末复习笔记
zyw2002的博客
11-28 4879
背景：2021春季期末与好友多喝岩浆xx共同整理的复习笔记。 主要参考了老师的课件, 还有一些博客。(万分感谢好友，老师，还有乐于分享的博主们！) github 下载地址：复习笔记pdf+图解数据结构doc 百度网盘下载地址：链接：复习笔记pdf 提取码：m6yn 感想：一般来说大学应试的数据结构考的都是基本的知识点，不会特别难，但真正的学习数据结构光靠应试的复习是远远不够的。说实话我第一遍听课的时候也觉的很多知识似懂非懂，但是在期末考试提前很久就开始自己复习了，通过画图把每一个算法都去弄懂，尤其像KMP.
Spark大数据分析与实战笔记（第二章 Spark基础-06）
想你依然心痛的博客
02-05 2万+
Spark-Shell通常在测试和验证我们的程序时使用的较多，然而在生产环境中,通常会在IDEA开发工具中编写程序,然后打成Jar包，最后提交到集群中执行。下面讲解使用IDEA工具开发WordCount单词计数程序的相关步骤。Maven是一个项目管理工具，虽然我们刚才创建好了项目，但是却不能识别Spark类，因此，我们需要将Spark相关的依赖添加到Maven项目中。集群模式是指将Spark程序提交至Spark集群中执行任务，由Spark集群负责资源的调度，程序会被框架分发到集群中的节点上并发地执行。
数据分析笔记
riluomati的专栏
06-29 7648
数据产业实践至少涉及三个关键环节： 数据业务定义（把一个具体业务问题定义成一个数据可分析问题）、 数据分析与建模（描述统计、数据可视化、回归分析、机器学习）、 数据业务实施（流程改造、产品设计、标准制定等）。 ...
Spark大数据分析与实战笔记（第一章 Scala语言基础-2）
热门推荐
想你依然心痛的博客
08-26 4万+
Spark是专为大规模数据处理而设计的快速通用的计算引擎，它是由Scala语言开发实现的，关于大数据技术，本身就是计算数据，而Scala既有面向对象组织项目工程的能力，又具备计算数据的功能，同时Spark和Scala的紧密集成，本书将采用Scala语言开发Spark程序，所以学好Scala将有助于我们更好的掌握Spark框架。另一种是使用关键字val声明的变量，也叫常量，值是不可变的。声明变量时，我们可以不给出变量的类型，因为在初始化的时候，Scala的类型推断机制能够根据变量的初始化的值自动推算出来。
数据仓库学习笔记
weixin_39281866的博客
12-03 1813
数据仓库的概念、数据仓库与数据库的区别，数据仓库的建模方法
数据结构--严蔚敏（C语言版）笔记
lose_user___的博客
05-27 4992
目录第一章 绪论1.1 复习笔记一、 什么是数据结构二、 基本概念和术语三、 抽象数据类型的实现四、 算法和算法分析第二章 线性表一、线性表的类型定义二、线性表的顺序表示和实现1. 顺序表存储结构的表示2. 顺序存储结构的特点三、 线性表的链式表示和实现1.定义2.链式存储结构的特点3.链式存储结构的分类第三章 栈和队列一、 栈1. 栈的定义与基本操作2. 栈的表示和实现二、栈的应用举例1. 括号匹配2. 表达式求值三、栈与递归的实现1. 递归的定义2.栈在递归中的运用数据结构是一门研究非数值计算的程序设计
数据结构与算法 学习笔记（手写版）..
心海非海_のBlog
10-28 1567
《大话数据结构》学习笔记 1. 相关概念 1.1 逻辑结构 & 物理结构 1.2 抽象数据类型 2. 算法 2.1 基本概念 2.2 算法效率的度量方法 2.3 复杂度 & 大O记法
韩顺平老师尚硅谷Java数据结构与算法194集笔记
10-12
这是我从B站上看韩老师讲的数据结构与算法后整理的笔记 代码经过运行，欢迎批评指正 有些地方我感觉还是挺难的 大都经过我自己的语言进行描述，韩老师中期的表达可能或多或少也影响可阅读性，望先生们见谅
王道数据结构+C语言版+超全笔记(图文)+个人整理版本
04-05
笔记自带标签，方便定位；还有个人示例代码，图文结合，逻辑清晰。适用于自学，考研党408科目等。 一、基本概念和术语 (一)数据元素、数据结构、抽象数据类型等概念 (二)算法设计的基本要求 (三)语句的频度和估算...
数据结构笔记2022.pdf
08-19
很抱歉，但您提供的文件内容信息中，【部分内容】并没有实际的内容描述，而是一连串的数字和...如果您能提供实际的文件内容，我将能够更好地帮助您总结和解释数据结构笔记中的关键点。请提供详细的内容以便进行分析。
数据结构（C语言描述）学习笔记、学习文档.zip
11-08
数据结构（C语言描述）学习笔记、学习文档 数据结构（C语言描述）学习笔记、学习文档 数据结构（C语言描述）学习笔记、学习文档 数据结构（C语言描述）学习笔记、学习文档 数据结构（C语言描述）学习笔记、学习文档 ...
基于yolov3结合卡尔曼滤波匈牙利算法虚拟线圈的车流量检测python源码+项目说明.zip
09-21
本项目专注于视频基的车辆跟踪与流量统计，依托深度学习技术，实时追踪路面车辆动态并精准统计各车道车流量。该项目通过以下核心步骤高效处理输入视频数据： 高精度目标检测：采用YOLOv3模型，凭借其卓越的实时性与准确性，快速识别视频中的车辆目标，为后续追踪奠定坚实基础。 稳定目标追踪：集成SORT（Simple Online and Realtime Tracking）算法，结合卡尔曼滤波器预测车辆未来位置，同时运用匈牙利算法优化目标间的匹配，实现连续、稳定的车辆追踪，有效应对遮挡、交叉等复杂场景。 智能车流量统计：借鉴虚拟线圈概念，巧妙设计算法以监测穿越预设区域的车辆，自动计数并准确统计各车道车流量，为交通管理与分析提供可靠数据支持。 整体而言，本项目通过融合先进的目标检测与追踪技术，结合创新的流量统计方法，构建了一个高效、精准的实时车辆跟踪与流量统计系统，为智慧交通领域的发展贡献力量。
本科毕业设计--基于深度学习的人脸面部表情识别.zip
最新发布
09-21
深度学习是机器学习的一个子领域，它基于人工神经网络的研究，特别是利用多层次的神经网络来进行学习和模式识别。深度学习模型能够学习数据的高层次特征，这些特征对于图像和语音识别、自然语言处理、医学图像分析等应用至关重要。以下是深度学习的一些关键概念和组成部分： 1. **神经网络（Neural Networks）**：深度学习的基础是人工神经网络，它是由多个层组成的网络结构，包括输入层、隐藏层和输出层。每个层由多个神经元组成，神经元之间通过权重连接。 2. **前馈神经网络（Feedforward Neural Networks）**：这是最常见的神经网络类型，信息从输入层流向隐藏层，最终到达输出层。 3. **卷积神经网络（Convolutional Neural Networks, CNNs）**：这种网络特别适合处理具有网格结构的数据，如图像。它们使用卷积层来提取图像的特征。 4. **循环神经网络（Recurrent Neural Networks, RNNs）**：这种网络能够处理序列数据，如时间序列或自然语言，因为它们具有记忆功能，能够捕捉数据中的时间依赖性。 5. **长短期记忆网络（Long Short-Term Memory, LSTM）**：LSTM 是一种特殊的 RNN，它能够学习长期依赖关系，非常适合复杂的序列预测任务。 6. **生成对抗网络（Generative Adversarial Networks, GANs）**：由两个网络组成，一个生成器和一个判别器，它们相互竞争，生成器生成数据，判别器评估数据的真实性。 7. **深度学习框架**：如 TensorFlow、Keras、PyTorch 等，这些框架提供了构建、训练和部署深度学习模型的工具和库。 8. **激活函数（Activation Functions）**：如 ReLU、Sigmoid、Tanh 等，它们在神经网络中用于添加非线性，使得网络能够学习复杂的函数。 9. **损失函数（Loss Functions）**：用于评估模型的预测与真实值之间的差异，常见的损失函数包括均方误差（MSE）、交叉熵（Cross-Entropy）等。 10. **优化算法（Optimization Algorithms）**：如梯度下降（Gradient Descent）、随机梯度下降（SGD）、Adam 等，用于更新网络权重，以最小化损失函数。 11. **正则化（Regularization）**：技术如 Dropout、L1/L2 正则化等，用于防止模型过拟合。 12. **迁移学习（Transfer Learning）**：利用在一个任务上训练好的模型来提高另一个相关任务的性能。 深度学习在许多领域都取得了显著的成就，但它也面临着一些挑战，如对大量数据的依赖、模型的解释性差、计算资源消耗大等。研究人员正在不断探索新的方法来解决这些问题。
雷电模拟器改成真机环境
09-21
在Android系统中，模拟器通常会被识别为非真实的设备，这可能导致某些应用或服务无法正常运行，尤其是那些需要硬件信息或root权限的应用。改真机环境意味着通过技术手段使模拟器的行为更接近真实的Android设备，包括模拟设备硬件信息、IMEI、MAC地址等，以绕过检测并提升兼容性。LSPSED（Linux System Property Setter and Editor）模块是Magisk的一个扩展，专门用于修改Android系统的系统属性。通过LSPSED，我们可以更改设备的各种系统属性，如设备型号、制造商信息等，这些修改对于使模拟器看起来更像真实设备至关重要。在使用过程中，还需要添加几个机型模块，这些模块通常包含了特定设备的系统配置信息，如设备代号、硬件信息等。通过安装这些模块，雷电模拟器可以模仿各种流行的Android设备，进一步提高应用的兼容性和真实性。
CenterNet 部署版本，便于移植不同平台（onnx、tensorRT、rknn、Horizon）
09-21
CenterNet 是一种用于目标检测的神经网络架构，它的核心思想是利用目标的中心点作为检测的关键信息。这种方法与传统的目标检测方法（如基于边界框的方法）有所不同，因为它不直接预测目标的边界框，而是预测目标的中心点坐标和目标的宽度与高度。 CenterNet 的主要特点包括： 1. **中心点预测**：网络输出目标的中心点坐标，以及目标的宽度和高度。 2. **热图（Heatmap）**：网络生成一个热图，其中每个像素点的值表示该点成为目标中心点的概率。 3. **回归任务**：除了中心点坐标，网络还需要预测目标的宽度和高度，这通常通过预测中心点周围的偏移量来实现。 4. **多任务学习**：CenterNet 通常会同时预测目标的类别、中心点坐标、宽度、高度以及目标的旋转角度（在某些变体中）。 5. **端到端训练**：CenterNet 可以直接在最终的目标检测任务上进行端到端的训练，无需复杂的区域提议网络（Region Proposal Network, RPN）或锚点（anchor）机制。 6. **高效性**：由于省略了传统目标检测中的一些步骤，CenterNe
考研数据结构复习笔记与经典题目解析
在考研复习笔记中，这部分内容涵盖了数据结构的核心要素，包括逻辑结构、存储结构和基本运算。 逻辑结构定义了数据元素之间的关系，例如，学生成绩记录可以看作是一个数据元素，它由多个数据项如姓名和性别组成，...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值