當前位置:工程項目OA系統(tǒng) > 泛普各地 > 河北O(jiān)A系統(tǒng) > 石家莊OA系統(tǒng) > 石家莊OA信息化
Web服務網(wǎng)絡:簡化企業(yè)間工程的中介
Web服務網(wǎng)絡:簡化企業(yè)間工程的中介
Kelly Truelove(kelly_truelove@hotmail.com)
獨立顧問
2001 年 10 月
與通宵的遞送服務所做的大致一樣,Web 服務可以作為一起工作的不同公司的中介,從而幫助他們更有效地做生意。然而,Web
服務的這種環(huán)境并不失其復雜性,它僅僅超出使多組織一起工作的商業(yè)問題。Kelly Truelove 研究了潛在的 — 使用 Web
服務作為中介的潛在問題。
在物質(zhì)世界中,企業(yè)在彼此進行商務的過程中使用很多中介。例如,“聯(lián)邦快遞公司”(Federal
Express)包裹遞送網(wǎng)絡大大簡化了組織間的貨物運輸和通信,代替了那些必須建立定制的點對點的遞送系統(tǒng)。Web 服務網(wǎng)絡通過使 Web 服務(Web
服務是由不同企業(yè)操作的)間通信更便利來執(zhí)行類似的中介職能。和現(xiàn)實情況一樣,中介通過解決許多疑難問題來增加巨大的價值,否則這些問題將留給企業(yè)自己解決。一個起步者,Grand
Central,已經(jīng)在 Web 服務網(wǎng)絡的概念上處于領先,并已經(jīng)實施了這種服務。(請參閱參考資料。)
用于自動的后端企業(yè)對企業(yè)集成的 Web 服務
在深入之前,一些關于 Web
服務和企業(yè)間工程的詞匯要確定。由術語“Web 服務”想象到的一般印象是一個企業(yè)門戶網(wǎng)站,它把來自多個資源的數(shù)據(jù)和功能性集成到單一的最終用戶視圖。Web
服務標準確實支持這種前臺集成,它使從分布式元素創(chuàng)建最終用戶應用程序輕松一些。
然而,重要的是 Web 服務也適合于應用程序間的后臺集成。這里,我將重點放在后臺方案,方案里為了業(yè)務過程的自動執(zhí)行,應用程序使用 Web 服務接口相互鏈接(服務器到服務器)。
當有關的 Web 服務是由不同組織操作時,該方案提出了特殊的要求,這正是本文所涉及到的情形。
中介提供缺少標準的環(huán)境支持
集成工程自然趨向于集中在數(shù)據(jù)格式和過程調(diào)用明確的問題,但是組件集成中有關的環(huán)境同等重要。
Web 服務標準在簡單性和開放性方面是強大的。然而,目前它們的范圍還沒擴展到超出數(shù)據(jù)格式和服務描述的面向內(nèi)容的問題,達到服務間交互操作的面向環(huán)境的問題的程度。與物質(zhì)類比,地址格式標準、包裝樣式以及“裝運”和“接收”方法存在的描述并沒有解決當包裹遞送了,可辦公室卻鎖著這種與環(huán)境相關的問題時該做什么。返回給發(fā)送方?嘗試明天再遞送?還是放在門口?
“聯(lián)邦快遞公司”作為中介增加價值的一種方法是通過為包裹遞送定義一個通用接口。每一個組織以其自己的特點(關于工作時間、位置以及裝運和接收部門的策略)與“聯(lián)邦快遞公司”建立一個連接。這種方法,N 個公司定義 N 個關系,而不是組合 N2 個在其它情況下必需的鏈接。巨大的效率產(chǎn)生了。Web 服務網(wǎng)絡給企業(yè)間 Web 服務工程帶來同樣數(shù)量級的成本縮減。在這兩種情況下,中介解決面向環(huán)境的要求來增加價值?;氐筋惐?,“聯(lián)邦快遞公司”能允許發(fā)送方或者接收方就如果包裹沒有簽收時是否可以留下,作一個獨立的面向環(huán)境的選擇,使收發(fā)方免于擔心在這一點上的協(xié)調(diào)。
企業(yè)間工程面向環(huán)境的要求
很多 Web
服務工程迄今都是在企業(yè)內(nèi)的,在防火墻后(環(huán)境經(jīng)常在這里被隱式地理解)執(zhí)行。然而,正如使用其它技術的企業(yè)間工作的老手們清楚地意識到,這種情形在防火墻外更具有挑戰(zhàn)性,那里不同組件的運營者不能控制(或者看到)彼此的系統(tǒng)。在此種情形下,不能對通常的環(huán)境的理解想當然。
企業(yè)間 Web 服務工程提出了兩大類具有挑戰(zhàn)性面向環(huán)境的要求:
I. 通信要求:
在因特網(wǎng)跨越防火墻集成所需的元素:異步、加密、可靠性和不可抵賴性以及輪詢。
II. 協(xié)作要求:
安全地發(fā)布 Web 服務或者使用和集成 Web
服務來形成企業(yè)間業(yè)務過程所需的元素:訪問控制、實現(xiàn)抽象、路由以及注冊中心和發(fā)現(xiàn)。
通過更深入地研究其中的每一點,我們發(fā)現(xiàn)在直接的企業(yè)對企業(yè)基礎上處理這些要求具是有挑戰(zhàn)性的。
I.
通信要求
異步
企業(yè)間后臺集成工程通常最好是使用異步消息傳遞,因為它允許參與者以最小的互依賴性操作。這通常是穿越防火墻(這里被連接的系統(tǒng)可能有關于響應和自主性的不同策略)的集成要求。異步方法在執(zhí)行公司間復雜的業(yè)務過程是尤其有價值,它們可能要花數(shù)分鐘、數(shù)小時甚至數(shù)天來完成,在那里等待或者阻塞于一個響應將是不切實際的和不可伸縮的。然而,當考慮到多公司交互操作時,異步協(xié)調(diào)的邏輯是很嚇人的。誰擁有不能被傳遞的消息?
加密
經(jīng)過加密的安全性是因特網(wǎng)上企業(yè)通信的標準要求。雖然使用現(xiàn)有標準提供這個功能相對容易,但是使用不同標準或者強加不同策略使多公司的業(yè)務過程復雜化。在多公司集成中,哪一個組織擁有能被別的組織采納的標準或者策略?
可靠性和不可抵賴性
與加密相似,可靠性和不可抵賴性是企業(yè)對企業(yè)通信的標準要求
—
但是在直接企業(yè)對企業(yè)方案中它們處理起來特別困難。如果沒有接收到消息,誰判定誰應該負責任?什么權威機構規(guī)定不可抵賴性?
輪詢
在指定的
Web 服務通信中,一方自然是發(fā)送方,而另一方就是接收方。然而,接收方可能不希望不斷偵聽到來的消息所導致的花費,而是周期地輪詢發(fā)送方。一般來說,Web
服務模型吸引人之處是在能滿足不改變組織防火墻的要求方面。然而,如果收發(fā)方不得不作調(diào)整以不斷地偵聽消息的話就會失去這個優(yōu)勢。當其它方不得不偵聽消息的時候誰開始享受輪詢的樂趣?
II.
協(xié)作要求
訪問控制
敏感數(shù)據(jù)交換或者專有服務公開使參與組織間的謹慎的信任管理成為必要。難題是業(yè)務過程經(jīng)常擴展超出了端對端關系中的兩方。相反,該體系結構必須滿足管理動態(tài)的多對多關系的要求。結果,企業(yè)間工程要求一個構建在由像證書認證那樣的標準提供的訪問控制上的信任管理模型。在多公司集成中誰維護該模型?
實現(xiàn)抽象
把一個抽象層添加到系統(tǒng)接口非常有助于滿足把服務管理成本減到最小的要求。創(chuàng)建獨立的公共接口(從后端實現(xiàn)分離)允許改變或升級
Web
服務而不破壞可能依賴于它們的系統(tǒng)。企業(yè)對企業(yè)集成中抽象層被定位在防護墻的哪一邊?
路由
在不同企業(yè)中,特定業(yè)務過程的實現(xiàn)可能要求多個不同企業(yè)間
Web
服務的串連或編排。企業(yè)間業(yè)務過程管理在一種情況下是獨一無二的,這種情況就是被編排的特定過程典型地比那些在防火墻后找到的過程簡單,然而由于不同公司和系統(tǒng)在執(zhí)行它們,所以它們可能更難實現(xiàn)和管理。同樣,Web
服務的業(yè)務處理管理組件必須在其執(zhí)行時向過程提供可見性,并且在它將不同的企業(yè)系統(tǒng)投入運行時管理過程的狀態(tài)。在自動的多企業(yè)業(yè)務過程中哪一方管理這種編排所涉及的路由?
注冊中心和發(fā)現(xiàn)
包括眾所周知的
UDDI 規(guī)范,注冊中心和發(fā)現(xiàn)涉及與發(fā)布和查找位置、綁定以及訪問控制信息相關的 Web
服務要求。它在區(qū)分一批有限的合伙人(典型為企業(yè))間的私人協(xié)作和服務(典型為服務提供者)的公開宣傳方面是有用的。這兩方面的差異,尤其是企業(yè)要求產(chǎn)生了專用 UDDI
目錄(在此根據(jù)一批有限的參與者的策略可以控制注冊中心和發(fā)現(xiàn))的概念。哪一方維護這樣一個注冊中心?
使用中介處理面向環(huán)境的要求
上面討論的面向環(huán)境的要求呼吁企業(yè)間工程中需要中介。取代中介,組織必須參與決策,誰擔任什么角色,結果都是技術和商務兩方面令人頭疼的事。當集成涉及到的各方數(shù)量增加時,困難成指數(shù)放大。此外,這些中介功能沒有一個必須是尋求集成的企業(yè)的特征。正如包裹遞送網(wǎng)絡類似,很需要專門的中介,其核心能力專門滿足這些面向環(huán)境的要求。
Web 服務網(wǎng)絡:強大的中介
Web
服務網(wǎng)絡作為一個無所不在可訪問的服務工作,該服務滿足本文討論的通信和協(xié)作要求。
作為運行在因特網(wǎng)上端的服務,Web 服務網(wǎng)絡的功能性可以容易地并入到現(xiàn)有的應用程序。
在通信前端,Web 服務網(wǎng)絡可以為異步傳遞排列消息并提供通過輪詢的隊列訪問。與包裹遞送網(wǎng)絡相似,Web 服務網(wǎng)絡能夠?qū)煽啃院桶踩载撠?,并提供象“?lián)邦快遞公司”一樣的消息跟蹤作為不可抵賴性機制。根據(jù)協(xié)作,中介可以充當服務間信任管理點。此外,它被獨特地定位于在支持多企業(yè)業(yè)務過程的服務間路由消息。最后,通過 Web 服務網(wǎng)絡公開它們的接口,系統(tǒng)得到引入實現(xiàn)抽象的層。
簡而言之,正如企業(yè)通過把裝運和接收部門并入包裹遞送網(wǎng)絡而不是直接將它們系在一起來享有很高的效率一樣,企業(yè)通過利用 Web 服務網(wǎng)絡的功能性,可以大大簡化企業(yè)間 Web 服務工程。在這兩種情況下,中介通過解決與面向環(huán)境有關要求的疑難問題增加巨大的價值,使企業(yè)得到解放從而將精力放在它們的業(yè)務上。Grand Central 已經(jīng)在該領域確立了地位并得到了從事企業(yè)間 Web 服務工程開發(fā)者的關注(請參閱參考資料)。
參考資料
- 請參與關于本文的討論論壇。
- Grand
Central 是公司間 Web 服務中介。
- 聯(lián)邦快遞公司正在研究 Web 服務以便在他們系統(tǒng)中使用。
- Intelligent EAI,是 CMP 的 Intelligent Enterprise 的一部分,定期地涉及一些集成問題。
IBM
參考資料
- IBM Systems Journal 的用
tpaML 的企業(yè)對企業(yè)集成和企業(yè)對企業(yè)協(xié)議框架,描述了一些 B2B
集成固有的問題并提出了一些解決方案。
- 中介:處理信息流的方法,也是來自 IBM Systems Journal,主要(但并非專門)是中介應用到信息流中,研究物質(zhì)世界和虛擬世界中很多不同類型的中介服務。
Kelly Truelove 最近是 Clip2 的的創(chuàng)始人和 CEO,他在那里領導致力于對等文件共享系統(tǒng)和分布式系統(tǒng)平臺領域的研究與開發(fā),包括 Gnutella、OpenNap/Napster、FastTrack Morpheus、JXTA 和 Web 服務。他參與合著了 O'Reilly Research 2001 P2P Networking Overview,為 O'Reilly Network 撰稿,服務于 JXTA TechnicalAdvisory Committee 并為相關的主題作顧問。Truelove 的技術背景包括從事對等搜索系統(tǒng)的研究,用法規(guī)范人類生成 Web 目錄以及計算天體物理學。他擁有加利福尼亞大學克伯利分校的物理學博士學位。
- 1走出石家莊OA信息化的迷思(BY AMT 夏敬華)
- 2Web服務網(wǎng)絡:簡化企業(yè)間工程的中介
- 3Web服務面臨的課題:安全和標準化
- 4石家莊OA信息化的基本XML和RDF技術(四):問題跟蹤程序模式
- 5Web服務內(nèi)幕,第10部分:深入主題:可靠性和事務
- 6鄂爾多斯投資控股集團智能協(xié)同OA移動辦公系統(tǒng)介紹
- 7協(xié)同辦公OA軟件對系統(tǒng)登陸的安全設置
- 8石家莊OA信息化,知識組織和知識工作者:來自前沿的觀點
- 9SOAP與RDF--超越遠程過程調(diào)用
- 10SOAP技術與B2B應用集成--SOAP的消息結構與數(shù)據(jù)的組織方法
- 11組織學習的五個子系統(tǒng)
- 12中小企業(yè)如何化解經(jīng)濟危機
- 13不同視角看石家莊OA信息化技術(by AMT 夏敬華)
- 14OA內(nèi)容管理與知識管理方案介紹
- 15WebLogic Workshop給非開發(fā)人員帶來Web服務
- 16利用辦公自動化系統(tǒng)進行石家莊OA信息化
- 17Web服務的(革)創(chuàng)新,第2部分
- 18Web服務的(革)創(chuàng)新,第3部分
- 19At Your Service, On the Web
- 20協(xié)同之惑
- 21送你一雙慧眼 識破偽石家莊OA信息化軟件
- 22泛普軟件石家莊OA信息化實施階段劃分
- 23A Platform for Web Services
- 24端到端的挑戰(zhàn)者
- 25透視Best Buy石家莊OA信息化實踐(by AMT 夏敬華 編譯)
- 26超越石家莊OA信息化
- 27OA辦公系統(tǒng)可以幫助企業(yè)擺脫束縛
- 28OA辦公系統(tǒng)的信息發(fā)布與管理門戶介紹
- 29IBM推新工具包助用戶跨平臺開發(fā)Web服務
- 30Web Service Case Study:軟件反饋跟蹤平臺
成都公司:成都市成華區(qū)建設南路160號1層9號
重慶公司:重慶市江北區(qū)紅旗河溝華創(chuàng)商務大廈18樓