重用所面臨的障礙
重用一直是軟件開發的首要目標之一。這很明顯:如果您編寫了一段代碼來實現某種功能,如果無需在其他很多地方再重新編寫或維護它,那么無疑會提高生產率。然而,重用實現起來并不輕松,也并非自動化的。首先,必須以一種可重用的方式來組織或編寫代碼。然后,必須知道存在一段可以被重用的代碼。在組織代碼方面,不同的編程語言以不同的方式為重用提供內置支持。過程和函數是大多數程序員所熟悉的基本單元。面向對象的語言,比如C++和Java,還提供了定義和擴展自定義的類型或類的手段。這些特性背后的基本理念就是封裝(也就是說,只需通過一些定義良好的接口來訪問其中的功能,實現對于您而言是一個黑盒子)。這些特性有其用途和優點,但是當涉及到支持更大規模的重用時,它們也存在一些局限性。
﹡ 首先,這些編程語言工件是非常低級的,只有特別熟悉它們的程序員才能進行有效的重用。
﹡ 其次,即便是在同一個項目團隊中,要發現可重用的資產也不是一件容易的事情,更不用說在企業范圍內了。
﹡ 最后,這個層面上的代碼并不支持網絡,這意味著無法跨機器調用這些代碼,也無法在另一種編程語言中透明地重用它們。例如,假定我已經使用C++編寫了一個定價模塊,那么不費一番工夫,我是無法在Java中調用這個模塊的。
在這里我想表達的是,這些特性肯定有其用處,但是這個層面上的重用實際上就是剪切和粘貼代碼,這易于出錯而且不可擴展。
面向重用
“服務”這個概念的出現就是為了解決這些重用問題中的一部分。CORBA是對象管理組(Object Management Group,OMG)提出的一個標準,這或許也是使用基于標準的分布式計算模型來解決重用問題的首次全面努力。
其思路是,通過一個抽象接口正式實施封裝的概念,并提供一組可由這些服務(或CORBA技術中的對象)使用的基礎性服務。接口是使用一種叫做IDL(Interface Definition Language,接口定義語言)的語言定義的,而且為各種編程語言定義了映射。服務可以使用這種語言來描述。要使用某個特定的服務,只需使用IDL即可,而無需了解實現該服務的實際細節。這些服務還支持網絡。這提供了一種跨硬件、語言和網絡的便利途徑。
CORBA還定義了一套豐富的基礎性服務,比如用于注冊和發現對象的目錄服務(稱為命名(naming))、基于公開屬性發現對象的交易(trader)服務、用于異步通信的通知服務、事務服務,等等。所以,現在可以快速構建服務,因為可以利用這些基礎性服務。還可以跨越多種邊界輕松重用這些服務。其他的分布式組件模型,比如微軟的DCOM和J2EE,都以一種或多或少類似的方式來構建和使用服務。
SOA到底是什么?
現在,我們已經準備給出面向服務架構(即SOA)的定義了。遺憾的是,關于SOA,存在多種定義,有時它們還相互沖突。很多定義都結合了一種特定的技術(特別是Web services),或者在定義中包含一種特定的特性(例如調用類型)。我將給出一些我認為抓住了SOA本質、而不是將其與特定的技術相關聯的現有定義。但是,首先讓我們看一看面向服務架構中的術語“服務”。
定義SOA中的服務
服務是一個被過度使用的術語,但是卻沒什么好的定義。服務就是一種能夠以分布式方式調用的功能,它是定義良好的、自包含的,并且不依賴于上下文或其他服務的狀態。讓我們看一看構成服務定義的一些特征:
﹡ 能夠以分布式方式被調用。這很重要,因為我們不能假定某個功能是處在客戶端環境中。
﹡ 定義良好。正如早先討論的那樣,重用在編程語言層面上面臨的一大難題就是難于發現可重用的資產并跨越各種技術使用它們。一個服務應該能夠在一個眾所周知的目錄中描述和注冊自身,而希望調用服務的客戶端則應該能夠完全基于已注冊的信息來調用服務。
﹡ 自包含。一項操作的語義應該由即將進行的操作中的信息和服務狀態所決定,而不應該依賴于其他某個服務的狀態或上下文。這種隔離使得理解服務提供的功能和對其進行重用變得更加容易。
定義SOA
現在,讓我們看一看一些SOA的不同定義。W3C把SOA定義為“一組可調用的組件,其接口描述可以被公開和發現”。我個人不太喜歡該定義中使用的組件這個詞,因為組件是一個被過度使用的術語,會讓人聯想起特定的內容,比如ActiveX、EJB等等。然而,如果我們使用服務來代替組件這個詞,那么這種定義是合理的。
ZapThink是一家行業分析公司,它把SOA定義為“一種架構準則,其中心內容是把IT資產描述和公開為服務。然后可以把這些服務以松散耦合的方式作為高級業務流程的一部分,從而在面臨IT異構性時提供業務靈活性”。我較為喜歡這個定義,因為它使用了IT資產這個術語來定義SOA,范圍更為廣泛。此外,它還指出了SOA的一個重要特性——松散耦合(稍后將進行詳細說明),并提及了SOA的優點。
最后一個定義來自于BEA的dev2dev站點的SOA技術中心,在這個定義中,SOA被定義為“一種設計方法,其目標是重用應用中立的服務,從而提高IT適應性和效能”。這是SOA在業務層的一個優秀定義。它強調了一個事實:SOA不僅僅是一個技術工件(像接口和協議一樣),它其實是一種設計方法,具有最大化重用的明確目標。我想為這個定義添加一些內容:它不僅是設計方法(這只是前端部分),還是涉及到服務的整個生命周期——服務的設計、部署、維護和最后的停止使用——的方法。
希望這3個定義能夠讓您了解什么是SOA及其目標。在進入下一節內容之前,我想談談SOA的一個重要特性——松散耦合。耦合即組件相互依賴的程度?梢詫⒎⻊赵O計在一起,即緊密耦合;也可以動態發現和使用服務。松散耦合是我們想要實現的目標,因為它可以降低服務或組件之間的相互依賴性,并讓您可以輕松替換或更新服務。
SOA和分布式技術
從有關CORBA和J2EE的討論中,您可以看到,這兩種技術都提供了構建SOA的方法。這些技術已經跨不同行業進行過幾次成功的部署。然而,如果要在企業級評估重用,那么即便是在已經部署這些技術的企業中,重用也沒有達到應有的水平。在某些企業中,從業務的角度看,大量“服務”實際上都在執行同樣的任務,比如驗證信用卡、查找雇員等等,這種情況并非罕見。
為什么會存在這種重復呢?主要有如下兩個原因:
﹡ 異構性或多中間件問題:一家典型的企業通常使用多種應用程序、工具和技術。同樣的情況也適用于中間件:Java領域可能使用J2EE,而Microsoft領域則使用DCOM,諸如此類。從構建服務的角度看,這意味著可以通過多種方式描述接口(IDL用于CORBA,MDL用于DCOM,Java用于J2EE)。此外,由于每項技術都定義了自己的傳輸協議,所以有多種使用這些服務的方式。盡管人們曾經嘗試搭建“橋梁”來連通這些技術之間的不同編程模型和傳輸協議,但實際的用戶體驗還是很糟糕:無法理解的映射(試試從Java到IDL的映射就知道了),這類“橋梁”的糟糕性能,供應商由于互操作性問題而相互責怪。簡而言之,無論是定義還是使用服務的方式都不是通用的,從而影響了互操作性,而使重用難以實現。
﹡ 這些技術的復雜性:這些技術都相當復雜,難于學習,需要了解一個新的API和一個新的編程模型才能使用這些技術。使用這些技術構建服務需要編寫大量的代碼,尤其是對于CORBA來說。在這方面,J2EE做得要稍好一些,因為它支持使用更為聲明式的方法來構建服務。然而,即使是J2EE也無法讓人滿意,因為程序員要掌握數十個API才能達到一定的效率。復雜性的另一方面體現在管理這些服務的生命周期上,例如,部署服務、對服務進行版本控制、停止使用服務。這些技術在這方面的支持很差,只有J2EE稍好一些,而CORBA和DCOM都有其各自的優點。然而,對于每個企業來說,有效地管理這些服務都是一件傷腦筋(且開銷巨大)的事情。
所以,盡管分布式組件技術為構建SOA提供了明確支持,并且基于行業認可的標準,但上述兩個因素在企業層面上妨礙了重用的實現。注意,實際的情況還要更糟,因為要使用這些基于標準的技術,企業需要讓系統基于專用的中間件技術,比如MQ和TIBCO。所有這些系統,無論是基于標準的還是基于專用技術的,都應該被認為是企業的IT資產,因為在構建這些系統的過程中企業進行了大量的投資。這些現有系統中已經存在的功能必須被公開為可重用的服務,從而使用它們輕松構建新的系統。使用CORBA和J2EE的經驗告訴我們,引入另一組API或另一種傳輸協議無法解決這個問題。我們需要做的是對消息格式進行標準化,并使用已經在企業中普遍應用的傳輸協議,比如MQ和IIOP。在下一節中,您將會看到Web services是如何滿足這種需求的。
Web Services是救星?
Web services基于很多與Internet和Web相同的技術,它解決了分布式組件模型所具有的很多問題。我假定您已經對Web services有了一些基本的了解。對于想要快速入門的人,可以參考本文結尾處的參考資料部分。在這一節中,我將說明Web services是如何解決CROBA和J2EE之類的分布式組件模型的局限性的。
﹡ Web services使用HTTP作為其傳輸協議。HTTP已經被廣泛采用和認可,這不僅有助于增強互操作性,而且使用現有的基礎架構還可以提高操作效率。注意,Web services實際上是獨立于傳輸協議的,HTTP只是可以使用的傳輸協議中的一種而已?梢詫eb services使用已經在企業中普遍應用的傳輸協議,比如MQ和IIOP。
﹡ XML的使用。Web services使用XML來描述接口和需要在服務及其消費者之間交換的消息?梢允褂肳eb services描述語言(Web services Description Language,WSDL)來描述通向某個Web服務的接口。盡管從表面看來,WSDL類似于IDL或Java接口,但是WSDL的功能更為強大,并擁有支持服務松散耦合的構件。例如,WSDL支持多個類型系統,所以可以使用它來描述使用大型主機類型系統的服務。它還支持多種協議和傳輸方式,例如,可以指定某個特定的服務基于JMS而不是HTTP可用。最后,借助于WSDL,可以以一種抽象方式定義Web服務的操作性行為,然后在不同的網絡端點將其綁定到訪問它的特定方式。
﹡ 承諾降低復雜性。分布式組件技術之所以復雜,原因之一就是它們規定了自己的編程模型,因此需要學習一組新的API。相比之下,Web services就沒有指定任何新的編程模型,您可以繼續使用您所熟悉的環境,包括J2EE或CORBA。這還意味著,可以選擇使用任何編程語言——C++、Java、Perl。Web services其實是一種接合和消息傳遞技術。
從上面的討論中可以看出,Web services實際上解決了與分布式組件模型相關的許多問題。Web services最適用于部署SOA。
然而,我們尚未完全實現這一目標。前面我曾提到過,當討論與分布式組件模型相關的復雜性時,造成復雜性的主要原因是難于支持服務的整個生命周期,這不僅涉及到服務的構建,而且還涉及到對服務的部署、版本控制、保護和管理。我們還需要對服務的定義進行擴展,以便包容企業現有的資產,即使企業不是基于SOAP和WSDL之類的Web services技術。這包括在消息解決方案之外構建的集成,比如.NET、MQ Series、TIBCO和遺留及打包應用程序。為了支持真正的重用,我們需要打破企業中存在的屏障。我們還需要使這些服務的發現和使用更為輕松——這不僅涉及到程序員,而且還涉及到操作人員甚至是業務分析師。
服務基礎架構:新興解決方案
我們看到,行業基于共同的經驗教訓在繼續發展。上述討論不應該被理解為傳統技術在企業中沒有存在的位置或價值。我們仍然需要面向對象的編程語言,比如Java、分布式組件技術和消息傳遞系統,來構建新的系統。正如前面提到的那樣,問題在于通過把這些系統中的功能看作服務并支持利用這些服務創建新的復合應用程序,從而跨現有的技術筒倉來支持重用。盡管使用現有技術進行手動構建是可行的,但是這樣做既不輕松,也不經濟有效。就像我們使用J2EE作為構建應用程序的基礎架構一樣,我們也需要一個類似的基礎架構來組成、消費和管理企業中服務的生命周期。簡而言之,我們需要服務基礎架構(參見圖1)。這類服務基礎架構的本質特征應該包括:
﹡ 多中間件支持:CORBA、J2EE、MQ、Tuxedo——這些技術都在企業中用于集成;谶@些產品和技術構建的應用程序已經變成了一個筒倉,因為企業中可能會出現多個無法交互的“域”。服務基礎架構應該允許企業基于合適的粒度水平在這些筒倉中公開有用的資產。有了用于發現這些系統中的元數據并基于它們自動創建服務的工具之后,這類服務的公開應該會變得更加容易。所有這類服務都應該以一種統一的方式被公開,并根據它基于的技術進行抽象,例如,我應該能夠利用基于MQ的帳單編制功能和基于Tuxedo的呼叫處理功能構建一個新的復合應用程序,而不必學習有關MQ或Tuxedo的任何知識。
﹡ 對多種傳輸方式的支持:JMS、MQ、FTP、HTTP等都是現今在企業中普遍應用的傳輸方式,而且在不久的將來還將繼續使用。服務基礎架構不僅應該支持這些傳輸方式,還應該提供一種使用企業的專用協議或傳輸方式擴展它們的方式。另外,服務基礎架構應該直接進行協議轉換,而不應讓服務使用像HTTP這樣的通用協議。對于某些高性能的應用程序來說,這很重要,因為轉換到標準消息或使用像HTTP這樣的協議所帶來的開銷可能是不可接受的。
﹡ 服務的發布和發現:服務必須先被發現,然后才能被重用。需要使用某種形式的注冊庫來發現現有的服務(目錄應該基于某種查詢或瀏覽格式),從而注冊或發布新的服務。另外,對這些服務使用的策略需要進行定義和注冊,這類策略可以描述諸如使用服務的成本和安全特征之類的內容。
﹡ 服務運行時和生命周期管理:這涉及到監控服務的可用性、服務的故障恢復、服務的版本控制,或者停止使用服務。簡而言之,必須提供高級的操作性支持。在前幾代的集成和中間件產品中,管理和操作性支持似乎是馬后炮。這給大多數企業造成了相當大的麻煩,并提高了成本。服務基礎架構應該以操作性考慮為核心。另一個重要的方面是,由于可以在多個應用程序中重用服務,服務的不可用性將影響到依賴于它的所有應用程序。因此,應該提供用于服務版本控制和升級的特殊方式。
﹡ 對服務復合的支持:這涉及到使用現有服務構建新的復合應用程序。由于服務本身是應用中立的,可以用在服務的初始設計者預想不到的上下文中,所以必須支持消息轉換、基于消息內容的路由和對一些簡單條件邏輯的引入。
﹡ 服務安全性:安全性顯然是一個大問題,所以必須支持基于某種策略、使用審計、警報觸發機制的服務訪問控制。此外,由于服務可以橫跨具有其獨有安全性模型的多個應用程序,所以必須提供與這些安全性模型的集成,從而提供端到端的安全性。
﹡ 易用性:服務基礎架構本身不應該引入新的編程模型或API。它在本質上應該是高度聲明式的,幾乎或完全不需要編碼。這應該由非常直觀的可視化工具提供。
圖1.服務基礎架構的基本要素
我們的目標達到了嗎?
服務基礎架構在支持SOA和增強重用方面走了很長一段路。這代表著整個行業在支持重用和簡化系統構建方面所做出的共同努力。毫無疑問,基于在部署利用這類基礎架構的新應用程序方面的經驗,整個行業將會繼續發展。很多公司都很關心Web services標準的數量,其中一些標準是由相互競爭的供應商陣營所驅動的。供應商之間需要進行更多的合作,不僅要快速聚合Web services和安全性領域中的一些重要標準,而且要解決實際的測試和驗證問題,這樣才不會由于產品的互操作性而給客戶造成不便。
我列出了一組有關服務基礎架構的長長的需求清單。好消息是市場上已經出現幾種支持其中絕大部分功能的產品。然而,有一點必須意識到:僅僅通過購買一種聲稱支持這些特性的產品,企業還不能擁有能夠交付靈活性和敏捷性價值的服務基礎架構。SOA和支持SOA的服務基礎架構是可以轉換的,因此需要對組織、流程管理和文化進行更改。IT組織應該實施架構一致性,并使自身與其業務風險承擔者之間的同盟關系更加緊密,以便在進行轉換時獲得支持和資金。流程應該按照如何交付服務以及如何管理SOA中參與者之間的相互依賴性進行定義。一些被大多數應用程序重用的服務可以是水平的和一般性的,其他的則可以專門用于一些選定的應用程序。一個涵蓋如何為這些服務提供資金以及如何開發這些服務的管理模型頗為重要。最后,文化應該鼓勵和獎賞對現有服務的重用,而不是從頭開始構建一切。
所有這些內容聽起來可能令人生畏,但是實際情況是,這確實是一項令人生畏的任務。然而,現在出現了一些有利于開發的好兆頭。首先,Web服務互操作性(Web Service Interoperability,WS-I)小組特別制定了圖表,以便改進跨不同實現的Web服務互操作性。供應商們基于WS-I提供的配置文件進行互操作性測試。盡管這看起來似乎是明顯應該做的事,但是CORBA或J2EE并非如此。而專用中間件和EAI產品的情況則更為糟糕。第二個好消息是,用于構建服務基礎架構的工具已經越來越成熟,而且更加易于使用。例如,BEA的AquaLogic Service Bus產品是完全配置驅動的——幾乎所有任務都能夠通過一個圖形界面來完成。最后,許多企業都已經部署了SOA,并且已經在應用程序開發速度和成本方面獲益。更加成熟的IT組織已經獲得了圍繞其實現的這些指標和最佳實踐,并向它們的企業證明了敏捷IT可以成為多么具有競爭力的區分點。
文章來源于領測軟件測試網 http://www.kjueaiud.com/