設計更好的 SOA

　　面向服務的架構（ Service-Oriented Architecture ， SOA) 在概念上是簡單的，但是它的價值還不是很明顯，在分布式企業中實現共享服務基礎架構仍然十分困難。構建正確的架構和采用實現共享服務前景所需的最佳實踐可以使過渡變得容易，并有助于確保短期和長期內的成功。

　　讓我們從更廣的范圍著手。企業需要建立公司級的最佳實踐，以用于構建成功的 SOA ?！?Organizational and Operational Best Practices ”中描述了我們在企業內使用的企業級最佳實踐。此外，我們還有六個技術和架構方面的最佳實踐（請參閱“ A Better Way to Build ”）?，F在，讓我們看看構建 SOA 時，企業和技術團隊都應該考慮的一些主要的特性、設計注意事項和實現選擇。

　　◆耦合

　　耦合是指兩個軟件（應用程序、組件、模塊、方法和服務）之間的關系（相關性和依賴性）。耦合可以分類為緊密、松散和去耦三種。兩種服務之間的耦合程度主要取決于兩個因素：服務提供者的實現和調用，以及消費者對于如何查找和調用服務的了解。對于服務來說，位置和接口定義（包括數據類型定義）組成了耦合。處理不同版本的服務的耦合級別也是必要的。

　　在計算機或軟件系統中，完全解除兩個相關系統之間的耦合實際上是不可能的。只要一個系統在任何程度上依賴于其他系統的數據、功能、服務或連通性，那么解除耦合之后，這些系統就無法工作。

　　在松散耦合中，服務提供者使用一種標準定義語言定義和公布它的服務接口。接口定義服務消費者和服務提供者之間的調用契約。只要服務接口保持一致，就可以修改服務提供者的實現。

　　消費者對于服務提供者位置的了解也引入了耦合。如果兩個服務需要交互，就不能解除它們之間的耦合，而且它們具有 100 ％的位置依賴性。相反，如果消費者能夠到達調用服務的確切位置，那么它在位置上是緊密耦合的。因為位置去耦是不可能的（在兩個已知的實體之間是不可能的，但是在事件驅動的架構中是可能的），而位置的緊密耦合缺乏靈活性，所以需要一種介于二者之間的中間松散耦合。

　　位置的松散耦合可以通過使用諸如服務代理或目錄服務這樣的服務中介來實現。 Web services 的松散耦合是通過使用用于服務定義的 Web services 描述語言（ Web Services Description Language ， WSDL ）；統一描述、發現和集成（ Universal Description, Discovery, and Integration ， UDDI ）；以及 WebLogic Integration 服務代理 / 服務控制來實現的。

　　使用網絡負載均衡器（硬件和軟件）和 / 或 WebLogic 集群，您可以實現基于非策略的、基于簡單位置的松散耦合，同時無需使用中介。只要 WSDL 中指定的服務端點是一種分布式名稱服務（ DNS ），而不是一個 IP 地址，就可以使用標準的 HTTP 機制來重定向和代理 Web service 請求。請求可以由位于任意數量的物理服務器（包括不同的數據中心）上的任意數量的端點提供服務。

　　◆綁定

　　選擇的服務綁定方法——靜態的、代理的還是動態的——決定了服務調用的靈活性和性能。

　　靜態綁定假定服務定義和接口不會頻繁變化。服務消費者和服務提供者之間的靜態綁定緊密耦合了服務調用的兩位參與者。

　　在代理綁定中，服務消費者發送其請求給服務代理，而代理將基于它對該服務的策略，請求路由到一個或多個服務提供者。在這種模式中，服務消費者無需了解服務提供者。

　　動態綁定假定服務定義和接口是頻繁變化著的。動態綁定要求：對于每次調用，服務消費者都要聯系一個服務目錄或代理來請求服務定義。消費者基于服務代理返回的信息綁定到服務提供者。由于動態綁定要在執行查找之后進行綁定，所以性能不如靜態綁定方法好。

　　至于選擇動態的還是靜態的綁定，這要取決于應用程序對于性能和靈活性的要求。 Web service 定義的動態變化可以通過使用 UDDI 或 Web services 管理（ Web services management ， WSM ）中介服務來實現。

　　◆粒度

　　消費者為了完成一項業務操作而對服務提供者進行的服務調用次數決定了服務的粒度。當需要進行許多服務調用時，服務提供者需要實現細粒度的服務。如果需要進行的服務調用只有一個或者很少，那么服務提供者就只需要實現粗粒度的服務。

　　服務調用的數量與每次調用期間傳遞的信息量有關。細粒度的服務很少使用本地的類型或對象參數，但是粗粒度的服務使用文檔作為參數，參數中包含完成一個業務事務所需的所有數據。

　　粗粒度的服務可以通過組合或組裝細粒度的服務來創建；可以通過使用像 Tuxedo 、 Enterprise JavaBeans （ EJB ）、 servlet 和 Java Database Connectivity （ JDBC ）這樣的方法進行創建；或者通過使用適配器、 API 或 Web services 調用后端系統上的服務進行創建。將細粒度的服務組合成粗粒度的服務提供的優點和對應用程序使用 SOA 的優點相同。然而，這并不意味著把 EJB 中的每個方法都公開為 Web service ； 這是不必要的，而且可能是不正確的。例如，可以把 EJB 重用為 WebLogic Integration 中的控件，或者使用 EJB 組合粗粒度的服務。把所有細粒度的服務變為 Web services ，并通過一個服務接口訪問這些服務可能會帶來性能開銷。

　　選擇粗粒度的、面向文檔的服務來滿足高層次的業務過程需要?？梢允褂?Web services 、 J2EE 組件或控件來實現細粒度的服務。粗粒度的服務應該盡可能地使用細粒度的服務進行組合，以便利用整體的服務優勢。我們還建議把服務管理層應用于粗粒度和細粒度的服務。

　　◆調用

　　SOA 支持兩種服務調用模型：同步的和異步的（發布 / 訂閱）。選擇同步的還是異步的服務調用取決于服務提供者的可用性和性能大小以及消費者的需求。

　　當需要即時響應，而且消費者在預定的時間段內等待響應時，應該使用同步服務調用。想使這種模型獲得成功，就應該把服務提供者實現為針對最大的請求負載實時做出響應。服務應該始終可用。因為同步模型被實現為處理預定的負載，它無法處理意外的、優先級更高的請求。需要把服務器設計為同時處理所有請求。如果服務提供者做出響應的速度開始變慢，它就不能接受其他消費者。這類特性可以通過服務管理策略或者使用服務器虛擬化技術來實現。

　　在異步模型中，消費者發送請求給服務器，并繼續進行其他的處理。服務器完成服務之后馬上返回響應，所需時間取決于服務器的負載情況。應該把服務器實現為對預期的最大請求數量進行排隊，而且它不需要同時處理所有的服務請求。

　　如果預期會出現大量的服務請求，而服務器只能同時處理數量有限的服務，那么推薦使用異步服務調用。異步服務可以很容易地向上或向下擴展，只需調整請求的隊列長度即可。

　　如果要求實時響應，那么顯然要選擇同步模型。然而，應該把系統實現為處理預定數量的服務請求。添加更多的服務器是向上擴展這種實現的惟一途徑。

　　在大多數復合服務中，都涉及到大量的應用程序。在同步服務調用中，在許多應用程序之間確保請求 / 響應幾乎是不可能的。在這種情況下，異步發布 / 訂閱或者點對點的消息收發模型可以確保多個應用程序之間的消息和響應的交付。

　　異步服務調用模型最適合于高度可靠的、粗粒度的、面向文檔的服務。同步服務調用更加適合于細粒度的、輕量級服務調用。異步消息收發的一個缺陷是：響應順序可能與請求順序不匹配。

　　WebLogic 平臺可以同時支持同步和異步服務調用模型。同步 Web service 調用使用基于 HTTP 的簡單對象訪問協議（ Simple Object Aclearcase/" target="_blank" >ccess Protocol ， SOAP ），而異步模型則使用基于 Java 消息服務（ Java Message Service ， JMS ）的 SOAP 。 WebLogic Integration 支持同步的、異步的和 Web service 確認（ WS-acknowledgement ）服務調用模型。

　　◆共享 / 公用服務

　　SOA 促進了重用、開發和操作邏輯與任務的劃分，以及基于策略的計算。 SOA 的這些特性只能通過針對重用設計服務和客觀化操作策略來實現。

　　對于多個應用程序有用的服務在被識別、實現和發布之后就能夠被重用?？梢酝ㄟ^發現通用的服務來識別可重用的服務，而且必須利用重用的特殊注意事項來實現可重用的服務。但是，避免重用和復制率的提高則取決于可用服務的共享信息，以及在企業內部是否鼓勵重用。

　　為了使服務更加易于重用，不要嵌入特定于應用程序的策略，比如安全性（身份驗證和授權），服務水平協議，服務質量（ QoS ）和審計信息。因為策略是跨應用程序通用的，應該在應用程序之外配置和應用策略。

　　WSM 產品提供通用的或共享的基礎架構來管理服務、策略配置和管理。為了充分體現 SOA 的優勢，要使用適當的 WSM 基礎架構。下面是共享服務的一些例子：

　　※　共享的實用程序，比如安全和業務流程編排（跨公司）。
　　※　資源管理，比如目錄和代理。
　　※　服務管理，比如自動配置、監控、 QoS 和版本管理。
　　※　傳輸管理，比如可靠的消息收發、測量、路由和審計。
　　※　集成 / 互操作性

　　針對互操作性、數據（通用數據模型、元數據管理）、語義和安全性建立企業 SOA 標準，以確保各種基于 SOA 的解決方案之間的集成和互操作性，這是很重要的?？梢允褂酶鞣N技術（ J2EE 或 .NET ）或者使用各家廠商推出的產品的組合來實現基于 SOA 的解決方案。因為 SOA 解決方案為了保持一致性和可重用性，通常是由專攻各自領域的分布群組進行構建，而由其他群組進行消費的，在上述群組中建立標準以確保它們之間的互操作性是必要的。您應該把遺留系統封裝為服務，并采用面向服務的應用程序開發（ Service-Oriented Development for Applications ， SODA ）。

　　基于 SOA 的解決方案開發使企業能夠快速共享它們現有的遺留系統，具體方法是把這些遺留系統封裝為服務，然后共享服務。 SOA 不要求使用服務接口來構建替代系統?！?leave and layer ”方法——通常，現有的系統首先被封裝為服務，以便進行重用，然后被新的系統和服務替代——允許企業選擇和建立有關如何使用一個服務層封裝不同類型的系統的標準和指導方針。

　　SOA 不排除企業應用程序集成（ EAI ）； SOA 要求對后端系統進行集成。利用 SOA 原理進行集成（面向服務的集成 [Service-Oriented Integration,SOI] ）允許企業實現靈活的、可重用的、標準的和共享的集成。我們剛剛討論過的特性具有不同的實現選擇。每個基于 SOA 的解決方案都要求經過仔細的分析后選擇最佳方法。希望這里給出的信息能夠幫助您開始構建成功的 SOA 。

原文出處：

http://www.fawcette.com/weblogicpro/2005_01/magazine/features/rramanathan/

原文轉自：http://www.kjueaiud.com