SOA&Web2.0:新商業語言

SOA&Web2.0:新商業語言

面向服務的體系結構(Service-OrientedArchitecture,SOA)是一個組件模型,它將應用程式的不同功能單元(稱為服務)通過這些服務之間定義良好的接口和契約聯繫起來。SOA技術已存在超過20年的時間,但一直未得到廣泛的套用。隨著Web服務的出現逐漸被人們接納,SOA終於迎來了自己的“春天”。對SOA的需要來源於需要使業務IT系統變得更加靈活,以適應業務中的改變。通過允許強定義的關係和依然靈活的特定實現,IT系統既可以利用現有系統的功能,又可以準備在以後做一些改變來滿足它們之間互動的需要。

基本介紹

  • 中文名:SOA&Web2.0:新商業語言
  • 外文名:Service-OrientedArchitecture
  • 模型:面向服務的體系結構
  • 優點:良好的接口和契約聯繫
SOA簡介,SOA定義,1.獨立的功能實體,2.大數據量低頻率訪問,3.基於文本的訊息傳遞,SOA與Web ServiceWeb,SOA對於軟體架構設計的影響,SOA-為什麼選擇SOA,策略,控制,管理,SOA 不是Web服務,SOA-SOA的優勢,SOA發展出來的效益,實施SOA可能帶來的主要優勢,版權資訊,內容簡介,目錄,

SOA簡介

面向服務的體系結構(Service-OrientedArchitecture,SOA)是一個組件模型,它將應用程式的不同功能單元(稱為服務)通過這些服務之間定義良好的接口和契約聯繫起來。SOA技術已存在超過20年的時間,但一直未得到廣泛的套用。隨著Web服務的出現逐漸被人們接納,SOA終於迎來了自己的“春天”。對SOA的需要來源於需要使業務IT系統變得更加靈活,以適應業務中的改變。通過允許強定義的關係和依然靈活的特定實現,IT系統既可以利用現有系統的功能,又可以準備在以後做一些改變來滿足它們之間互動的需要。就開發體系結構方面而言,SOA是將來的一個發展趨勢。SOA將數據和信息作為服務公開的模型使其成為了一個非常強大的概念,與當前的應用程式構建塊範例截然不同。

SOA定義

SOA是指為了解決在Internet環境下業務集成的需要,通過連線能完成特定任務的獨立功能實體實現的一種軟體系統架構。從這個定義中前提有下面兩點:1)軟體系統架構: SOA不是一種語言,也不是一種具體的技術而是一種軟體系統架構,它嘗試給出在特定環境下推薦採用的一種架構,從這個角度上來說,它更像一種模式(Pattern)。因此它與很多已有的軟體技術比如面向對象技術,是互補的而非互斥的。它們分別面向不同的套用場景,用來滿足不同的特定需求。2)SOA的使用範圍:需求決定同時也限制功能。SOA並不是包治百病的萬靈單,它最主要的套用場合在於解決在Internet環境下的不同商業套用之間的業務集成問題。在下面我們會詳細討論Internet的各種特點是如何決定了SOA的特點,這裡我們只需要先簡單回顧一下Internet環境區別於Intranet環境的幾個特點:a)大量異構系統並存,計算機硬體工作方式不同,作業系統不同、程式語言也不同;b)大量、頻繁的數據傳輸仍然速度緩慢並且不穩定;c)版本升級無法完成,我們根本就無法知道網際網路上有哪些機器直接或者間接的使用某個服務。基於上面的前提,下面就讓我們一起看一下SOA的3個基本特徵:

1.獨立的功能實體

在Internet這樣鬆散的使用環境中,任何訪問請求都有可能出錯,因此任何企圖通過Internet進行控制的結構都會面臨嚴重的穩定性問題。SOA非常強調架構中提供服務的功能實體的完全獨立自主的能力。傳統的組件技術,如.NET Remoting, EJB,COM或者CORBA,都需要有一個宿主(Host或者Server)來存放和管理這些功能實體;當這些宿主運行結束時這些組件的壽命也隨之結束。這樣當宿主本身或者其它功能部分出現問題的時候,在該宿主上運行的其它套用服務就會受到影響。SOA架構中非常強調實體自我管理和恢復能力。常見的用來進行自我恢復的技術,比如事務處理(Transaction),訊息佇列(Message Queue),冗餘部署(Redundant Deployment)和集群系統(Cluster)在SOA中都起到至關重要的作用。

2.大數據量低頻率訪問

對於.NET Remoting,EJB或者XML-RPC這些傳統的分散式計算模型而言,他們的服務提供都是通過函式調用的方式進行的,一個功能的完成往往需要通過客戶端和伺服器來回很多次函式調用才能完成。在Intranet的環境下,這些調用給系統的回響速度和穩定性帶來的影響都可以忽略不計,但是在Internet環境下這些因素往往是決定整個系統是否能正常工作的一個關鍵決定因素。因此SOA系統推薦採用大數據量的方式一次性進行信息交換。

3.基於文本的訊息傳遞

由於Internet中大量異構系統的存在決定了SOA系統必須採用基於文本而非二進制的訊息傳遞方式。在COM、CORBA這些傳統的組件模型中,從伺服器端傳往客戶端的是一個二進制編碼的對象,在客戶端通過調用這個對象的方法來完成某些功能;但是在Internet環境下,不同語言,不同平台對數據、甚至是一些基本數據類型定義不同,給不同的服務之間傳遞對象帶來的很大困難。由於基於文本的訊息本身是不包含任何處理邏輯和數據類型的,因此服務間只傳遞文本,對數據的處理依賴於接收端的方式可以幫忙繞過兼容性這個的大泥坑。此外,對於一個服務來說,Internet與區域網路最大的一個區別就是在Internet上的版本管理極其困難,傳統軟體採用的升級方式在這種鬆散的分散式環境中幾乎無法進行。採用基於文本的訊息傳遞方式,數據處理端可以只選擇性的處理自己理解的那部分數據,而忽略其它的數據,從而得到的非常理想的兼容性。每一項新技術都是在一些舊的技術基礎上發展出來的。正如XML根本思想來自於在60年代就已經出現的早期標記性語言一樣,SOA雖然這兩年才出現,但是它所表達的觀念應該說在網路這種分散式系統結構出現不久就已經廣泛套用了。例如我們最熟悉的HTTP協定就是一個非常典型的SOA架構設計。HTTP協定的工作過程簡單敘述如下:1)客戶端,通常是通過瀏覽器,向伺服器端以文本的方式傳送一個請求,索取一個Web頁面;2)伺服器端接收到這個請求之後,根據請求的內容進行處理並且返回一個符合HTML語法的文本;3)客戶端接收到伺服器端的回響文本後調用本地的程式,通常還是瀏覽器,把返回的HTML文本的內容展現出來。下面來看一下HTTP協定如何滿足了SOA的特點:獨立的功能實體:作為伺服器端的Web伺服器是絕對不會因為客戶端的狀況變化而改變的,它總是非常穩定的按照自己的內在邏輯運行,回響外部的請求,管理自己的資源和數據。這裡一個非常好的例子就是Web伺服器對快取(Cache)的處理,很多Web伺服器為了提高性能都或多或少的對數據進行快取,但是快取數據、刷新數據這些於客戶端完全無關的操作完全由伺服器端獨立完成,完全不受客戶端的影響。 大數據量低頻率訪問:對於一個HTTP請求來說,客戶端與伺服器之間訪問的邊界非常簡單:就是一個請求,一個回響,沒有任何其它的信息往返。無論客戶端申請的網頁上除了文字之外還有什麼信息,對於客戶端來說,它發出的請求只是簡單的告訴Web伺服器它所需要的網頁的位置;至於為了生成這個網頁,伺服器端是否需要訪問資料庫,執行Servlet或者其它的CGI程式對客戶端而言,都是完全透明的。 基於文本的訊息傳遞:迄今為止兼容性最好的系統可能就是HTTP協定支撐的大部分的web套用了,我們可以在Windows平台下用IE查看網際網路上一個Linux+Apache伺服器上的由Perl腳本自動生成的網頁。這裡的關鍵就是所有內容都是以格式化的文本方式傳遞的,不管Perl腳本如何執行,只要它的輸出是符合HTML規範的網頁,就可以被客戶端的瀏覽器解釋。而由於不同的作業系統上對於相同的HTML的解釋遵循相同的規範,因此不同作業系統下仍然能夠看到一致的用戶界面。我們上面基本描述了SOA作為一種軟體架構有哪些特點,下面讓我們一起看看Web Service與SOA的關係。

SOA與Web ServiceWeb

Service是就現在而言最適合實現SOA的一些技術的集合,事實上最近SOA的火爆在很大程度上歸功於Web Service標準的成熟和套用的普及為廣泛的實現SOA架構提供了基礎。下面讓我們看看Web Service中的各種協定是如何互相工作來滿足SOA所需的特點的:獨立的功能實體:通過UDDI的目錄查找,我們可以動態改變一個服務的提供方而無需影響客戶端的應用程式配置。所有的訪問都通過SOAP訪問進行,只要WSDL接口封裝良好,外界客戶端是根本沒有辦法直接訪問伺服器端的數據的。大數據量低頻率訪問:通過使用WSDL和基於文本(Literal)的SOAP請求,我們可以實現能一次性接收大量數據的接口。這裡需要著重指出的是SOAP請求分文本方式和遠程調用(RPC)兩種方式,正如上文已經提到的,採用遠程調用方式的SOAP請求並不符合這點要求。但是令人遺憾的是現有的大多數SOAP請求採用的仍然是遠程調用(RPC)方式,在某些平台上,例如IBM WebSphere的早期版本,甚至沒有提供文本方式的SOAP支持。 基於文本的訊息傳遞:Web Service所有的通訊是通過SOAP進行的,而SOAP是基於XML的,不同版本之間可以使用不同的DTD或者XML Schema加以辨別和區分。因此只需要我們為不同的版本提供不同的處理就可以輕鬆實現版本控制的目標。

SOA對於軟體架構設計的影響

無論您現在的系統是否牽涉到基於Internet的業務集成,採用SOA推薦的架構都對提高您系統的擴展性有很大幫助,下面是在系統中引入SOA後需要在軟體架構方面做出的改變:使用基於文本方式的SOAP調用,擺脫遠程調用中出現的函式參數類型等與數據無關的信息,保證所有SOAP傳遞的都是有意義的商業數據。依賴於Schema,而不是類定義對這些數據進行解釋。 傳統的三層Web套用將可能變成四層結構:傳統意義上的商業邏輯層將被進一步劃分為存放每個會話(Session)信息的客戶邏輯層和與狀態無關Sateless的SOA層。

SOA-為什麼選擇SOA

不同種類的作業系統,套用軟體,系統軟體和套用基礎結構(application infrastructure)相互交織,這便是IT企業的現狀。一些現存的應用程式被用來處理當前的業務流程(business processes),因此從頭建立一個新的基礎環境是不可能的。企業應該能對業務的變化做出快速的反應,利用對現有的應用程式和套用基礎結構(application infrastructure)的投資來解決新的業務需求,為客戶,商業夥伴以及供應商提供新的互動渠道,並呈現一個可以支持有機業務(organic business)的構架。SOA憑藉其松耦合的特性,使得企業可以按照模組化的方式來添加新服務或更新現有服務,以解決新的業務需要,提供選擇從而可以通過不同的渠道提供服務,並可以把企業現有的或已有的套用作為服務, 從而保護了現有的IT基礎建設投資。 如圖1的例子所示,一個使用SOA的企業,可以使用一組現有的套用來創建一個供應鏈複合套用(supply chain composite application),這些現有的套用通過標準接口來提供功能。 服務架構 服務架構 為了實現SOA,企業需要一個服務架構,圖2顯示了一個例子: 圖2 在圖2中, 服務消費者(service consumer)可以通過傳送訊息來調用服務。這些訊息由一個服務匯流排(service bus)轉換後傳送給適當的服務實現。這種服務架構可以提供一個業務規則引擎(business rules engine),該引擎容許業務規則被合併在一個服務里或多個服務里。這種架構也提供了一個服務管理基礎(service management infrastructure),用來管理服務,類似審核,列表(billing),日誌等功能。此外,該架構給企業提供了靈活的業務流程,更好地處理控制請求(regulatory requirement),例如Sarbanes Oxley(SOX),並且可以在不影響其他服務的情況下更改某項服務。 SOA基礎結構 要運行,管理SOA應用程式,企業需要SOA基礎,這是SOA平台的一個部分。SOA基礎必須支持所有的相關標準,和需要的運行時容器。圖3所示的是一個典型的SOA基礎結構。 SOAP, WSDL, UDDI WSDL,UDDI和SOAP是SOA基礎的基礎部件。WSDL用來描述服務;UDDI用來註冊和查找服務;而SOAP,作為傳輸層,用來在消費者和服務提供者之間傳送訊息。SOAP是Web服務的默認機制,其他的技術為可以服務實現其他類型的綁定。一個消費者可以在UDDI註冊表(registry)查找服務,取得服務的WSDL描述,然後通過SOAP來調用服務。 WS-I Basic Profile WS-I Basic Profile,由Web服務互用性組織(Web Services Interoperability Organization)提供,是SOA服務測試與互用性所需要的核心構件。服務提供者可以使用Basic Profile測試程式來測試服務在不同平台和技術上的互用性。 J2EE 和 .Net 儘管J2EE和。NET平台是開發SOA應用程式常用的平台,但SOA不僅限於此。像J2EE這類平台,不僅為開發者自然而然地參與到SOA中來提供了一個平台,還通過他們內在的特性,將可擴展性,可靠性,可用性以及性能引入了SOA世界。新的規範,例如 JAXB(Java API for XML Binding),用於將XML文檔定位到Java類;JAXR(Java API for XML Registry)用來規範對UDDI註冊表(registry)的操作;XML-RPC(Java API for XML-based Remote Procedure Call)在J2EE1.4中用來調用遠程服務,這使得開發和部署可移植於標準J2EE容器的Web服務變得容易,與此同時,實現了跨平台(如。NET)的服務互用。 服務品質 在企業中,關鍵任務系統(mission-critical system,譯註:關鍵任務系統是指如果一個系統的可靠性對於一個組織是至關重要的,那么該系統就是該企業的關鍵任務系統。比如,電話系統對於一個電話促銷企業來說就是關鍵任務系統,而文字處理系統就不那么關鍵了。)用來解決高級需求,例如安全性,可靠性,事物。當一個企業開始採用服務架構作為工具來進行開發和部署套用的時候,基本的Web服務規範,像WSDL,SOAP,以及UDDI就不能滿足這些高級需求。正如前面所提到的,這些需求也稱作服務品質(QoS,quality of services)。與QoS相關的眾多規範已經由一些標準化組織(standards bodies)提出,像W3C(World Wide Web Consortium)和OASIS(the Organization for the Advancement of Structured Information Standards)。下面的部分將會討論一些QoS服務和相關標準。 安全 Web服務安全規範用來保證訊息的安全性。該規範主要包括認證交換, 訊息完整性和訊息保密。該規範吸引人的地方在於它藉助現有的安全標準,例如,SAML(as Security Assertion Markup Language)來實現web服務訊息的安全。OASIS正致力於Web服務安全規範的制定。 可靠 在典型的SOA 環境中,服務消費者和服務提供者之間會有幾種不同的文檔在進行交換。具有諸如“僅且僅僅傳送一次”( once-and-only-once delivery),“最多傳送一次”( at-most-once delivery),“重複訊息過濾”(duplicate message elimination),“保證訊息傳送”(guaranteed message delivery)等特性訊息的傳送和確認,在關鍵任務系統(mission-critical systems)中變得十分重要。WS-Reliability 和 WS-ReliableMessaging是兩個用來解決此類問題的標準。這些標準現在都由OASIS負責。

策略

服務提供者有時候會要求服務消費者與某種策略通信。比如,服務提供商可能會要求消費者提供Kerberos安全標示,才能取得某項服務。這些要求被定義為策略斷言(policy assertions)。一項策略可能會包含多個斷言。WS-Policy用來標準化服務消費者和服務提供者之間的策略通信。

控制

當企業著手於服務架構時,服務可以用來整合數據倉庫(silos of data),應用程式,以及組件。整合套用意味著例如異步通信,並行處理,數據轉換,以及校正等進程請求必須被標準化。在SOA中,進程是使用一組離散的服務創建的。BPEL4WS 或者 WSBPEL(Web Service Business Process Execution Language)是用來控制這些服務的語言。WSBPEL目前也由OASIS負責。 管理

管理

著企業服務的增長,所使用的服務和業務進程的數量也隨之增加,一個用來讓系統管理員管理所有運行在多相環境下的服務的管理系統就顯得尤為重要。WSDM(Web Services for Distributed Management)規定了任何根據WSDM實現的服務都可以由一個WSDM適應(WSDM-compliant)的管理方案來管理。 其它的qos特性,比如合作方之間的溝通和通訊,多個服務之間的事務處理,都在WS-Coordination 和 WS-Transaction 標準中描述, 這些都是OASIS 的工作。 SO

SOA 不是Web服務

在理解SOA和Web服務的關係上,經常發生混淆。根據2003年4月的Gartner報導,Yefim V. Natis就這個問題是這樣解釋的:“Web服務是技術規範,而SOA是設計原則。特別是Web服務中的WSDL,是一個SOA配套的接口定義標準:這是Web服務和SOA的根本聯繫。”從本質上來說,SOA是一種架構模式,而Web服務是利用一組標準實現的服務。Web服務是實現SOA的方式之一。用Web服務來實現SOA的好處是你可以實現一個中立平台,來獲得服務,而且隨著越來越多的軟體商支持越來越多的Web服務規範,你會取得更好的通用性。

SOA-SOA的優勢

SOA的概念並非什麼新東西,SOA不同於現有的分散式技術之處在於大多數軟體商接受它並有可以實現SOA的平台或應用程式。SOA伴隨著無處不在的標準,為企業的現有資產或投資帶來了更好的重用性。SOA能夠在最新的和現有的套用之上創建套用;SOA能夠使客戶或服務消費者免予服務實現的改變所帶來的影響;SOA能夠升級單個服務或服務消費者而無需重寫整個套用,也無需保留已經不再適用於新需求的現有系統。總而言之,SOA以藉助現有的套用來組合產生新服務的敏捷方式,提供給企業更好的靈活性來構建應用程式和業務流程。

SOA發展出來的效益

A. 平衡最初的舊系統投資(Leverage initial investment): 組織過去所投資的系統、軟硬體,如果能再利用等於賦予其新的價值,這也替組織降低成本並增加競爭力。 B. 基礎建設的便利性(Infrastructure Commoditization): 讓所有的套用程式能相互溝通(互通性)。 C. 快速的接近市場(Faster time-to-market): 服務的重複使用(再利用),來縮短過去的組織流程,更快速的提供服務來接近市場。 D. 減少支出(Reduce Cost): 服務的重複使用,可降低開發成本。因為開發新系統的成本,大部份比更新舊有系統來的花費大。 E. 減低風險(Risk mitigation): 開發新系統的風險遠大於更新舊系統。 F. 持續改善商業流程的循環(Continuous improvement cycle for business process) G. 中心流程處理(Process-centric processing)

實施SOA可能帶來的主要優勢

有5點:  一,SOA可通過網際網路伺服器發布,從而突破企業區域網路的限制,實現與供應鏈上下游夥伴業務的緊密結合。通過SOA架構,企業可以與其業務夥伴直接建立新渠道,建立新夥伴的成本得以降低。  二,SOA與平台無關,減少了業務套用實現的限制。要將企業的業務夥伴整合到企業的“大”業務系統中,對其業務夥伴具體採用什麼技術沒有限制。  三, SOA具有低耦合性特點,增加和減少業務夥伴對整個業務系統的影響較低。在企業與各業務夥伴關係不斷發生變化的情況下,節省的費用會越來越多。  四, SOA具有可按模組分階段進行實施的優勢。可以成功一步再做下一步,將實施對企業的衝擊減少到最小。  五, SOA的實施可能並不具有成本顯著性。這要分三種情況加以討論:   當企業從零開始構建業務系統時,採用SOA架構與不採用SOA架構成本可看做是相同的。   當企業業務發展或發生企業重組等變化而原有系統不能滿足需要,而需要重構業務系統時,採用SOA架構與不採用SOA架構成本可看做是相同的。   當企業業務發生緩慢變化並可預見到將來需要重構業務系統時,由於可以按模組分階段逐步實施SOA以適應變化的需要,這樣企業不需一下投入一大筆經費進行系統改造,而是根據企業業務發展情況和資金情況逐步投入,緩解了信息投入的壓力。  另指 半導體光放大器 (Semiconductor Optical Amplifer) 一般有行波放大和諧振放大兩種,行波SOA的材料和一般半導體雷射器相同,光纖通訊領域多為InP材料,放大波段1550nm附近,毅力簡單的理解為一個沒有反饋腔的雷射器,一般端面反射率小於千分之五。

版權資訊

書 名: SOA&Web2.0:新商業語言
SOA&Web2.0:新商業語言
作 者:(美)卡特
出版時間: 2007
ISBN: 9787302155850
開本: 16
定價: 29.80 元

內容簡介

★IBM資深副總裁,頂級SOA戰略大師SandyCarter力作!
〔名家書評〕
一本正在尋求企業IT成功之道的中國CIO乃至CEO們值得一讀的書!
--用友軟體股份有限公司董事長、總裁:王文京
〔本書最大的閃光點〕
SandyCarter引述了IBM近年來幫助企業開發SOA的案例,這對剛剛起步的企業有很大的借鑑意義。此外,這本書與其說是在傳播實現SOA的具體技術,不如說是為企業介紹一些關鍵的基本理念,為其提供實現SOA所需的正確思想,全書並不涉及如何進行SOA或Web服務套用的實際開發,所以您會發現本書很少有原始碼或API講解。
現在,在機構的靈活性和業務表現之間存在一種直接的、可查證的聯繫。為了將靈活性最最佳化,企業必須對其內部、外部的關鍵流程與基礎架構實現前所未有的整合與自動化。同時,企業必須學會以更具動態性和反應性的方式來管理流程。
總而言之,企業必須實現靈活應對。
直到最近,技術都一直阻礙著這些目標的實現。正是由於面向服務架構(SOA)、Web2.0和開放標準的出現,才促成企業實現了這些目標。在本書中,IBM的頂級SOA策略家展示了業務經理該如何利用技術創新來推動動態流程的發展,以應對當今世界越來越快的變化。
在本書中,SandyCalter示範了將企業解構為“組件化”業務模式的方法,然後用相互連線的、可重複的並且能快速、輕鬆、經濟地適應各種變化的IT服務來支持該模式。這些技術將幫助IT專家和業務經理達到嶄新的運營水平,以開展著眼於市場的創新,這才是最重要的。

目錄

第Ⅰ部分從起點開始--業務
第1章創新迫在眉睫3
1.1專注於增長4
1.1.1增長的議程4
1.1.2靈活性:一項核心的技能5
……

相關詞條

熱門詞條

聯絡我們