什么是面向服務的體系結構(SOA)?
面向服務的體系結構(Service-Oriented Architec-ture，SOA)是一個組件模型，它將應用程序的不同功能單元(稱為服務)通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行交互。
這種具有中立的接口定義(沒有強制綁定到特定的實現上)的特征稱為服務之間的松耦合。松耦合系統的好處有兩點，一點是它的靈活性;另一點是，當組成整個應用程序的每個服務的內部結構和實現逐漸地發(fā)生改變時，它能夠繼續(xù)存在。而與此相對，緊耦合意味著應用程序的不同組件之間的接口與其功能和結構是緊密相連的，因而當需要對部分或整個應用程序進行某種形式的更改時，它們就顯得非常脆弱。
對松耦合系統的需求來源于業(yè)務應用程序需要根據業(yè)務的變動變得更加靈活，以適應不斷變化的環(huán)境，比如經常改變的政策、業(yè)務級別、業(yè)務重點、合作伙伴關系、行業(yè)地位以及其他與業(yè)務有關的因素，這些因素甚至會影響業(yè)務的性質。我們稱能夠靈活地適應環(huán)境變化的業(yè)務為按需(On Demand)業(yè)務，在按需業(yè)務中，一旦需要，就可以對完成或執(zhí)行任務的方式進行必要的更改。
雖然面向服務的體系結構不是一個新鮮事物，但它卻是更傳統的面向對象的模型的替代模型，面向對象的模型是緊耦合的，已經存在二十多年了。雖然基于 SOA的系統并不排除使用面向對象的設計來構建單個服務，但是其整體設計卻是面向服務的。由于它考慮到了系統內的對象，所以雖然SOA是基于對象的，但是作為一個整體，它卻不是面向對象的。不同之處在于接口本身。SOA系統原型的一個典型例子是通用對象請求代理體系結構(Common Object Request Broker Architecture，CORBA)，它已經出現很長時間了，其定義的概念與SOA相似。
然而，現在的SOA已經有所不同了，因為它依賴于一些更新的進展，這些進展是以可擴展標記語言(eXtensible Markup Language，XML)為基礎的。通過使用基于XML的語言(稱為Web服務描述語言，Web Services Definition Language，WSDL)來描述接口，服務已經轉到更動態(tài)且更靈活的接口系統中，非以前 CORBA中的接口描述語言(Interface Definition Language，IDL)可比了。
Web服務并不是實現SOA的惟一方式。前面剛講的CORBA是另一種方式，這樣就有了面向消息的中間件(Message-Oriented Middleware)系統，比如IBM 的MQSeries。但是為了建立體系結構模型，您所需要的并不只是服務描述。您需要定義整個應用程序如何在服務之間執(zhí)行其工作流。您尤其需要找到業(yè)務的操作和業(yè)務中所使用的軟件的操作之間的轉換點。因此，SOA 應該能夠將業(yè)務的商業(yè)流程與它們的技術流程聯系起來，并且映射這兩者之間的關系。例如，給供應商付款的操作是商業(yè)流程，而更新您的零件數據庫，以包括進新供應的貨物卻是技術流程。因而，工作流還可以在 SOA的設計中扮演重要的角色。
此外，動態(tài)業(yè)務的工作流不僅可以包括部門之間的操作，甚至還可以包括與不為您控制的外部合作伙伴進行的操作。因此，為了提高效率，您需要定義應該如何得知服務之間關系的策略，這種策略常常采用服務級協定和操作策略的形式。
最后，所有這些都必須處于一個信任和可靠的環(huán)境之中，以同預期的一樣根據約定的條款來執(zhí)行流程。因此，安全、信任和可靠的消息傳遞應該在任何SOA中都起著重要的作用。
我可以用面向服務的體系結構做什么?
對SOA的需要來源于需要使業(yè)務 IT 系統變得更加靈活，以適應業(yè)務中的改變。通過允許強定義的關系和靈活的特定實現，IT 系統既可以利用現有系統的功能，又可以準備在以后做一些改變來滿足系統之間交互的需要。
下面舉一個具體的例子。一個服裝零售組織擁有 500 家國際連鎖店，它們常常需要更改設計來趕上時尚的潮流。這可能意味著不僅需要更改樣式和顏色，甚至還可能需要更換布料、制造商和可交付的產品。如果零售商和制造商之間的系統不兼容，那么從一個供應商到另一個供應商的更換可能就是一個非常復雜的軟件流程。通過利用WSDL接口在操作方面的靈活性，每個公司都可以將它們的現有系統保持現狀，而僅僅匹配 WSDL接口并制訂新的服務級協定，這樣就不必完全重構它們的軟件系統了。這是業(yè)務的水平改變，也就是說，它們改變的是合作伙伴，而所有的業(yè)務操作基本上都保持不變。這里，業(yè)務接口可以作少許改變，而內部操作卻不需要改變，之所以這樣做，僅僅是為了能夠與外部合作伙伴一起工作。
另一種形式是內部改變，在這種改變中，零售組織現在決定它還將把連鎖零售商店內的一些地方出租給專賣流行衣服的小商店，這可以看作是采用店中店(Store-in-Store)的業(yè)務模型。這里，雖然公司的大多數業(yè)務操作都保持不變，但是它們現在需要新的內部軟件來處理這樣的出租安排。盡管在內部軟件系統可以承受全面的檢修，但是它們需要在這樣做的同時不會對與現有的供應商系統的交互產生大的影響。在這種情況下，SOA模型保持原封不動，而內部實現卻發(fā)生了變化。雖然可以將新的方面添加到SOA模型中來加入新的出租安排的職責，但是正常的零售管理系統繼續(xù)如往常一樣。
為了延續(xù)內部改變的觀念，IT 經理可能會發(fā)現，軟件的新配置還可以以另外的一種方式加以使用，比如出租粘貼海報的地方以供廣告之用。這里，新的業(yè)務提議是通過在新的設計中重用靈活的SOA模型得出的。這是來自SOA模型的新成果，并且還是一個新的機會，而這樣的新機會在以前可能是不會有的。垂直改變也是可能的，在這種改變中，零售商從銷售他們自己的服裝完全轉變到專門通過店中店模型出租地方。如果垂直改變完全從最底層開始的話，就會帶來 SOA模型結構的顯著改變，與之一起改變的還可能有新的系統、軟件、流程以及關系。
在這種情況下，SOA 模型的好處是它從業(yè)務操作和流程的角度考慮問題，而不是從應用程序和編程的角度考慮問題，這使得業(yè)務管理可以根據業(yè)務的操作清楚地確定什么需要添加、修改或刪除。然后可以將軟件系統構造為適合業(yè)務處理的方式，而不是在許多現有的軟件平臺上常常看到的其他方式。
正如您可以看到的，在這里，改變和SOA系統適應改變的能力是最重要的部分。對于開發(fā)人員來說，這樣的改變無論是在他們工作的范圍之內還是在他們工作的范圍之外都有可能發(fā)生，這取決于是否有改變需要知道接口是如何定義的，以及它們相互之間如何進行交互。與開發(fā)人員不同的是，架構師的作用就是決策對SOA 模型大的改變。這種分工，就是讓開發(fā)人員集中精力于創(chuàng)建作為服務定義功能單元，而讓架構師和建模人員集中精力于如何將這些單元適當地組織在一起。這種方式已經有十多年的歷史了，通常用統一建模語言(Universal Modeling Language，UML)，并且描述成模型驅動的體系結構(Model-Driven Architecture，MDA)。
構成SOA的技術是什么?
SOA本身應該是“如何將軟件組織在一起”的抽象概念。它依賴于用 XML 和 Web 服務實現并以軟件的形式存在的更加具體的觀念和技術。此外，它還需要安全性、策略管理、可靠消息傳遞以及會計系統的支持，從而有效地工作。您還可以通過分布式事務處理和分布式軟件狀態(tài)管理來進一步地改善它。
SOA服務和Web服務之間的區(qū)別在于設計。SOA 概念并沒有確切地定義服務具體如何交互，而僅僅定義了服務如何相互理解以及如何交互。其中的區(qū)別也就是定義如何執(zhí)行流程的戰(zhàn)略與如何執(zhí)行流程的戰(zhàn)術之間的區(qū)別。而另一方面，Web服務在需要交互的服務之間如何傳遞消息有具體的指導原則;從戰(zhàn)術上實現SOA模型最常見的方式是通過HTTP傳遞的SOAP消息。因而，從本質上講，Web 服務是實現SOA的具體方式之一。
盡管我們覺得 Web 服務是實現SOA最好的方式，但是SOA并不局限于Web服務。其他使用WSDL直接實現服務接口并且通過XML消息進行通信的協議也可以包括在SOA之中。正如在別處指出的，CORBA和 IBM的MQ系統通過使用能夠處理WSDL的新特征也可以參與到SOA中來。如果兩個服務需要交換數據，那么它們還會需要使用相同的消息傳遞協議，但是數據接口允許相同的信息交換。
既為了建立所有這些信息的適當控制，又為了應用安全性、策略、可靠性以及會計方面的要求，在SOA體系結構的框架中加入了一個新的軟件對象。這個對象就是企業(yè)服務總線(Enterprise Service Bus，ESB)，它使用許多可能的消息傳遞協議來負責適當的控制、流甚至還可能是服務之間所有消息的傳輸。雖然ESB并不是絕對必需的，但它卻是在SOA中正確管理您的業(yè)務流程至關重要的組件。ESB本身可以是單個引擎，甚至還可以是由許多同級和下級ESB組成的分布式系統，這些 ESB一起工作，以保持SOA系統的運行。在概念上，它是從早期比如消息隊列和分布式事務計算這些計算機科學概念所建立的存儲轉發(fā)機制發(fā)展而來的。
從開發(fā)人員的角度來說，他們使用的工具必須知道 SOA的能力，并允許開發(fā)人員有效地使用SOA對象。這將把設計SOA模型、開發(fā)服務和服務對象以及測試 SOA應用程序這些過程包括進來并組成一個整體。因而，開發(fā)人員的工作必須為面向服務的應用程序設計/開發(fā)(Service-Oriented Application Design/Development，SOAD)做好準備。
SOA與其他技術的關系如何?
SOA可以與許多其他技術結合在一起使用，然而，組件的封裝和聚合在其中扮演著重要的角色。如前所述，SOA可以是一個簡單對象、復雜對象、對象集合、包含許多對象的流程、包含其他流程的流程，甚至還可以是輸出單一結果的應用程序的整體集合。在服務之外，它可以看作是單個實體，但是在其自身中，它可以具有任何級別的復雜性(如果必要的話)。出于性能方面的考慮，大多數SOA服務并沒有下降到單一對象的粒度，并且更適合于大中型組件。
除了可能離不開XML和WSDL之外，SOA并不是特定于語言的。可以用任何編程語言來實現服務，只要這種編程語言可以生成服務并且可以與WSDL結合在一起使用就可以了。SOAP本身并不是絕對需要的，但它是通用的消息傳遞系統。因此，可以使用幾乎任何一種編程語言和支持WSDL的平臺來實現SOA中的成員服務。
基于通用對象請求代理體系結構(Common Object Broker Request Architecture，CORBA)的應用程序有許多組件必須連接到 SOA 中。雖然 CORBA 中的接口描述語言(Interface Description Language，IDL)在概念上類似于WSDL，但它不是嚴格的，因而首先需要將其映射到WSDL。另外，需要使用更高級的 SOA協議(比如用于流程和策略管理的協議)，而不是CORBA中的類似的概念。請記住，這是CORBA組件(表示為服務)需要與SOA服務交互的情況;在 CORBA模型中，所有的獨立子集仍然可以像以前一樣工作。
由對象管理組織(Object Management Group，OMG)提出并在許多IBM Rational產品中得以實現的模型驅動體系結構在一個更抽象的層次上與SOA的概念具有很強的相關性。MDA基于這樣的概念，任何軟件流程都可以定義為模型甚至是元模型(即模型的模型)，然后可以將這些模型和元模型轉換成應用程序的實際組件。因此，MDA創(chuàng)建了一個模型，這個模型先編譯成軟件應用程序，而軟件應用程序接著又編譯成可執(zhí)行程序，這樣就可以在平臺上運行了。MDA并不區(qū)分服務和對象這兩個概念，但是它確實允許模型由其他子集模型本身組成，這類似于BPEL(SOA的一個核心組件)中的流程聚合的概念。
SOA和Web服務是獨立于編程語言的，但Java是主要的開發(fā)語言之一。可以使用定義良好的Java接口以及各種協議豐富的Java實現為正在構建這個模型的開發(fā)人員提供了優(yōu)勢。Java在此擔當了開發(fā)每個服務的功能、管理數據對象和與其他在邏輯上封裝在服務內的對象進行交互的角色。
SOA與Web的另一個重要的關系是自主計算和網格計算的概念。自主計算的概念應用于管理分布式服務體系結構的范圍，具體來說，就是幫助維護策略和服務級協議以及SOA系統的總體穩(wěn)定性。
另外，網格計算可以以兩個級別與SOA系統一起使用。網格是分布式計算的一種形式，它利用分布式特性和服務之間的交互來為SOA應用程序提供計算支持。在這種情況下，網格起到了框架的作用，其中實現了一些或所有單獨的服務。因此，SOA應用程序可以是網格服務的消費者。
在另一方面，網格本身也可以構建在SOA之上。在這種情況下，每個操作系統服務都是構成整個SOA應用程序的成員，而SOA應用程序就是網格本身。因此，單獨的網格組件既可以使用Web服務進行通信，又可以以SOA的方式進行交互。總而言之，網格系統可以是SOA本身，也可以提供服務來在其上構建應用程序級SOA模型。
如何構建SOA系統?
利用SOA的好處不僅僅在于它是一個軟件開發(fā)流程，而且還是一個業(yè)務開發(fā)流程。采用SOA有四個層次，您的實現可以跨越從創(chuàng)建特定的軟件服務到將您的業(yè)務模型全面轉換到按需系統的過程。
第一個層次是最簡單的，因為它只需創(chuàng)建單獨的服務。
在第二個層次中，您不僅可以創(chuàng)建服務，而且可以開始將業(yè)務功能集成到SOA中。這涉及多個層次的集成，其中包括應用程序集成、信息集成、流程集成和整個系統的集成。
第三個層次涉及將您的企業(yè)IT基礎設施轉換到 SOA模型，而采用SOA的第四個層次集中于轉換您的業(yè)務模型，以使之成為隨需應變的模型。
從IT專業(yè)人員的角度來看(與業(yè)務層相比)，要創(chuàng)建SOA應用程序，您通常將經歷四個階段：構建、部署、使用和管理。在構建階段中，您可以定義業(yè)務模型或流程、軟件模型和SOA模型。之后，您就可以創(chuàng)建一組服務，這組服務可以與已發(fā)布的通用接口一起重用。
在部署階段，您提取創(chuàng)建的服務，并把它們放在一個可執(zhí)行、可管理的環(huán)境之中。在使用階段，您根據前面所講的SOA和軟件模型來裝配應用程序，并且測試其軟件質量以及非功能性需求，比如性能、可伸縮性等等。應用程序現在已經準備完畢并且可交付用戶。最后的管理階段是一個長期的過程，在這個階段中，您可以監(jiān)控并管理安全性和使用，以及在許多與您可能已經為 SOA制訂好的服務級協定或策略相對應的方面比較其性能。
這些是SOA的生命周期的概念階段。為了使對應于這些階段的實際工作角色具體化，有許多角色需要加入到SOA應用程序的創(chuàng)建之中。這些角色可能從事相同的工作，也可能跨多個團隊成員甚至多個團隊。在 Rational Unified Process(RUP)中所劃分的角色非常好地表達了角色概念。
如何提高我的SOA技能?
技能的獲取取決于您是一個什么類型的專業(yè)人員：信息分析員、軟件架構師、軟件開發(fā)人員、軟件質量分析員、系統管理員等等。如前所述，SOA的概念跨越所有這些工作角色。因此，理解每個工作角色所起的作用是非常有幫助的。
接下來，您應該熟悉每個角色中所包括的技術概念。信息分析員和軟件架構師應該熟悉模型驅動的體系結構(Model-Driven Architectures，MDA)和UML 2.0。軟件開發(fā)人員和程序員應該了解Web服務的程序化接口、MQ和其他協議、程序化地保護交互的方式以及工作流處理的概念。質量分析員和系統管理員應該理解 SOA流程模型與實際SOA功能性體系結構實現，以及分別開發(fā)單獨的服務如何影響這樣的分布式應用程序的整體性能。系統管理員還應該知道應用程序安全性和信任模型如何工作，以及應用程序使用策略如何影響操作系統平臺和網絡系統。