SOA 的基本概念及設計原則淺議

　SOA是英文詞語"Service Oriented Architecture"的縮寫，中文有多種翻譯，如"面向服務的體系結構"、"以服務爲中心的體系結構"和"面向服務的架構"，其中"面向服務的架構"比較常見。SOA有不少定義，但基本上能夠分爲兩類：一類認爲SOA主要是一種架構風格;另外一類認爲SOA是包含運行環境、編程模型、架構風格和相關方法論等在內的一整套新的分佈式軟件系統構造方法和環境，涵蓋服務的整個生命週期：建模-開發-整合-部署-運行-管理。後者歸納的範圍更大，着眼於將來的發展，咱們更傾向於後者，認爲SOA是分佈式軟件系統構造方法和環境的新發展階段。

　　一、SOA 的基本概念

　　在SOA架構風格中，服務是最核心的抽象手段，業務被劃分(組件化)爲一系列粗粒度的業務服務和業務流程。業務服務相對獨立、自包含、可重用，由一個或者多個分佈的系統所實現，而業務流程由服務組裝而來。一個"服務"定義了一個與業務功能或業務數據相關的接口，以及約束這個接口的契約，如服務質量要求、業務規則、安全性要求、法律法規的遵循、關鍵業績指標(Key Performance Indicator，KPI)等。接口和契約採用中立、基於標準的方式進行定義，它獨立於實現服務的硬件平臺、操做系統和編程語言。這使得構建在不一樣系統中的服務能夠以一種統一的和通用的方式進行交互、相互理解。除了這種不依賴於特定技術的中立特性，經過服務註冊庫(Service Registry)加上企業服務總線(Enterprise Service Bus)來支持動態查詢、定位、路由和中介(Mediation)的能力，使得服務之間的交互是動態的，位置是透明的。技術和位置的透明性，使得服務的請求者和提供者之間高度解耦。這種鬆耦合系統的好處有兩點：一點是它適應變化的靈活性;另外一點是當某個服務的內部結構和實現逐漸發生改變時，不影響其餘服務。而緊耦合則是指應用程序的不一樣組件之間的接口與其功能和結構是緊密相連的，於是當發生變化時，某一部分的調整會隨着各類緊耦合的關係引發其餘部分甚至整個應用程序的更改，這樣的系統架構就很脆弱了。

　　SOA架構帶來的另外一個重要觀點是業務驅動IT，即IT和業務更加緊密地對齊。以粗粒度的業務服務爲基礎來對業務建模，會產生更加簡潔的業務和系統視圖;以服務爲基礎來實現的IT系統更靈活、更易於重用、更好(也更快)地應對變化;以服務爲基礎，經過顯式地定義、描述、實現和管理業務層次的粗粒度服務(包括業務流程)，提供了業務模型和相關IT實現之間更好的"可追溯性"，減少了它們之間的差距，使得業務的變化更容易傳遞到IT。

　　所以，能夠將SOA的主要優勢歸納爲：IT可以更好更快地提供業務價值(Business Centric)、快速應變能力(Flexibility)、重用(Reusability)。

　　從演變的歷程來看，SOA在不少年前就被提出來了，如今SOA的再現和流行是若干因素的結合。一方面是多年的軟件工程發展和實踐所積累的經驗、方法和各類設計/架構模式，包括OO/CBD/MDD/MDA、EAI和中間件;另外一方面是互聯網的多年發展帶來史無前例的分佈式系統的交互能力和標準化基礎。與此同時，企業愈來愈重視業務模型自己的組件化，以支持高度靈活的業務戰略。可是現有的企業軟件架構不夠靈活，難以適應日益複雜的企業整合，難以知足隨需應變商務的須要，所以與業務對齊、以業務的敏捷應變能力爲首要目標、鬆散耦合、支持重用的SOA架構方法獲得青睞。更多的細節請參見"以服務爲中心的企業整合"。

　　基於咱們同客戶打交道的經驗，有必要在這裏澄清你們常常混淆的幾個基本問題。

　　第一，SOA是架構風格，是方法;而不是具體架構具體實現技術(如Web Service)、具體架構元素(如企業服務總線，Enterprise Service Bus，ESB)。

　　常常有人認爲只要用了Web Service，就是SOA了。這是不對的，Web Service只是實現服務的一種具體技術表現形式。一樣，認爲搞SOA，就是買點軟件，建個ESB，這也是不對的，ESB只是SOA架構風格中的一部分。首先，ESB是一種從實踐中總結出來的架構風格元素，即BUS(總線模式);其次，ESB的主要功能是負責連通性和服務中介(Service Mediation)，解耦服務的請求者和服務的提供者。

　　第二，SOA的首要目標是IT與業務對齊，支持業務的快速變化;其次是IT架構的靈活性和IT資產的重用。

　　業務對敏捷性的須要，是SOA最大的驅動力。一方面是業務在這方面的要求愈來愈高;另外一方面是今天的IT很不靈活，很難適應業務快速變化的需求，不只僅是由於IT架構不靈活，更重要的是業務模型中的元素和IT系統的元素之間存在很大的差距。這種不對齊，致使業務人員和IT人員之間的溝通不夠有效，業務的變化須要花費很大的代價傳遞到IT系統。很難想像，業務人員對一個Java對象，一個EJB或者一個JSP頁面感興趣，這離業務世界太遠了。這種業務和IT的對齊，須要在IT系統中實現更高階的抽象元素，就是業務模型中的元素(服務、流程、業績管理)，而且知足業務須要的水平整合(將人、信息、應用和流程端到端地動態整合起來)。這樣一個以服務爲中心的、端到端整合的環境，首先使得業務變化能夠在業務元素這個層面上溝通，更容易、更準確地從業務傳遞到IT。其次，這種變化被隔離在須要變化的局部，而不擴散到系統的其餘部分。這就須要整個IT架構自己是鬆散耦合的，一個服務的變化(功能、數據、過程、技術環境等)不影響其餘服務。最後，咱們但願這些反映業務元素的服務，是相對穩定、能夠重用的，這對快速適應變化、減小成本是很是重要的。

　　第三，在工程上，SOA的重點是服務建模和基於SOA的設計原則進行架構決策和設計。

　　常常碰到客戶提出這樣的問題：SOA挺好，爲何好?怎麼作纔是SOA的方法?跟過去的方法，好比OO/CBD有什麼不一樣?有時候一個J2EE服務器就行了，爲何那麼複雜?

　　從建模和設計的角度來講，SOA更多地側重在業務層次上，也就是經過服務建模將業務組件化爲服務模型，它是業務架構的底層，是技術架構的頂層，承上啓下，是靈活的業務模型和IT之間的橋樑，保證兩者之間的"可追溯性"。從這裏往下，是基於已有的方法，好比OO/CBD來進行的。從架構的層次上，SOA更多地側重於如何將企業範圍內多個分佈的系統(包括已有系統/遺留系統)鏈接起來(ESB，Adapter/Connector)，如何將它們的功能、數據轉化爲服務，如何經過服務中介機制(ESB，Service Registry)保證服務之間以鬆散耦合的方式交互，如何組裝(集成)服務爲流程，如何管理服務和流程等。從這往下，對於實現服務的一個具體應用，它的架構、設計和實現是能夠基於已有的實踐和方法的，好比J2EE或.NET。

　　有些時候，因爲業務需求比較簡單，全部這些東西都在一個J2EE的應用服務器上，有些要素不是那麼突出，不過隨着系統規模的擴大，要解決的業務問題更復雜、範圍更大的時候，SOA的各類架構要素就會變得愈來愈重要。

　　在下面的小節裏就歸納地討論一下SOA的若干個重要方面，包括：面向服務的計算環境，編程模型，架構風格，工程方法，以及相關的技術。

　　二、計算環境的演變和麪向服務的計算環境

　　2.1 計算環境

　　計算環境由一組計算機、軟件平臺和相互聯通的網絡組成，這個環境可以處理和交換數字信息，容許外界訪問其內信息資源(1) 。不一樣的計算環境有不一樣的計算風格和編程模型，由一些特定於該計算環境的技術來支撐。如何在一個計算環境中分割和部署計算能力、數據資源，如何讓各個部分相互通訊和協做，如何在概念上對問題域進行建模，而後映射到該計算環境，都會受到計算環境的影響和制約。所以，瞭解一下計算環境的歷史，會幫助咱們理解面向服務的計算環境是如何演變而來的。

　　2.2 計算環境的演變歷程

　　計算環境的演變經歷了若干個階段，在早期的主機時代，絕大多數的計算功能和系統的組成部分，都包括在一臺機器裏。在20世紀80年代，隨着PC的繁榮，計算環境發生很大的變化。經過局域網相互鏈接的計算設備構成客戶/服務器計算環境，計算資源和數據資源被適當地分割，客戶和服務器經過網絡協議、遠程調用或消息等方式來相互協做，完成計算。

　　爲了知足更高的可伸縮性需求，多層架構出現，計算資源和數據資源的分佈多樣化，與企業中原來已經存在的計算環境，尤爲是主機及其遺留系統之間的集成也變得愈來愈重要。中間件迅速發展，開始出現分佈式對象、組件和接口等概念，用於在計算環境中更好地分割運算邏輯和數據資源。計算環境中不一樣部分之間的交互，也從原有相對低層的網絡協議、遠程調用和消息機制的基礎上，發展到支持分佈式對象、組件和接口之間的交互，這種交互在名字服務(Naming Service)等的支持下，一般是位置透明的。但因爲缺少廣泛的標準化支持，很難作到技術透明，系統是緊耦合的。

　　隨着互聯網(Internet)的發展，開放和標準的網絡協議被廣泛支持，全部底層計算平臺都開始支持這些標準和協議，這致使一個計算環境內部和各個計算環境之間交互的藩籬被打破。數據和功能的表示與交互在XML、WEB服務(Web Service)技術與標準的基礎上，保證了通用性和最大的交互能力，這使得計算環境發展到一個全新的階段--基於標準、開放的互聯網技術的計算環境。在這樣的計算環境中，各個部分能夠採用異構的底層技術，它們使用XML來描述和表示本身的數據和功能，採用開放的網絡協議(如HTTP)來握手，在此之上，基於Web服務來互操做和交換數據。在這裏，一個很重要的新概念是"服務"(2)，它是一個自包含的功能，使用者經過明肯定義的接口(契約)來與一個服務交互，這個接口的描述基於WSDL(Web Service Description Language)這樣的開放標準。對象和組件重在表示一個事物自己的組成部分和相互關聯(也就是WHAT"THINGS"ARE的問題)，而服務則表示一個事物作什麼(也就是WHAT"THINGS"DO的問題)。Web服務是實現服務的技術手段，就如同各類編程語言中的對象是實現對象的技術手段，J2EE中的EJB是實現組件的技術手段同樣。這種基於標準、開放的互聯網技術，以服務爲中心的計算環境，咱們稱之爲"面向服務的計算環境"。

　　2.3 面向服務的計算環境

　　在面向服務的計算環境中，系統能夠是高度分佈、異構的。它通常包括服務運行時環境(Service Runtime)、服務總線(Service Integration Infrastructure)、服務網關(Service Gateway)、服務註冊庫(Service Registry)和服務組裝引擎(Service Choreography Engine)等，如圖1-1所示。

　　服務運行時環境提供服務(和服務組件)的部署、運行和管理能力，支持服務編程模型，保證系統的安全和性能等質量要素;服務總線提供服務中介的能力，使得服務使用者可以以技術透明和位置透明的方式來訪問服務;服務註冊庫支持存儲和訪問服務的描述信息，是實現服務中介、管理服務的重要基礎;而服務組裝引擎，則將服務組裝爲服務流程，完成一個業務過程;服務網關用於在不一樣服務計算環境的邊界進行服務翻譯，好比安全。

　　面向服務的計算環境是開放的、標準的，由如圖1-2所示的技術標準協議棧所定義和支持。例如，Transport層的HTTP協議，Service Description層的WSDL，Business Process層的WS-CDL等，與Policy相關的WS-Policy。本書後面的章節將討論全部統稱爲WS-*的標準和協議。

　　圖1-1 SOA計算環境的組成要素

　　

　　圖1-2 SOA計算環境的標準協議棧

　　

　　面向服務的計算環境，爲IBM所定義的隨需應變計算環境奠基了現實基礎。隨需應變計算環境應具有如下特色，如圖1-3所示。

　　圖1-3 隨需應變的計算環境應該具有的特色

　　

　　(1)整合：將人、過程、應用和數據全面整合起來。

　　(2)虛擬化：將分佈、異構的物理資源(服務器、存儲設備等)整合起來，呈現爲統一的邏輯對象，以安全和可管理的方式供使用。

　　(3)自主計算：如同生物體同樣，系統具有一些高級生物系統的能力，包括自我診斷和修復問題，自動配置和調整以適應環境的變化，自動優化資源的使用效率、加強工做負荷的處理的能力，自我保護數據和信息的安全。

　　(4)開放標準：整個環境創建在開放的標準之上，保證系統的交互性。

　　2.4 面向服務計算環境的現狀

　　不一樣的服務計算環境，採用不一樣的技術和產品，這裏主要結合IBM的產品和技術來介紹在J2EE平臺上實現的服務計算環境。

　　主機經過增長對互聯網技術和標準的支持，來建立主機上的面向服務計算環境。好比IBM的CICS 3.1，提供了SOAP和Web服務的支持，能夠將主機上的應用以Web服務的方式提供出來，供消費者使用。

　　多年來，IT界的主要技術提供者，一直攜手努力定義和推進Web服務的相關標準，而且在主要的幾個計算平臺上實現了高度兼容，包括.NET，J2EE和開源平臺(如LAMPLinux，Apache，mySQL，PHP/Perl/Python)。

　　IBM以J2EE爲基礎，提供了全面的、強大的服務計算環境，如圖1-4所示。

　　圖1-4 IBM提供的服務計算環境

　　

　　在這個計算環境中，它是服務的世界。其中，Access Services提供訪問已有應用或遺留系統的能力，將已有系統中的功能和信息轉化爲服務，IBM提供了訪問不一樣系統的適配器和相應的框架來幫助轉化。Business App Services指那些經過新的計算平臺J2EE(如IBM的WebSphere Application Server)來實現的新應用，它們所實現的功能和信息也都轉化爲服務提供出來。Partner Service指那些來自合做夥伴的服務，WebSphere Partner Gateway提供企業邊界處不一樣安全等差別的轉換。Information Service是那些跟信息(而不是活動)有關係的服務，好比將多個系統中異構的數據，聚合、轉換爲業務須要的統一整齊的業務數據對象來訪問。Process Service是指把多個服務聚合成爲一個服務流程對應業務過程的服務，這種複合服務通常是長時間運行的過程。Interaction Service是把人的活動，經過人機交互以服務的方式出如今整個業務過程當中，做爲Process Service中的一部分。

　　在面向服務計算環境中，企業服務總線處於很是重要的位置，它提供服務的中介，解耦服務請求者和服務提供者，是服務計算環境中的核心。 ESB是過去消息中間件的發展，採用了"總線"這樣一種模式來管理和簡化應用之間的集成拓撲結構，以廣爲接受的開放標準爲基礎來支持應用之間在消息、事件和服務級別上的動態互聯互通。

　　ESB的基本特徵和能力包括：描述服務的元數據和服務註冊管理;在服務請求者和提供者之間傳遞數據及對這些數據進行轉換的能力，並支持由實踐中總結出來的一些模式如同步模式，異步模式等;發現、路由、匹配和選擇的能力，以支持服務之間的動態交互，解耦服務請求者和服務提供者。高級一些的能力，包括對安全的支持、服務質量保證、可管理性和負載平衡等。

　　ESB所提供的基於標準的鏈接服務，將應用中實現的功能或者數據資源，轉化爲服務請求者能以標準的方式來訪問的服務;當請求者來請求一個服務時，ESB中這種中介轉化過程可能簡單到什麼也沒有，也可能要很複雜的中介服務支持，包括動態地查找、選擇一個服務，消息的傳遞、路由和轉換、協議的轉換。這種中介過程，是ESB藉助於服務註冊管理及問題域相關的知識(如業務方面的一些規則等)自動進行的，不須要服務請求者和提供者介入，從而實現瞭解耦服務請求者和提供者的技術基礎。這使得服務請求者不須要關心服務提供者的位置和具體實現技術，雙方在保持接口不變的狀況下，各自能夠獨立地演變。

　　因此，ESB採用總線結構模式簡化了應用之間的集成拓撲，經過源自實踐的模式，提供了基於標準的通用鏈接服務，使得服務請求者和服務提供者之間能夠以鬆散耦合、動態的方式交互，從而在不一樣層次上使得SOA解決方案是一個鬆散耦合、靈活的架構。

　　須要注意的是，ESB是一種架構模式，不能簡單地等同於特定的技術或產品，但實現ESB確實須要各類產品在運行時和工具方面的支持。IBM有很好的產品支持，運行時支持包括WebSphere ESB和WebSphere Message Broker;工具支持有WebSphere Integration Developer，支持用戶以圖形界面的方式來完成相關的開發任務，如發佈服務、使用各類模式、轉換消息和定義路由等。

　　2.5 面向服務的編程模型：服務組件架構(SCA)和服務數據對象(SDO)

　　爲了促進面向服務應用的開發，IT公司聯合起來，在2005年11月發佈了服務組件架構(Service Component Architecture)和服務數據對象(Service Data Object)規範，這些公司包括IBM，BEA，Oracle，SAP等。

　　SCA的目標是大大地簡化服務開發，直接採用Web服務和XML開發服務，使得程序員工做在底層技術上，須要應付各類異構環境下的具體實現細節。其中，SCA定義和規範了技術中立和實現透明的服務組件、服務及服務調用和組裝;而SDO定義和規範了服務世界裏的數據，這些數據對象擁有清晰定義的信息模型，獨立於數據源和具體數據訪問技術，使得服務訪問數據和在服務之間交換數據更方便、有效。

　　不少公司已經在J2EE平臺上支持了SCA/SDO，還提供了C++的版本。IBM WebSphere Process Server 6實現了SCA/SDO規範，提供了最新的SOA編程模型的支持，已經在不少實踐中被普遍使用。

 

三、軟件體系結構的演變和麪向服務（SOA）的設計原則

 

　　軟件開發一直是一件很難的事情，由於咱們要處理的問題愈來愈複雜，人們處理這種複雜性最主要的手段就是抽象。回顧歷史，咱們的抽象層次愈來愈高，反映在各個方面，從編程語言、平臺、開發過程、工具到模式。尤爲是模式，大量出如今那些結構上設計得很好的軟件系統中，不管是微觀層次上(對象、組件)穩定出現的結構範式，仍是在宏觀層面上出現的架構模式。使用哪些抽象手段來爲問題域建模?如何定義組成部分之間的協做和結構關係?如何定義從外界所看到的系統結構和行爲?是什麼設計原則在指導咱們的架構決策?有什麼最佳實踐和模式可供借鑑?全部這些，造成了不一樣設計風格和體系結構範式(Architecture Paradigm)。

　　一般，一種體系結構範式，包括設計原則，來自實踐的結構式樣、組成要素和關係，以及在整個開發生命週期中它們是如何被識別、描述和控制的。體系結構從過去單個應用包羅一切的客戶/服務器的模式，逐漸演變到三層和多層結構的各類分佈式計算模式。今天，人們開始談論和實踐面向服務、更加分佈化的架構範式。

　　從抽象手段而言，SOA在原有方法的基礎上，增長了服務、流程等元素。這些抽象手段之間的關係如圖1-5所示。

　　如何利用這些抽象手段，將一個業務需求轉化爲流程、服務，進一步建模爲服務組件，而後結合具體實現環境，在重用已有系統的功能和數據資源的基礎上來實現?如圖1-6所示是IBM總結的SOA架構概念模式。

　　SOA架構中，繼承了來自對象和組件設計的各類原則，如封裝、自我包含等。那些保證服務的靈活性、鬆散耦合和重用能力的設計原則，對SOA架構來講一樣是很是重要的。

　　結構上，服務總線是SOA的架構模式之一。

　　關於服務，一些常見和討論的設計原則以下：

　　(1)無狀態。以免服務請求者依賴於服務提供者的狀態。

　　(2)單一實例。避免功能冗餘。

　　圖1-5 SOA中的重要抽象手段

　　

　　圖1-6 SOA的概念架構模式

　　

　　(3)明肯定義的接口。服務的接口由WSDL定義，用於指明服務的公共接口與其內部專用實現之間的界線。WS-Policy用於描述服務規約，XML模式(Schema)用於定義所交換的消息格式(即服務的公共數據)。使用者依賴服務規約來調用服務，因此服務定義必須長時間穩定，一旦公佈，不隨意更改;服務的定義應儘量明確，減小使用者的不適當使用;不要讓使用者看到服務內部的私有數據。

　　(4)自包含和模塊化。服務封裝了那些在業務上穩定、重複出現的活動和組件，實現服務的功能實體是徹底獨立自主的，獨立進行部署、版本控制、自我管理和恢復。

　　(5)粗粒度。服務數量不該該太大，依靠消息交互而不是遠程過程調用(RPC)，一般消息量比較大，可是服務之間的交互頻度較低。

　　(6)服務之間的鬆耦合性。服務使用者看到的是服務的接口，其位置、實現技術、當前狀態等對使用者是不可見的，服務私有數據對服務使用者是不可見的。

　　(7)重用能力。服務應該是能夠重用的。

　　(8)互操做性、兼容和策略聲明。爲了確保服務規約的全面和明確，策略成爲一個愈來愈重要的方面。這能夠是技術相關的內容，好比一個服務對安全性方面的要求;也能夠是跟業務有關的語義方面的內容，好比須要知足的費用或者服務級別方面的要求，這些策略對於服務在交互時是很是重要的。WS- Policy用於定義可配置的互操做語義，來描述特定服務的指望、控制其行爲。在設計時，應該利用策略聲明確保服務指望和語義兼容性方面的完整和明確。

　　四、軟件工程的演變和麪向服務體系結構

　　軟件工程方法和過程伴隨着軟件實踐不斷髮展。軟件危機發生以後，從瀑布模型、原型方法等講究過程、文檔密集、控制較多的方法，逐漸發展到輕量級、敏捷和迭代的方法。這些方法更加人性化，避免由於太重的過程而扼殺人的主動性和創造性。這些方法更強調快速地交付對客戶有價值的軟件、直接的溝通、持續集成和持續質量保證。

　　SOA和當前軟件工程過程的一個共同交叉點就是業務價值驅動(Business Centric)，強調速度。SOA從軟件的靈活性和重用能力入手，而敏捷過程則從軟件交付效率出發。

　　SOA的架構特性，使得敏捷過程很是適合SOA項目的實施。在SOA架構中，服務的獨立性，使得每一個服務能夠被單獨地開發、測試和集成。一個企業中的IT系統，若是是基於SOA的計算環境，那麼這個環境就是一個服務的生態系統，每開發一個服務，立刻就能夠獨立部署，成爲這個生態系統中的一部分。這樣既很好地支持了持續集成、持續質量保證，又很好地使得這個服務立刻產生業務價值，而不是苦等其餘服務的到位。服務的特性，使得敏捷過程和SOA架構能夠有一個很好的結合，讓兩者相得益彰。以咱們與不一樣客戶合做的實踐，咱們已經充分體會到這兩者在實現過程當中的風險控制、業務需求改變的適應能力方面相互配合的好處。好比咱們在中遠集運，從瀑布過程轉向了迭代的開發過程，採用了敏捷方法的原則。

　　在韓國的項目裏，咱們的團隊來自IBM中國，IBM韓國及韓國客戶本身的工程師，分處漢城和北京兩個地方，這些工程師怎樣協做才能很快地交付高質量的系統而不相互牽扯?對於北京的工程師，北京的團隊沒法複製客戶在漢城的已有系統，如何測試本身開發的服務?經過服務建模，系統被分解爲若干相互獨立的服務，咱們將那些要重用已有系統來實現的服務交給漢城的隊員，其餘的交給北京的隊員，而且要求每一個服務開發人員提供一個簡單的"僞"實現(Mock Service)。一開始，這些簡單實現被部署在北京和漢城的測試環境中，而後各個服務開發小組開始各自獨立地開發本身所負責的服務，而流程開發人員也在同一時間開始開發他的流程，不過所基於的服務是在那些簡單實現之上，可是這些簡單實現足以支持有意義的單元和集成測試。隨後，一旦某個服務被實現，它就被部署到實際的環境中，經過調整ESB的服務中介配置，對此服務的請求被路由到真實實現。一旦真實實現有問題，還能夠換回簡單實現，以免影響其餘服務、流程的單元和集成測試。這種靈活性帶來的隨時開發、隨時部署、隨時集成和測試對於採用敏捷過程是很是有利的。

　　五、SOA技術概覽

　　本節將討論目前SOA體系架構中用到的主要技術和標準。

　　5.1 SOA的主要組件

　　在前面關於計算環境的討論裏，咱們已經提到SOA計算環境的主要組件包括：服務運行時環境、服務總線、服務註冊庫、服務網關和流程引擎。一般，還會包括服務管理、業務活動監控(Business Activity Monitoring)和業務績效管理(Business Performance Management，BPM)。另外，在服務建模、開發和編排服務等方面，咱們須要相應的工具來支持。在分析、設計方面，咱們須要基於服務的分析、設計方法，就是咱們一般說的服務建模，包括服務的識別、定義和實現策略，其輸出是一個服務模型(Service Model)。

　　5.2 SOA主要技術和標準

　　Web服務做爲實現SOA中服務的最主要手段。咱們首先來了解跟Web Service相關的標準，它們大多以"WS-"做爲名字的前綴，因此統稱WS-*。 Web服務最基本的協議包括UDDI，WSDL和SOAP，經過它們，咱們能夠提供直接而又簡單的Web Service支持，如圖1-7所示。

　　可是基本協議沒法保證企業計算須要的安全性和可靠性，因此咱們須要增長這方面的協議，好比WS-Security，WS-Reliability和WS-ReliableMessaging;對於複雜的業務場景，咱們須要WS-BPEL和WS-CDL這樣的語言來將多個服務編排成爲業務流程;管理服務的協議如WS-Manageability，WSDM等。跟Web服務相關的標準，還在快速發展當中。目前在SOA產品和實踐中，除了基本協議外，比較重要的還包括BPEL，WS-Security，WS-Policy和SCA/SDO。如表1-1所示給出了一個基本的總結，後面的章節會介紹重要的技術和標準。

　　圖1-7 基本Web服務協議

　　

　　表1-1 當前Web服務協議棧

　　

　　5.3 SOA技術在工業界的支持現狀

　　目前，Web的標準和技術在演變當中，不一樣的技術環境的支持力度也不一樣，可是前面提到的基本核心協議，都有很好的支持。關於Web服務協議的接受和支持程度，如圖1-8所示。

　　圖1-8 當前Web服務的接受狀況

　　

　　小結

　　本文介紹了SOA基本概念，並澄清了容易混淆的一些問題，而後概要地討論了SOA的若干重要方面，包括面向服務的計算環境、編程模型、架構風格、工程方法等。還很是簡要地介紹了SOA在工業界的支持概覽，更多的細節請參看各個部分所附的參考連接，它們會給讀者提供很是充分的信息和文檔，供讀者瞭解SOA相關技術和標準的發展細節。經過表1-2，讀者也能夠了解到工業界，包括廠家和標準化組織的參與狀況。