天天看點

動态Web services

動态 Web services             作者: Atul Saini

在今天的商業環境中,重要資訊存在與企業的許多異構系統中。

其包括:

•客戶關系管理(CRM)系統

•金融會計系統

•企業資源安排(ERP)系統

•Web servers

•遺留系統

這些資訊必須通過多觸點通路,這些系統已典型地演變為内部隔離的機構。他們注重與産品線和部門職能而不是客戶的需要,雖然如此,這些系統還是包含有戰略性資料。

包含了重要資訊的額外系統通常需要組合,是以商家極力尋找內建和商業過程管理(BPM)解決方案,這能擴充先前投資的壽命和增加投資的生産力。

現在有幾個平台能實作Web services——最著名的不同賣方的J2EE應用服務和微軟的 .NET Web services 都能提供基于标準的企業内或跨企業的資料存取方案。基于Web services 的實作內建解決方案允許企業動态減少與企業應用內建相關的傳統高額費用,這是因為Web services解決方案是基于工業标準的,不需要應用和産品所有者的特定知識。就因為此,許多企業願意為EAI和BPM采取基于Web services的解決方案。

EAI 的平台需要

不是所有的Web services平台能被用于EAI的out-of-the-box。這些問題包含在實作分布式EAI和BPM的解決方案中,在潛在的平台中增加特殊的需要。這節剩下部分就要讨論該需要,其是高效性和可擴充性所必需的。

完全分布式、對等網絡、基于事件的架構

   真實的商業過程是典型的多應用、多硬體和多軟體系統的分布式的;他們也是基于事件的,這是因為這些過程是典型的通過一系列事件連接配接在一起的。是以,一個平台應能努力實作企業内和跨企業需要的商業過程內建,它需要在完全分布式節點上運作這些過程。一個有效的EAI/BPM平台必須需要一個對等網絡的架構,用軟體引擎方法來開發,強調其各種安全性,控制權,動态通路和靈活性。該平台必須是對稱的,這意味着同樣基于事件基礎結構的軟體需要執行在企業内的所有機器上。大部分EAI和BPM解決方案通過中央系統控制商業過程,這樣,應用的改變或增加新的應用,就需要在中央系統改變。這種拓撲就存在效率低不夠靈活性,進而導緻在分布式系統中瓶頸的存在。

過程路由透明

一個EAI基礎架構平台應該在組成解決方案的不同過程中提供完全透明的資訊流。為了提供不用任何程式設計的靈活的改變管理能力,系統内各元件對過程的資訊路由應該是無須考慮的。

基于 service- 架構的靈活性

一個EAI平台應該保證其易于部署、管理和能改變參與的過程。這意味着一個基于元件的架構,在這個架構中的應用是由粗糙的元件松散組合的,它們通過基于事件的消息互相束縛,每個service潛在地運作在分離過程中。這容許一個快速的部署模型,減少實作解決方案的引導時間。這個架構提供對飛速修改的過程的支援工具,是以分析員能改變和即時重部署過程以滿足商業需求的改變。

遠端部署、監測和管理

一個EAI基礎架構平台應該能提供在網絡上的部署、管理和監測的方法。它也應該支援對資料和事件的實時監測,這将明顯減少時間和分布式商業過程的部署花費。

企業标準支援

   為了對資料交換、消息傳送支援,現存的企業标準和BPM能動态減少EAI基礎架構的整個花費。它無須考慮特定的需要或在部署方案中特定的知識,因為在商業夥伴之間需要交換的内容,擴充标記語言(XML)消息和文檔就是所期望的格式。大部分的商家欲用已存架構中的消息、元件、services、企業資料、輕權路徑通路協定(LDAP)路徑服務、e-mail系統,等等來開發系統。是以一個EAI平台需要保證容易實作這些标準。

現在 Web services 架構存在的問題

雖然為了EAI對Web services的興趣很高,但是現在的Web services平台對實作EAI還存在一些問題。這些已存Web services平台的原則問題(包括基于J2EE應用服務和微軟的 .NET)是:

請求 / 答複語義效率低

現存的Web services平台是典型的基于請求/答複語義的,每個Web services通過使用簡單對象通路協定(SOAP)請求聯系,然後子產品等待,直至結果傳回給調用者。平台是基于投票表決和需要人工編碼來擷取Web services的輸出的,并把它傳遞給不同的Web services或在工作流内的應用。在Web services内的資料流缺少事件總線,進而使得EAI解決方案中以存的Web services平台效率低下。

集中、不可更新的架構

現在的EAI解決方案通過中央系統控制商業過程,應用的改變或新的應用就需要改變中央系統。而且,在應用間的所有資料交換需要經過中央系統,這種拓撲結構将導緻分布式系統的瓶頸,并且引起明顯的效率低和不靈活。

缺少遠端部署、監測和日志

典型的分布式系統有許多services運作在跨網絡的不同機器上,如果任何這些services服務失效,在這系統上的其它元件應該被提醒。一個EAI平台應該要為這樣的分步式的監測提供services的建構,還要加上遠端跟蹤和日志設施。在遠端節點上自動部署Web services的另一個目的是可以減少維護和實作的費用。存在的中央Web services平台沒有對遠端service部署的支援,這是因為網絡的刹車沒有為部署提供基礎架構級别的支援,導緻為了解決方案的開發和部署增加了時間。

使用services 操作平台

現在Web services基礎結構平台不能解決相關EAI和BPM的核心問題,這些問題最好是采用事件方式的Web services解決,即我們所提到的動态Web services。最好在完全分布式情況下實作,有事件的基礎架構我們稱之為services操作平台(SOP)。SOP便于分布式的企業應用使用可視化工具進行合成、部署、和修改。一個強大的SOP就在于它能為公司的EAI、B2B內建、BPM、合作和通用分布式計算需要提供一個單一整體平台。

動态Web services

圖1所示為一個典型SOP節點的架構。在一個典型企業中,基于這種架構的每個網絡節點都運作着一個daemon,這些daemon通過消息總線相連接配接,就如圖2所示。從圖1中可以看到,一個SOP提供為基于事件的消息、透明過程路由、遠端監控跟蹤和日志、時序安排、現場和可用性、安全和遠端部署提供建構支援。

一個SOP是個純粹的基礎架構平台,它允許任何種類軟體的services實作,包括Web services。它不同于現存的Web services實作就在于它需要一個完全的分布式的對等網絡的使用消息的基礎架構,而不是一個中央請求/答複的基礎架構。一個SOP能為客戶提供這些優點。

動态Web services

基于 services 的應用合成

 部署在SOP上的應用是由一個或更多的services(或元件)複合而成的,每個service随意運作在分離的程序中。Services可能是任何語言編寫的并通過XML消息互相通信。這允許該結構是靈活的且易于修改的系統。

在飛速的商業過程中部署和改變

在SOP上的動态Web services實作是粗糙的services,它們很理想是易于改變和替代,而且在SOP上的services實作是很明顯的在services距離間路由。這使得它商業過程的飛速的修改動态服務替換或增加變得簡易。一個SOP也支援執行期services的部署,允許改變商業過程為通過網絡的即時部署,與傳統的解決方案相比這将是數量級上地降低部署費用。

錯誤容忍性、可測量性,可靠性

      SOP對稱的對等網絡的結構提供了高可測量可靠的平台,它沒有一個單點的失誤,缺少中央系統給予了應用開發者在所需services之間直接路由資料而定義網絡的拓撲選擇上以最大的靈活性。

元件級别的安全

一個SOP給予管理者以完全控制是哪個services被執行,在哪執行,同時確定安全。

SOP讓管理者為每個services設定任何數量上的安全屬性,并且提供工具配置在任何網絡上的點服務的安全設定。

執行期監測、跟蹤和日志

      一個SOP為執行期監測、跟蹤和日志包含自身、服務級别支援。所有的services能通過可視化工具進行監測。跟蹤級别能在已部署的services上動态改變,并且調試日志能被在任何節點上的軟體工具路由傳送。這些特點大大簡化了在SOP運作的分布式應用的開發、部署和調試。

 •

支援可視化過程合成和改變管理工具

一個SOP包含應用程式接口(API)以支援軟體工具的開發,它允許分布式應用的迅速合成,通過使用拖和點services面版上的可視圖示來建構應用設計者的商業過程。這同一環境也允許監測所有分布式網絡上的所有services。

支援企業标準

一個SOP使用基于标準的Java 消息服務(JMS)與标準的XML進行消息交換,使用XSLT資料能被翻譯成Tifosi  SOP和其它任何應用或服務格式。一個元件解決開發包(SDK)讓使用者能連接配接任何使用SOP的已存在的元件或服務。其它企業标準,例如簡單郵件協定(SMTP)和簡單網絡管理協定(SNMP),使得其能與其它企業系統進行內建。

支援通用目的的 services

一個SOP也支援不是實作為特定Web services的元件內建。一個通用目的的service能有任何不變數量的輸入和輸出端口,而一個Web service邏輯上僅有一個輸入和一個輸出端口。在他們的內建努力下,通用services為企業提供額外的靈活性。經常,它較容易模型化遺留程式代碼為通用目的的軟體service而不是特定的Web service。

結論

為EAI、BPM和相關企業問題以存的方法不能完全滿足這些問題對潛在基礎結構的需求。基于service的結構,在完全分布式、對等網絡、事件驅動系統上的實作,為企業平台空間帶來了整個新級别的通用性。

SOP實作了這種方式,闡述了BPM在應用和人們互動級别上的需要。它在企業内或跨企業的、跨領域的(包含被不同傳統解決方案服務的領域)闡述了這些需要。為了所有的分布式計算的需要,為了節省時間和金錢,為了增加跨部門的處理效率,一個SOP保證允許一個企業建立一個統一的計算基礎架構。

About the Author

eAI Journal • April 2003 19

Atul Saini is CEO

and chief technical

officer of Fiorano

Software. Through his

leadership, the company’s

flagship product,

FioranoMQ, has

become a leading

繼續閱讀