1.Overview

數(shù)據(jù)服務是專門化的Web服務，在Web服務占了很大的地盤。 因此，有企業(yè)服務總線(ESB)，也會有數(shù)據(jù)總線，兩者是SOA下的兩大總線，概念與功能上基本能一一對應，都是提供集中、星型的訪問服務。 數(shù)據(jù)vs信息。數(shù)據(jù)一般指單體的表，而信息指有業(yè)務含義的多個數(shù)據(jù)表的組合。數(shù)據(jù)服務的主體一般是"信息"。

2.數(shù)據(jù)的基本服務接口

通過元數(shù)據(jù)定義，在一個或多個數(shù)據(jù)源中，將一個或多個數(shù)據(jù)表組合為信息視圖，暴露為服務，提供CRUD接口和更新通知機制。

除了讓數(shù)據(jù)總線直接訪問數(shù)據(jù)庫外，數(shù)據(jù)源還可能是業(yè)務系統(tǒng)的WebService/EJB等接口，這一點上極具SOA的意義，業(yè)務系統(tǒng)下的數(shù)據(jù)庫極有可能在物理上或邏輯上不允許總線對其直接訪問和更新。 1.CRUDSI操作接口 ：

對信息暴露標準的Create，Update，Delete，Retrive，Search與Information接口。 除了最傳統(tǒng)的WebService接口外，還可能有下面的傳輸協(xié)議與數(shù)據(jù)格式：

• REST，輕量級面向資源接口，數(shù)據(jù)服務似乎是REST最貼切的用武之地--層次式URL定位對象，CRUD操作的HTTP原語。
• JSON/POX(Plain Old XML)，盡量簡化的數(shù)據(jù)傳輸。
• RSS/ATOM Feed，輕量級的信息發(fā)布訂閱格式。
• IBM/BEA的SDO規(guī)范，雖然看上去很美，但由于數(shù)據(jù)傳輸?shù)目缙脚_要求，沒有MS的加入等于白搭。
• 虛擬JDBC Driver，支持ADO.net的WebService，盡量減少舊系統(tǒng)改造的成本。

2.查詢語言 ：

• 直接的SQL92語言。
• 針對XML結果集的XQuery。
• 自設計的面向對象的查詢語言，JPA的JQL、Salesforce的SOQL、Facebook的FQL等，能更好的表達信息視圖中的對象嵌套關系，如post.comments。
• Google Base的簡單按屬性匹配查詢--Fillter模式。

3.數(shù)據(jù)更新通知機制 ：

• SalesForce的帶時間窗參數(shù)(beginTime,endTime)的服務端查詢接口，如id[] getUpdated(objectType,beginTime,endTime)。 優(yōu)點- 最為簡單；缺點 -實時性低，要達到高實時性時資源損耗嚴重；
• 客戶自行實現(xiàn)接收通知的Web Service，供服務端調用。 缺點--客戶需要實現(xiàn)Web Service Server，而服務端需要自行實現(xiàn)訂閱，可靠性保障等消息中間件功能。
• 使用 跨平臺的消息中間件 ?，客戶通過MOM的客戶端接收消息。而且封裝屏蔽底層消息中間件的存在，只向用戶提供有限的API。 優(yōu)點- 效率高，且對客戶端要求低。缺點 -免費又服眾的跨平臺中間件難覓。

4.接口粒度 ：

可以每個業(yè)務實體一個接口，下屬SCURDI操作；也可以使用同一個操作接口，如使用REST定位實際對象類型。

REST的"層次式定位"比單純的"數(shù)據(jù)類型"更適合復雜的數(shù)據(jù)環(huán)境。

無論是最后是采用SOAP還是REST格式，采用RPC風格與強數(shù)據(jù)類型都會頻繁增加或改動接口。

5.權限規(guī)則引擎 ：

在表級、列級權限控制的基礎上，還需要靈活的規(guī)則引擎來實現(xiàn)可定義的行記錄級的權限控制。

6.業(yè)務級封裝

在規(guī)范數(shù)據(jù)接口之上，可以封裝可重用的業(yè)務級接口。

3.數(shù)據(jù)的分散式部署

在上面的基本服務提供了基本的分散數(shù)據(jù)源的集中統(tǒng)一訪問點(但不支持整合)之后，還可以：

• 分布式實時聯(lián)合視圖

數(shù)據(jù)聯(lián)合模式 ，將分散在位置透明的多種數(shù)據(jù)源(DB，WebService)，多個數(shù)據(jù)表中的數(shù)據(jù)，聯(lián)合成一個更大的有業(yè)務意義的信息視圖，支持其即時聯(lián)合查詢與有限的更新能力。

• 將數(shù)據(jù)最終整合存放

數(shù)據(jù)整合模式 ?，支持連接于數(shù)據(jù)總線上的數(shù)據(jù)服務進行縱向的整合。

比如，當多個自治的獨立異構數(shù)據(jù)源(地域分公司，并購企業(yè))中，都存在核心的業(yè)務實體--主數(shù)據(jù)(如客戶，訂單)，可進行疊加轉換后，提供統(tǒng)一的只讀數(shù)據(jù)集。

整合的方式有兩種，一種是各數(shù)據(jù)源主動調用總數(shù)據(jù)集的基本服務接口進行發(fā)布。而另一種模式則是數(shù)據(jù)總線主動對各數(shù)據(jù)源進行拉取。

4.其他更強悍的需求

• 全文索引：支持相關性排序、模糊搜索，或者多個關鍵字搜索的搜索。
• 數(shù)據(jù)分析：支持數(shù)據(jù)挖掘，儀表板報告等。
• ETL。

5. 輕量級的數(shù)據(jù)服務

• ATOM/APP,GData ? ATOM/APP協(xié)議與Google,Microsoft的擴展實現(xiàn)。
• FaceBook的Data Store API Beta版
• snaplogic ? RESTful的python 數(shù)據(jù)整合框架，支持db,webservice的整合。

6. 其他實現(xiàn)項目

6.1 BEA Data Service Platform

• AquaLogic Data Services Platform
• SOA中的數(shù)據(jù)，第1部分：將數(shù)據(jù)轉換成信息(dev2dev)
• 邏輯數(shù)據(jù)服務 - "SCRUDI"設計模式(dev2dev)
• 使用數(shù)據(jù)服務進行數(shù)據(jù)集成(dev2dev)

支持基本服務接口，輸出Web Service，SDO，JDBC(只讀)等操作接口，偏重于基于XQuery的異構數(shù)據(jù)橫向聯(lián)合查詢。

6.2 其他

• JBoss DNA ?( 深入JBoss MetaMatrix ?) ，類似BEA，JBoss收購后還沒發(fā)布。

• LongJump Daas(Database-as-a-Service)

7. 其他參考資料

• 信息服務模式，第1部分：數(shù)據(jù)聯(lián)合模式 ?， 第 2 部分: 數(shù)據(jù)整合模式 ?， 第 3 部分：數(shù)據(jù)清理模式 ?(IBM DW)
• 在SOA中整合企業(yè)數(shù)據(jù)(InfoQ)

數(shù)據(jù)服務筆記