通過優銳課的java架構知識講解中，了解面向服務的體系結構的特征以及什么構成基於Java的SOA基礎結構。分享給大家學習參考。
面向服務的體系結構（SOA）是基於用於同步和異步應用程序的請求/答復設計范例的分布式計算的演變。應用程序的業務邏輯或各個功能被模塊化，並作為針對消費者/客戶端應用程序的服務呈現。這些服務的關鍵是它們的松散耦合性質。即服務接口獨立於實現。應用程序開發人員或系統集成商可以通過組合一項或多項服務來構建應用程序，而無需了解服務的基礎實現。例如，可以在.Net或J2EE中實現服務，而使用該服務的應用程序可以在其他平台或語言上。
SOA的好處是其與平台無關的方法以及Web服務之間更好的互操作性。本文是SOA的概述，包括構建Web服務時使用的一些工具和協議。
SOA和Web服務
面向服務的體系結構是可以使用Web服務實現的體系結構模式。 有關在Java中構建基於SOAP的RESTful Web服務的教程簡介，請參見“ Java SE中的Web服務”（JavaWorld，2017年）。
面向服務的體系結構具有以下關鍵特征：
- ·SOA服務在與平台無關的XML文檔中具有自描述接口； 用於描述服務的標准是WSDL或Web服務描述語言。
- ·SOA服務與通過XML Schema或XSD正式定義的消息進行通信。 消費者與提供者或服務之間的通信通常發生在異構環境中，很少或根本不了解提供者。 服務之間的消息可以視為企業中處理的關鍵業務文檔。
- ·SOA服務由充當目錄列表的注冊表在企業中維護。 應用程序可以在注冊表中查找服務並調用服務。 通用描述，定義和集成（UDDI）是用於服務注冊表的標准。
為什么選擇SOA？
IT企業基礎結構在操作系統，應用程序，系統軟件和應用程序基礎結構之間是異構的。 一些現有的應用程序用於運行當前的業務流程，因此不能從頭開始構建新的基礎架構。 企業應迅速敏捷地響應業務變化； 利用對應用程序和應用程序基礎結構的現有投資來滿足新的業務需求； 支持與客戶，合作伙伴和供應商互動的新渠道； 並具有支持有機業務的架構。 SOA具有松散耦合的性質，允許企業以粒度方式插入新服務或升級現有服務，以滿足新的業務需求，提供使服務跨不同渠道可使用的選項，並將現有企業和遺留應用程序公開為服務 ，從而保護現有的IT基礎架構投資。
雲計算的SOA
了解有關Java企業中面向服務的體系結構的更多信息：
- 邏輯SOA：體系結構概述
- 面向現實世界的SOA
- ·確保SOA：你需要了解的內容
- ·精益SOA的企業模式
如圖1的示例所示，使用SOA的企業可以使用一組通過標准接口公開功能的現有應用程序來創建供應鏈復合應用程序
圖1.供應鏈應用程序。 單擊縮略圖以查看完整尺寸的圖像。
服務架構
為了實現SOA，企業需要一種服務架構，其示例如圖2所示。
圖2.一個示例服務架構。 單擊縮略圖以查看完整尺寸的圖像。
在圖2中，幾個服務使用者可以通過發送消息來調用服務。 這些消息通常由服務總線轉換並路由到適當的服務實現。 該服務體系結構可以提供業務規則引擎，該業務規則引擎允許將業務規則合並到服務中或跨服務。 服務體系結構還提供了服務管理基礎結構，用於管理服務和活動，例如審核，計費和日志記錄。 此外，該架構還為企業提供了具有敏捷業務流程的靈活性，可以更好地滿足Sarbanes Oxley（SOX）等法規要求，並且可以在不影響其他服務的情況下更改單個服務。
SOA基礎架構
為了運行和管理SOA應用程序，企業需要SOA平台中一部分的SOA基礎結構。 SOA基礎結構必須支持所有相關標准和所需的運行時容器。 典型的SOA基礎架構如圖3所示。以下各節討論了基礎架構的各個部分。
圖3.典型的SOA基礎架構。 單擊縮略圖以查看完整尺寸的圖像。
SOAP, WSDL, UDDI
在撰寫本文時，WSDL，UDDI和SOAP是SOA基礎結構的基礎。 WSDL用於描述服務； UDDI，用於注冊和查找服務； 和SOAP，作為在服務使用者和服務提供者之間發送消息的傳輸層。 SOAP是Web服務的默認機制，而替代技術則可以完成其他類型的服務綁定。 使用者可以在UDDI注冊表中搜索服務，獲取具有描述的服務的WSDL，然后使用SOAP調用該服務。
WS-I基本配置文件
Web服務互操作性組織提供的WS-I基本概要正在變成服務測試和互操作性所需的另一個核心部分。 服務提供商可以使用Basic Profile測試套件來測試服務在不同平台和技術之間的互操作性
Java EE 和 .Net
盡管Java EE和.Net平台是SOA應用程序的主要開發平台，但是SOA絕不限於這些平台。 諸如Java EE之類的平台不僅為開發人員提供了自然參與SOA的框架，而且憑借其固有的特性，還為SOA世界帶來了可擴展性，可靠性，可用性和性能的成熟成熟的基礎架構。 規范，例如用於將XML文檔映射到Java類的Java綁定的Java API（JAXB），用於以標准方式與UDDI注冊中心進行交互的XML Registry的Java API（JAXR）和基於XML的遠程的Java API 過程調用（XML-RPC），用於調用Java EE 1.4中的遠程服務，有助於開發和部署可跨標准J2EE容器移植的Web服務，同時與其他平台（如.Net）的服務進行互操作。
服務質量
企業中現有的關鍵任務系統可以滿足高級要求，例如安全性，可靠性和事務處理。 隨着企業開始采用服務體系結構作為開發和部署應用程序的工具，諸如WSDL，SOAP和UDDI之類的基本Web服務規范將無法滿足這些高級要求。 如前所述，這些要求也稱為服務質量。 與QoS有關的許多規范正在諸如Internet聯盟（W3C）和結構化信息標准促進組織（OASIS）之類的標准機構中制定。 以下各節討論了一些QoS工件和相關標准。
安全
Web服務安全性規范解決了郵件安全性問題。 該規范專注於憑證交換，消息完整性和消息機密性。 此規范的吸引力在於它利用了現有的安全標准，例如``安全斷言標記語言（SAML）''，並允許使用這些標准來保護Web服務消息。 Web服務安全性是OASIS正在進行的一項工作。
可靠性
在典型的SOA環境中，服務使用者和服務提供者之間交換幾個文檔。 在使用服務體系結構的關鍵任務系統中，具有一次發送，一次發送，最多一次發送，消息重復消除，保證的消息傳遞和確認等特征的消息傳遞變得很重要。 WS-Reliability和WS-ReliableMessaging是解決可靠消息傳遞問題的兩個標准。 這兩個標准現已成為OASIS的一部分。
政策
服務提供商有時會要求服務使用者與某些策略進行通信。 例如，服務提供商可能需要Kerberos安全令牌才能訪問服務。 這些要求被定義為策略聲明。 一個策略可能包含多個斷言。 WS-Policy標准化了服務使用者和服務提供者之間如何交流策略。
編排
隨着企業開始使用服務體系結構，服務可用於集成數據，應用程序和組件的孤島。 集成應用程序意味着必須對過程要求（例如異步通信，並行處理，數據轉換和補償）進行標准化。 BPEL4WS或WSBPEL（Web服務業務流程執行語言）是解決服務編排的OASIS規范，其中業務流程是使用一組離散服務創建的。 WSBPEL現在是OASIS的一部分。
管理
隨着企業中隨着服務而暴露的服務和業務流程數量的增長，讓系統管理員管理在異構環境中運行的服務的管理基礎架構變得非常重要。 Web服務分布式管理（WSDM）將指定根據WSDM實施的任何服務都可以由符合WSDM的管理解決方案進行管理。
WS-Coordination和WS-Transaction規范分別解決了其他QoS屬性，例如合作伙伴之間的協調以及涉及多個服務的事務，這也是OASIS所做的努力。
結論：SOA的好處
盡管SOA概念不是新概念，但SOA與現有的分布式技術的不同之處在於，大多數供應商都接受它，並擁有啟用SOA的應用程序或平台套件。 SOA具有無處不在的一組標准，可以為企業中現有資產或投資帶來更好的可重用性，並允許你創建可以在新的和現有應用程序之上構建的應用程序。 SOA支持對應用程序進行更改，同時使客戶端或服務使用者與服務實現中發生的演進式變化保持隔離。 SOA支持升級單個服務或服務使用者； 不必完全重寫應用程序或保留不再滿足新業務需求的現有系統。 最后，SOA通過利用現有的應用程序基礎結構來組合新服務，為企業提供了更好的靈活性，從而可以靈活地構建應用程序和業務流程。
> 喜歡這篇文章的可以點個贊，歡迎大家留言評論，記得關注我，每天持續更新技術干貨、職場趣事、海量面試資料等等
> 如果你對java技術很感興趣也可以交流學習，共同學習進步。
> 不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代
文章寫道這里，歡迎完善交流。最后奉上近期整理出來的一套完整的java架構思維導圖，分享給大家對照知識點參考學習。有更多JVM、Mysql、Tomcat、Spring Boot、Spring Cloud、Zookeeper、Kafka、RabbitMQ、RockerMQ、Redis、ELK、Git等Java干貨
