如何認識面向服務架構SOA的真實面目

在經典的軟件工程理論中，瀑布法和原型法都是從需求分析開始，壹步壹步地構建各種軟件系統。然而，需求變化就像揮之不去的陰影，始終伴隨著系統。每壹個實際應用系統的開發者，都經歷過系統進入開發階段、測試階段甚至上線階段時，鋪天蓋地的需求變化帶來的極度痛苦。客戶將變更後的需求視為bug是主要問題。如何解決這個問題？軟件開發和架構會有壹場革命嗎？SOA架構的提出被認為是這樣壹場革命。其本質是將系統模型與系統實現分離。1.定義SOA並不是壹個新概念。有些人認為CORBA和DCOM等組件模型是SOA架構的前身。早在1996年，Gartner Group就已經提出了SOA的預測，但當時只是“預測”，當時的軟件開發和信息化水平還不足以支撐這樣壹個概念進入實質性應用階段。近壹兩年來，SOA的技術手段逐漸成熟。在BEA、IBM等軟件巨頭的大力推動下，逐漸流行起來。Gartner的SOA願景是實現實時企業。目前，SOA還沒有壹個統壹的、被廣泛接受的定義。壹般認為，SOA是壹種面向服務的架構，是壹種組件模型，它通過服務之間定義良好的接口和契約來連接應用程序的不同功能單元-服務。接口是以中立的方式定義的，獨立於特定服務的硬件平臺、操作系統和編程語言，因此在這樣的系統中構建的服務可以以統壹和標準的方式進行通信。這種具有中性接口定義(不強制綁定到特定實現)的特性被稱為服務間的松耦合。從這個定義可以看出以下兩點:軟件系統架構:SOA不是語言，也不是具體的技術，更不是產品，而是軟件系統架構。它試圖給出壹個在特定環境下推薦的架構。從這個角度來看，它實際上更像是壹個模式，壹個概念架構，壹個應用服務的解決方案框架。服務是整個SOA實現的核心。SOA架構的基本元素是服務。SOA指定了壹組實體(服務提供者、服務消費者、服務註冊中心、服務條款、服務代理和服務契約)，它們詳細解釋了如何提供和消費服務。遵循SOA觀點的系統必須具有可互操作的、獨立的、模塊化的、位置明確的、松散耦合的服務，並且可以通過網絡找到它們的地址。2.2 .三個角色的關系服務。SOA是壹個自包含的無狀態實體，可以由多個組件組成。它通過預定義的接口響應服務請求。它還可以執行離散任務，如編輯和處理事務。服務本身不依賴於其他功能和過程的狀態。使用什麽技術來實現服務在其定義中不受限制。服務提供者提供符合約定的服務，並將它們發布給服務代理。服務消費者，也稱為服務消費者，發現並調用其他軟件服務來提供業務解決方案。從概念上講，SOA本質上將網絡、傳輸協議和安全性的細節留給了特定的實現。服務請求者通常被稱為客戶端，但他們也可以是最終用戶應用程序或其他服務。作為存儲庫、電話黃頁或交換所，service broker生成由服務提供商發布的軟件接口。這三個SOA參與者:服務提供者、服務代理和服務請求者通過三個基本操作進行交互:發布、查找和綁定。服務提供者向服務代理發布服務。服務請求者通過服務代理查找所需的服務，並綁定到這些服務。服務提供者和服務請求者可以交互。所謂無狀態服務，就是服務不依賴於任何預設的條件，是無狀態的。在SOA架構中，服務不依賴於其他服務的狀態。他們接受客戶的服務請求。因為服務是無狀態的，所以它們可以被編排和序列化成多個有序的(有時是流水線式的)來執行業務邏輯。編排是指序列化服務和提供數據處理邏輯。但不包括數據的顯示功能。3.SOA特征基於以上討論，我們給出了SOA的以下特征:服務封裝。將服務封裝到業務流程的可重用組件中的應用程序功能。它提供信息或簡化業務數據從壹種有效且壹致的狀態到另壹種狀態的轉換。封裝隱藏了復雜性。服務的API保持不變，讓用戶遠離具體實現的變化。服務的重用。服務的可重用性設計大大降低了成本。為了實現可重用性，服務只在特定流程的上下文中工作，獨立於底層實現和客戶需求的變化。服務的互操作性。互操作性並不是壹個新概念。CORBA、DCOM和web服務都采用了互操作技術。在SOA中，服務通過已建立的通信協議進行互操作。主要有兩種通信機制:同步和異步。SOA提供的服務的互操作性更有利於其在很多場合的重用。服務是自治的功能實體。服務是由組件組成的復合模塊，它是自包含的，模塊化的。SOA非常強調在架構中提供服務的功能實體的完全獨立的能力。傳統的組件技術，如。NET Remoting、EJB、COM或CORBA都需要壹個主機(Host或Server)來存儲和管理這些功能實體；當這些主機耗盡時，這些組件的壽命也將結束。這樣，當主機本身或其他功能部分出現問題時，主機上運行的其他應用服務就會受到影響。SOA架構強調實體的自我管理和彈性。常見的自恢復技術，如事務、消息隊列、冗余部署和集群，都在SOA中扮演著至關重要的角色。服務之間很容易耦合。服務請求者到服務提供者的綁定應該與服務松散耦合。這意味著服務請求者不知道提供者實現的技術細節，比如編程語言、部署平臺等等。服務請求者通常通過消息調用操作，請求消息和響應，而不是使用API和文件格式。這種松散耦合允許對話壹端的軟件發生變化而不影響另壹端，前提是消息模式保持不變。在壹種極端的情況下，服務提供者可以用基於Java語言的新代碼完全替換以前基於遺留代碼(例如COBOL)的實現，而不會對服務請求者產生任何影響。只要新代碼支持相同的通信協議，這就是真的。服務是位置透明的。服務是為業務需求而設計的。需要響應需求的變化，也就是所謂的敏捷設計。才能真正實現業務和服務的分離。有必要使服務的設計和部署對用戶完全透明。換句話說，用戶根本不需要知道響應自己需求的服務的位置，甚至不需要知道響應中涉及到哪個服務。4.三個抽象層次從概念上講，SOA中有三個主要的抽象層次:操作:代表單個邏輯工作單元的事務(LUW)。執行操作通常會導致讀取、寫入或修改壹個或多個持久數據。SOA操作可以直接與面向對象(OO)方法相比較。它們都有特定的結構化接口並返回結構化響應。就像方法壹樣，特定操作的執行可能涉及到調用其他操作。服務:代表操作的邏輯分組。可以對服務進行分層，以降低耦合性和復雜性。服務的粒度也與系統的性能密切相關。粒度太小，會增加服務間互操作通信的開銷；如果粒度過大，會影響服務面對需求變化的敏捷性。業務流程:實現特定業務目標的壹組長期運行的操作或活動。業務流程通常包括多個業務調用。在SOA中，業務流程包括根據壹組業務規則有序執行的壹系列操作。操作的排序、選擇和執行被稱為服務或流程編排。通常，編排的服務被調用以響應業務事件。從建模的角度來看，挑戰在於如何描述設計良好的操作、服務和流程的抽象特征，以及如何系統地構建它們。這些涉及服務建模和特征提取的問題成為現階段關註的焦點。