當前位置:工程項目OA系統(tǒng) > 泛普各地 > 河北O(jiān)A系統(tǒng) > 石家莊OA系統(tǒng) > 石家莊OA信息化
Web服務的計量與統(tǒng)計
Web服務的計量與統(tǒng)計
--一種動態(tài)電子商務解決方案
Dietmar Kuebler
軟件設計師,IBM Software
Group
Wolfgang Eibach
軟件設計師,Banking Solutions,IBM Software
Group
2001 年 7 月
作者在本文中描述了一個面向可由服務提供者為服務請求者實現(xiàn)的商業(yè) Web 服務的通用定價模型。他們提出的解決方案顯示了 Web
服務的使用如何被計量以及計量所得到的數(shù)據(jù)(供隨后的統(tǒng)計與記賬使用)。文中提出的解決方案自身以示例的方式作為 Web
服務得以實現(xiàn)。
對 Web 服務定價模型的需求
隨著 Web 服務在業(yè)界的發(fā)展,面向商業(yè) Web
服務提供者的商業(yè)模型會成為受到越來越多的矚目和討論的對象。如今發(fā)布的 Web
服務基本上都是免費的,因此并未對其價值進行衡量。然而隨著更高價值的服務(例如,支付處理)的出現(xiàn),對于一個能有效衡量由服務請求者調(diào)用的 Web
服務模型的需求也將不斷增長。由于這些服務并不依賴于瀏覽器,因此廣告收入在這一環(huán)境中多少會失去意義,這就必須用另一個模型來對其進行替換。
Web 服務及其體系結構的概述
Web
服務是一個被包裝成單一實體,且被發(fā)布以供其它程序使用的功能集合,它引入了由程序啟動的事務對使用瀏覽器人工啟動的事務的置換。它們能在分布式環(huán)境中得到描述、發(fā)布、發(fā)現(xiàn)以及動態(tài)調(diào)用,這意味著
Web 服務是完全建立在因特網(wǎng)標準之上的。
Web 服務背后的體系結構概念是面向服務的體系結構(service-oriented architecture,SOA)。它描述了三個基本角色:
服務提供者
服務中介者
服務請求者
如圖 1 所示,這些角色通過
find、bind 和 publish/unpublish 操作進行交互。
圖 1:Web 服務組件
服務提供者提供服務,并將它們通過注冊方進行發(fā)布。服務中介者為發(fā)布及定位服務提供支持。而服務請求者則通過服務中介者查找所需的服務并通過服務提供者綁定到服務。
創(chuàng)建 Web 服務定價模型的難題
當前 Web
服務倡議的發(fā)展相當快,并且面臨著許多技術難題,其中有:
可靠性與安全性
事務與可伸縮性
可統(tǒng)計性與測試,等等。
本文中簡要說明的解決方案主要關注的是 Web
服務的統(tǒng)計這一問題領域,特別觀察了面向服務提供者的商務管理以及他們?nèi)绾尾拍苡行У貫樗麄兯峁┑姆障蚍照埱笳呤召M。
計量與統(tǒng)計模型
計量與統(tǒng)計模型是專為 Web 服務設計的,它采用了比測量 IP
地址間的流量、對發(fā)送的電子郵件進行計數(shù),或者記錄特定用戶所使用的存儲量更為高級的方法。盡管它的設計是用來支持使用 Web
服務的服務提供者的,但每個提供者仍能在他們自己的系統(tǒng)中運行不同的 Web 服務??偟膩碚f,我們考慮的是:
簡單服務,類似股票行情服務或溫度服務等沒有服務質(zhì)量擔保、且可以免費獲得的服務。
客戶在商業(yè)交易中所使用的服務。在這種服務中,服務質(zhì)量起到了非常重要的作用,而該服務很可能不是免費提供的。
對于后一種服務,服務提供者需在使用時對其進行審計,并為其記賬。這通常是定期實行的,同時也是要用到計量和統(tǒng)計模型的地方。
模型是在這樣一個基本設想上進行操作的,即價值較高的 Web 服務是通過服務級別協(xié)議(Service Level Agreement)(SLA's)或其等效協(xié)議訂立合同的,這表明雙方對合同達成一致意見。合同涵蓋了服務慣例的所有屬性以及提供者和請求者如何對其進行使用,它的訂立為計量服務的使用建立了基礎。合同還可包含使用 Web 服務的環(huán)境先決條件。
一旦請求者(或客戶方)與提供者簽訂了合同(或進行了注冊),請求者就為提供者和服務計量所知了。這可通過用電子方式簽訂關于使用 Web 服務的合同和證書來實現(xiàn)。
合同提供了有關下列事項的詳細信息:
合同的類型:長期的、臨時的、限期的、無限期的,等等
合同的生效日期和終止日期
使用的時間模型:每天、周一到周五,等等
數(shù)量模型,規(guī)定了所提供服務的數(shù)量限制
安全性:加密與認證的簽名或證書
計量與統(tǒng)計服務通過證書的內(nèi)部使用將合同中詳細說明的請求者與提供者之間的關系存儲起來。這對于記賬用途來說特別重要,從而可以避免對服務請求者的錯誤收費。服務請求者在使用有合同的服務時必須同時使用一個帶簽名的
SOAP 消息。
請注意,合同的使用并不能排除不同地動態(tài)發(fā)布的 Web 服務之間的關系;它僅僅要求使用一個合適的使用模型。
計量的功能性適合很多可能的商業(yè)模型,如:
點擊付款/付費使用模型
預訂模型
租用模型
欲了解關于不同收入模型的討論,請參閱參考資料部分。
用途與功能性
計量與統(tǒng)計 Web 服務通常充當 Web
服務的資源計數(shù)器。它為下列事項提供了輸入:
根據(jù)服務提供者的等級模型進行記賬(例如:公共記賬接口)
支付與稅收處理
定義如下的功能與統(tǒng)計圖:
記錄用戶使用服務 xyz 的起始時間
記錄用戶使用服務 xyz 的結束時間
記錄一個特定用戶的全部資源使用量
報告每次請求的使用服務統(tǒng)計數(shù)據(jù)
創(chuàng)建服務請求者(Service Requestor,SR)賬戶(臨時賬戶和合同)
創(chuàng)建服務提供者(Service Provider,SP)賬戶
如果用戶標識得到使用所請求的服務標識(合同元素)的許可,則對查詢作出答復。
創(chuàng)建與 XML 一致的 IPDR.org 使用記錄
計量服務使得用 XML
文件那樣的標準格式來檢索使用數(shù)據(jù)成為可能。該數(shù)據(jù)能在成批的模型中使用,也就是說,它可供一個支持符合處理標準的輸入的記賬產(chǎn)品使用。
面向基于 IP 的服務的網(wǎng)絡數(shù)據(jù)管理用途
服務元素參與了基于 IP
的服務的傳遞,這些服務元素中的使用數(shù)據(jù)的交換用到了一些技術信息,IPDR 組織指定這些技術信息中哪些是充分的。他們開發(fā)了一個框架,可以限定 IP
網(wǎng)絡和服務元素以及支持系統(tǒng),并描述了系統(tǒng)間的關系。這一框架提供了一個模板,該模板指定了需要交換的 IP 資源類型和服務使用信息。
所有 IPDR 服務通用的元素是在一個單獨的 Master IPDR Schema
文檔中被聲明。服務專用模式指定了定義每項服務特定的 IPDR 元素所需的數(shù)據(jù)類型。在本文展示的引導實現(xiàn)中,我們根據(jù)計量與統(tǒng)計模型開發(fā)了一個 Web
服務專用模式。
概念體系結構的計量
圖 2:概念體系結構的計量
圖 2 展示了作為 Web
服務實現(xiàn)的資源計數(shù)器的概念體系結構。服務請求者(客戶方)在服務提供者的服務器上執(zhí)行服務。如果存在合同,并且調(diào)用的服務不是免費的,服務提供者就會向計量服務發(fā)送一個“記錄用戶起始時間”的請求。這一請求攜帶著服務請求者的用戶標識,可供計量服務作為關鍵字用來為該用戶查找統(tǒng)計模型及當前計量數(shù)據(jù)。被提議的概念還將計量服務定義為一種需使用
SOAP 消息進行訪問的 Web 服務。它允許服務提供者或者將計量作為在其自身的位置實現(xiàn)的本地服務,或者使用提供該項服務的可用的 Web
服務提供者。
計量服務在其數(shù)據(jù)庫中保存著不同的統(tǒng)計模型,它反映了服務請求者與服務提供者之間合同的統(tǒng)計部分。合同的這一部分可能指出了允許客戶方何時使用服務、每天或每月的服務最大使用量,等等。它還根據(jù)時間、調(diào)用數(shù)目或一些其它的模型規(guī)定如何對服務收費。
作為對“記錄用戶起始時間”的響應,計量服務可能會指出當前不允許客戶使用請求的服務,或者已經(jīng)超過了最大使用量。在得到肯定的響應時,服務提供者會執(zhí)行請求的服務,并且會在執(zhí)行結束后用“記錄用戶結束時間”的請求通知計量服務。
服務提供者可以隨時請求得到客戶方的統(tǒng)計數(shù)據(jù)供記賬使用。
解決方案的組件
圖 3
顯示了建立一個計量服務平臺所需的組件。與服務提供者的連接是使用 SOAP 通過 HTTP 實現(xiàn)的。我們假定計量服務是在 Web 服務器平臺上實現(xiàn)的。一個類似
Websphere 的 Web 應用服務器和一個 SOAP 服務器是 Web
應用服務器平臺上可用的標準組件。另外還需要兩個附加組件(稍后我們將加以討論)以實現(xiàn)計量服務。
圖 3:組件概述
資源計數(shù)器服務組件從服務提供者處接收進入的請求,提供被請求的服務并返回響應。該組件與一個帶有 XML 擴展的關系數(shù)據(jù)庫連接在一起,如帶有 XML 擴展器的 DB2,并為指定的服務請求者檢索統(tǒng)計模型和當前賬戶記錄。如果該統(tǒng)計模型不排除服務的執(zhí)行,則資源計數(shù)器服務組件將更新當前數(shù)據(jù),并給服務提供者一個肯定的響應,隨后該服務提供者開始執(zhí)行該服務。
已訂立合同的 Web 服務組件會對進入的 SOAP 請求進行認證。合同對于服務請求者必須可用,否則請求將遭拒絕。
使用案例
圖 4
中的順序圖表顯示了一個經(jīng)過認證的服務請求者是如何請求可記賬的服務的。服務請求者與服務提供者之間有一個有效合同。服務提供者利用過濾器來檢查請求者的權限,并與計量服務提供者進行交互。然后該過濾器在
SOAP RPC 調(diào)用過程中集成數(shù)字簽名。(請參閱參考資料部分中的教程,來獲取一個這樣的示例。)
圖 4:資源計數(shù)器使用案例
上述圖表示范的過程中執(zhí)行了下列步驟:
SOAP 綁定(SOAP Bind)請求服務提供者提供的 Web 服務
服務提供者過濾器使用提供的簽名來檢查服務請求者的認證,并在萬一沒有認證的情況下給出一個 SOAP 錯誤(SOAP Fault)響應。
SOAP 請求被發(fā)送給計量服務提供者,請求其對 Web 服務進行計數(shù),而計量服務提供者根據(jù)合同的詳細信息驗證服務提供者的請求,并開始計數(shù)
服務提供者執(zhí)行服務
Web 服務完成
SOAP 請求消息被發(fā)送到資源計數(shù)器以停止計數(shù)
SOAP
響應消息被發(fā)送到服務請求者,表明服務已經(jīng)完成,并返回結果
為簡單起見,我們省略了次要的交互作用(也就是出錯情況以及驗證簽名所需的認證機構)。
引導實現(xiàn)
我們實現(xiàn)了一個原型來展示計量的用法。代碼被集成到 IBM Web
Services ToolKit(可從 IBM Alphaworks 中獲得;請參閱參考資料)中的 Gourmet2Go 演示應用程序中。
圖 5 展示了由使用 Gourmet2Go 演示應用程序和注冊服務的用戶在幾次會話期間收集到的數(shù)據(jù)。正如我們先前討論過的那樣,服務根據(jù)不同的演示目的被分配了不同類型的使用模型。
結論
應包含在企業(yè)商務交易中的有價值的 Web
服務需要關于服務提供者如何對服務的使用進行收費的模型。在本文中,我們已經(jīng)就此問題展示了一個可能的解決方案。
一個使用該服務來計量 Web 服務使用的服務提供者首先在計量服務中注冊可用的 Web 服務。選擇使用服務提供者提供的某個服務(如,在仔細地查過 UDDI 注冊方以后)的服務請求者預訂使用該服務并訂立合同。合同的一部分是選擇一個預先定義的使用模型并在諸如 X509.v3 的證書標準上達成一致。這對于請求者簽名 SOAP 消息以及提供者評測正確的請求者都是必要的。一種典型的情況是,提供者定期使用計量服務來生成記賬數(shù)據(jù)對簽過合同的請求者進行收費。
我們建議的模型是作為 Web 服務自身來實現(xiàn)的。服務提供者能將一個類似的模型直接集成到其服務提供者平臺中,但這樣就會失去一些可能會飛速發(fā)展的 Web 服務的優(yōu)勢。
參考資料
- 請閱讀關于 Web 服務體系結構的內(nèi)容。
- 請閱讀 Web 服務設計師,第 2 部分:動態(tài)電子商業(yè)模型,看看關于 Web
服務和收入模型的價值問題的討論。
- 請從 IBM Alphaworks 頁中查找 IBM Web
Services Tookkit。
- 在這里您能找到關于 IPDR.org 倡議的所有詳細信息。
- 請使用關于 SOAP 數(shù)字簽名的出色教程。
- 白皮書: Dynamic e-business and with DB2 and Web services 展示了 DB2 是如何通過 DB2 XML 擴展器支持 Web 服務的。
Dietmar Kuebler 是一個在 IBM Boeblingen 實驗室工作的軟件設計師。他曾擔任過開發(fā)、技術營銷和項目管理幾個方面的各種職務,具有在多環(huán)境下進行結構設計和軟件開發(fā)方面的廣泛經(jīng)驗。它的專業(yè)技術領域包括 OO 技術、Java、WebSphere 以及中間件技術。
Wolfgang
Eibach 在 IBM Boeblingen
實驗室工作,擔任開發(fā)與體系結構方面的多個職務。他作為軟件設計師的專業(yè)經(jīng)驗包括大型的基于主機的軟件系統(tǒng)、OO 技術、MQSeries、Workflow
以及金融應用程序。
Dietmar 和 Wolfgang 目前正在 IBM Boeblingen 實驗室從事 Web 服務倡議的工作。
- 1借助RDF增強WSDL--管理結構化的Web服務元數(shù)據(jù)
- 2石家莊OA信息化隨筆之一:石家莊OA信息化“突圍”(by AMT 夏敬華)
- 3Web服務內(nèi)幕,第10部分:深入主題:可靠性和事務
- 4知識的經(jīng)濟學性質(zhì)
- 5ADO vs. ADO.NET Webservice
- 6Web Services: Building Reusable Web Components with SOAP and
- 7At Your Service, On the Web
- 8Sharing information through the Lotus Knowledge Discovery Sy
- 9Web服務設計師,第5部分:基于付費Web服務的障礙
- 10泛普軟件石家莊OA信息化IT實施步驟與策略
- 11微軟:“Web服務我們領先Sun 18個月”
- 12Building an ASP.NET Web Service
- 13Nasdaq、MS、PwC推出財務信息網(wǎng)上服務
- 14Web Services with ASP.NET
- 15BEA向Web服務互操作發(fā)展
- 16創(chuàng)造性的Intranet:Factors for Corporate Knowledge Creation
- 17Applying .Net to Web Services
- 18Building a Distributed Web Service Using a Strongly-Typed Da
- 19石家莊泛普OA軟件管理門戶登錄
- 20Consuming a Web Service from a Win Form Application
- 21架構Web Service:描述與注冊,發(fā)布Web服務
- 22透視Best Buy石家莊OA信息化實踐(by AMT 夏敬華 編譯)
- 23關于知識的問題
- 24將Web服務用于電子交易的單點登錄
- 25OA辦公系統(tǒng)軟件信息傳遞的安全解決方案
- 26Accessing Server Variables From Within Web Services
- 27尊重知識 崇尚理性
- 28關于石家莊OA信息化的幾個問答(by AMT 夏敬華)
- 29Accessing Web Services From DHTML
- 30企業(yè)CIO剖析中小企業(yè)信息化發(fā)展建設盲點.
成都公司:成都市成華區(qū)建設南路160號1層9號
重慶公司:重慶市江北區(qū)紅旗河溝華創(chuàng)商務大廈18樓