外部和內(nèi)部 Web 服務之間多個面向服務的體系結構 (Service-Oriented Architectures，SOA) 中的外部 Web 服務的互操作性最優(yōu)。Judith Myerson 展示了如何更改服務的類型、位置以及每個 Web 服務的平臺，以便實現(xiàn)原始應用程序的業(yè)務流程。
引言
在關于企業(yè)級面向服務的體系結構 (SOA) 系列我的第一篇文章，“使用多重 SOA 來消除企業(yè)系統(tǒng)之間的差異”（參閱參考資料）中，通過說明如何重用一個或多個 SOA 中的 Web 服務（以數(shù)據(jù)為中心 (data-centric) 和業(yè)務邏輯），然后將他們聯(lián)合到一個受組織控制的組合應用程序中，討論了使用 SOA 縮小企業(yè)系統(tǒng)差異的方案。
當 Web 服務不受組織所控制時，需要確保它們在外部可以彼此互操作，來共享語義和契約職責。語義的誤解（例如所有權）和契約漏洞（例如多平臺間的區(qū)別）會影響外部企業(yè) Web 服務之間的互操作性問題。
在本文中，我展示了四個實現(xiàn)制造資源規(guī)劃 (Manufacturing Resource Planning，MRP) 和客戶關系管理 (Customer Relationship Management，CRM) 服務的實例，如下所示：
- 企業(yè)以前的應用程序
- 到外部 Web 服務的動態(tài)鏈接
- 請求外部 Web 服務的 REpresentational State Transfer/Simple Object Access Protocol (REST/SOAP) 共存
- 使用 IBM? WebSphere? Application Server 和 Microsoft? Visual Studio .Net 的 Web 服務互操作性
考慮各種交易時，確定系統(tǒng)可以負載的可互操作的 SOA 的數(shù)量非常重要，這樣可以避免 SOA 過載。
企業(yè)以前的應用程序
假設企業(yè)以前的應用程序（參見圖 1）被分成業(yè)務流程的模塊化組件。該應用程序的兩個重要組件（MRP 和 CRM）要求不斷發(fā)生變化且重新編譯長期運行的應用程序。
圖 1. 企業(yè)以前的應用程序
動態(tài)服務鏈接
為增加運行效率，從應用程序中提取出這些組件并將其重新構建為外部 Web 服務更有意義。通過這種方式，您可以更改兩個 Web 服務的代碼，而不用重新編譯龐大的、復雜的長期運行的應用程序。
在第一個 SOA（參見圖 2）中以更加緊湊的形式重新設計的應用程序可以動態(tài)鏈接到第二個 SOA 中的外部企業(yè) MRP Web 服務，依次的，指向第三個 SOA 中的外部企業(yè) CRM Web 服務。一旦收到請求，CRM Web 服務將請求和信息發(fā)送給應用程序來進行進一步處理。
圖 2. 到 Web 服務的動態(tài)鏈接
每個鏈接機制都是以發(fā)送請求或消息，接收響應，或執(zhí)行 SQL 或 HTTP 操作的形式出現(xiàn)的。還可以封裝沒有 MRP 組件的應用程序，這樣就可以向 MRP Web 服務發(fā)送請求。
軟件架構
需要牢記，在從一個協(xié)議轉換到另一個，或者從一個軟件架構轉換到另一個時，可能會引起平臺間的互操作性問題。一些實例包括 SOAP、REST、.Net 架構、企業(yè) Java Bean (Enterprise Java Beans，EJB) 以及 Java 消息服務 (Java Messaging Service，JMS)。
運行在 HTTP 上的 .Net Web 服務可以以三種不同的方式調(diào)用：HTTP GET 操作、HTTP POST 操作和 SOAP。如果需要快速的調(diào)用 Web 服務且沒有 SOAP 客戶端的話，GET 和 POST 操作都是非常有用的。可以通過 Perl 腳本在 HTTP 上使用 REST 來執(zhí)行 GET、POST、PUT 和 DELETE 操作。在這個腳本中，您可以指定 SQL 查詢和簡單的消息隊列。
如果 SOAP 客戶端可用，下面是如何在 REST 和 SOAP 之間進行簡單的選擇。如果應用程序是 基于資源的，選擇 REST。如果應用程序是 基于行為的，選擇 SOAP。在 REST 中，客戶端可以通過 HTTP 請求執(zhí)行在一系列資源上的多個操作。對于基于 SOAP 的請求，可能需要執(zhí)行請求的每個面向活動的客戶端可能僅需要一個調(diào)用操作。
調(diào)用框架
要構建 SOAP 請求，需要使用 Web 服務描述語言 (Web Services Description Language，WSDL)，這是一種描述如何訪問 Web 服務以及將執(zhí)行什么操作的語言。您可以指定服務的類型，而不用自定義 Web 服務的代碼，也不用重新編譯以前的應用程序。
為確保 WSDL 文件能在各種軟件架構中工作，您可以利用 IBM Web Services Invocation Framework (WSIF)，它讓您可以將 WSDL 作為不同軟件標準來描述。這表明您可以通過描述語言周圍的 API 以獨立于協(xié)議和位置的方式訪問 WSDL。還意味著您可以通過 WSDL 將 Web 服務結合復合成應用程序，在 WSDL 中您可以在各種條件和異常情況下切換協(xié)議和位置。
為構建 WSIF，無論您打算使用什么提供商，您都需要滿足最低需求，該選項包括如下：
- JAXP XML 解析器
- Java API 的 WSDL
- Apache SOAP
- Apache Axis。
REST 和 SOAP 共存
雖然 REST 請求不像 SOAP 請求那樣依賴 WSDL，您仍需要 XML Schema 來驗證 REST 操作。既然 WSDL 支持 schema 規(guī)范，REST 和 SOAP 可以作為從一個合成的 Web 服務應用程序到外部應用程序的請求而共存。
例如，SOA #1（參閱圖 3）中的應用程序首先發(fā)送 SOAP 請求調(diào)用 SOA #2 的 MRP Web 服務中調(diào)用基于活動的服務，接下來發(fā)送一個 REST 請求來操作相同 MRP Web 服務中的面向行為的服務。所有基于 SOAP 的請求都是基于 IBM WSIF 的。
圖 3. REST 和 SOAP 共存
正如您所見到的，第一個 SOA 里面的應用程序運行在 Unix 或者 Linux 服務器上，而第二個 SOA 中的 MRP Web 服務運行在 IBM WebSphere Application Server (Application Server) 中。您可以使用 WSIF 來更改基于 SOAP 的請求的規(guī)范版本中的服務類型和位置。
WebSphere 和 .Net 產(chǎn)品的互操作性
如果您希望開發(fā)更加復雜的 Web 服務，作為 Linux 或者 Window 平臺上的較大企業(yè)系統(tǒng)開發(fā)項目的一部分，可以考慮使用用于 WebSphere 軟件的 IBM Rational? Application Developer。它同用于 Java? 和 EJB 的統(tǒng)一建模語言 (Universal Modeling Language，UML) Visual Editor 一起提供，并且運行在 Eclipse 源碼開放平臺上，允許您擴展您的開發(fā)環(huán)境。還可以使用 Microsoft Visual Studio.Net。
您可以使用軟件來將應用程序邏輯分割成模塊化的多業(yè)務流程 Web 服務組件。IBM 通過提供 Web Services Navigator（Rational Application Developer 插件） 更前進了一步，讓您直觀地同 Web 服務事務交互。
如果您正在使用 Visual Studio.Net 在 Microsoft .Net 平臺上開發(fā) Web 服務，可以在 Application Server 中運行它們。這意味著使兩個平臺之間的 Web 服務互操作（參閱參考資料），您所要做的只是開發(fā)與兩種平臺公用的 WSDL。
例如，運行在 Unix 或者 Linux 服務器上的應用程序（參見圖 4）首先發(fā)送 SOAP 請求來調(diào)用運行在 Application Server 上的 MRP Web 服務的基于活動的服務。接下來，該應用程序發(fā)送一個 REST 請求來執(zhí)行同樣 MRP Web 服務上的一系列基于資源的服務。一旦收到請求，SOA #3 中的 CRM Web 服務向原始應用程序發(fā)送一個請求或者信息。
圖 4. 多平臺外部 Web 服務
正如您所看到的，第三個 SOA 中的 CRM Web 服務運行在 .Net 平臺上并且訪問 Application Server。CRM Web 服務向第一個 SOA 中的應用程序發(fā)送請求或者信息。您可以為 Visual Studio.NET 添加一個 Visual Perl 插件。您還可以使用用于 Unix 到 Windows 移植的命令行級別的基于 REST 的腳本，并且使其適應 Visual Perl 環(huán)境，這取決于簡本的復雜性。
Visual Studio
對于您來說，使用 Visual Studio .Net 比 Visual Basic、C++、Java、Kornshell 來封裝 Unix 應用程序為 COM 組件要更加容易。同樣，如果您正在開發(fā)應用程序，使用 Unix shell 腳本來運行 Window 應用程序，或者如果您將 Unix 應用程序移植到 Window 平臺下來鏈接到外部 Web 服務，使用它也非常容易。
這里有一些您應該了解的提示。首先，您應該將自己的 WSDL 文件發(fā)布到一個公共的位置來解決互操作性的差別。您可以跳過 Rational Application Developer's 自底向上的方法或者 Visual Studio .Net 的 WSDL First 方法中的自動生成 WSDL 文件。可以使用 Rational Application Developer 的 Skeleton 或者自頂向下的方法 來啟動您的 WSDL 文件并填充 Java Class 實現(xiàn)。或者，還可以禁用 Visual Studio 的 WDSL First 方法中的自動生成 WSDL 文件選項并且發(fā)布您自己的 WSDL。
第二，要為自己提供一個可以使用的 WSDL 模板，可以考慮 Rational Application Developer 的自底向上的方法（從 Java Bean 開始），Rational XDE（基于類模型生成模板代碼），或者 Visual Studio 的 Implementation First Approach（在通過編寫 Web 服務代碼開始后生成模板代碼）。然而 Rational Application Developer 提供了 WSDL，Visual Studio.Net 可能沒有提供。
需要多少 SOA？
用來連接 EAI 應用程序的 SOA 的數(shù)量取決于項目、互操作性問題、業(yè)務流程和負載性能問題之間復雜性的平衡。如果您避免了 SOAP 超標，您需要確保 SOAP 在開發(fā)的整個生命周期不會超載。您應該在周期的每一點上測試超載。
結束語
使多平臺 SOA 之間的外部 Web 服務互操作性最優(yōu)需要事先計劃好可以開發(fā)多少 SOA。您應該與業(yè)務分析團隊和 IT 專家在各種性能問題上進行交流。您會發(fā)現(xiàn)解決互操作性問題將使您的開發(fā)工作變得更加得容易。您可以開發(fā)外部 Web 服務，每個服務可以使用不同的平臺和請求協(xié)議。分析師將發(fā)現(xiàn)解決該問題將使設計和分析多個 SOA 系統(tǒng)的工作更加容易。他們可以確定 Web 服務可以運行在什么平臺上，而不用導致 SOA 超載。