使用多重 SOA 來消除企業系統之間的差異

引言

在服務級協議（Service-Level Agreements，SLA）系列的第三篇文章（“在 Web 服務上下文中使用 SLA”，請見參考資料）中，我談論了 Web 服務是如何作為 EAI 限制來補充 Enterprise Application Integration（EAI）應用程式的。我進一步討論了使用 SOA 來消除企業系統之間的差異的場景，向您展示瞭如何執行獲取 EAI 應用程式所有權的 Web 服務的業務邏輯。我向您展示瞭如何複用以資料為中心的 Web 服務以及來源於一個或更多 SOA 的業務邏輯並將它們結合進複合應用程式中。

EAI 差異

我重在研究 EAI 解決方案的三個主要的侷限：所有權、有限的整合以及缺少開放行業標準。在公司的 EAI 應用程式之間存在資訊傳遞的差異，例如：

• 客戶關係管理（Customer relationship management，CRM）
• 投資關係管理（Investor relationship management，IRM）
• 供應鏈管理（Supply-chain management，SCM）
• 企業資源規劃（Enterprise resource planning，ERP）

EAI 應用程式的所有權性質受到公司應用於 EAI 應用程式中的業務流程型別和公司經營的業務型別的限制。EAI 解決方案限制了使用外部應用程式來整合 EAI 系統的範圍。對於在 EAI 系統及外部應用程式之間對映業務邏輯的計劃的定製是浪費時間並且代價昂貴的。

實現 EAI 的標準事實上是不存在的。沒有標準，在網際網路上整合多商家的 EAI 應用程式是非常困難的。與 EAI 不同，Web 服務提供了廣泛的標準，為應用程式與外部的服務提供者之間搭建了橋樑。然而，EAI 比 Web 服務更加安全，IT 行業聯合起來建立並改善了現有的標準（WS-Security）為 Web 服務提供了更加安全的機制。消除差異

各種窗體的中介軟體技術已經被用於消除 EAI 差異。Web 服務是使得 EAI 應用程式能夠互相傳遞資訊的最好的中介軟體。它們提供了開放的行業標準，為獨立平臺的 EAI 系統搭建了橋樑。一些附加的 EAI 應用程式承擔了開放行業業務流程的提供者或客戶的職責，EAI 應用程式不能在封閉環境下采用該流程。

事實上，在獨立 SOA 中不是所有 Web 服務都可用。您可以將 Web 服務與基本功能相結合形成複合的 Web 服務應用程式。相反，您可以將這些應用程式同其它的 Web 服務或其它 SOA 中的複合業務相結合來建立新的或更高階的業務服務。這意味著您可以使用多重 SOA 來消除 EAI 應用程式之間的或系統之間的差異

編制 Web 服務

在 SOA 中，使用一系列高階業務服務的業務流程來編制多重 Web 服務的執行。以資料為中心的 Web 服務很少自我執行。編制的目標是使得 Web 服務能夠消除 EAI 的差異，以便具有所有權的 EAI 應用程式可以通過整合的集線器來互相交流。

在編制過程中，您可以擴大或縮小編制的範圍和性質，通過複用程式碼來改變複合應用程式的業務流程邏輯。基於個人提出的功能，SOA 中的 Web 服務可被複用並結合到高階服務的複合應用程式中來建立新的業務服務，反之，該業務服務可被複用並結合到另一個 SOA 的業務服務的高階複合應用程式中。

避免錯誤

我想到了當開發 Web 服務或將 Web 服務結合進複合應用程式時可能發生的四個錯誤，您應當避免：

1. 簡單物件訪問協議（Simple Object Access Protocol，SOAP）的開銷
2. SOAP 互用性問題
3. 緊密結合的業務服務
4. 處理繁重事務的環境。

在每個地方都建立 Web 服務並且將它們結合到所有 Web 服務的應用程式中是不太實際的，即使 Web 服務是基於日益擴大的開放行業標準的（EAI 應用程式缺少這些標準）。當處理 Web 服務時企業可能會產生大量的 SOAP 開銷，這樣就減慢了完成業務流程的速度。

企業也可能遇到 Web 服務中的 SOAP 互用性的問題。雖然已經完成了大量的工作，使 SOAP 的互用性得到了提高，但是還沒有實現行業級的完全互用。

一些具備所有權的 EAI 應用程式可以在緊耦合的環境下很好地執行某些業務功能，在複合應用程式中的 Web 服務不能在鬆耦合的環境下很好地執行。一個緊耦合的業務服務的例項是客戶將卡插入讀卡機中，確認卡的金額，指定取出的現金並收到自動地從他的帳戶中取款的確認。

在短時間內一些 Web 服務連同其它的 Web 服務（包括長期執行的基於一套複合業務規則的應用程式）一起完成了業務流程，在整合這樣的 Web 服務的過程中您可能會發現問題。Web 服務非常適合於短時間執行的應用程式，而不適合於處理繁重事務的環境，因為在這樣的環境下需要很長時間才能完成業務流程。

獨立的 SOA 場景

現在我們來看一下您怎樣才能使 Web 服務同基本功能相結合來構建複合的 Web 服務應用程式，假設裝載的效能是令人滿意的。考慮下面的 Web 服務，每個都來自於完全互用的系統：

• 零售商的識別符號
• 零售商的名稱
• 零售商的地址
• 定購的數量
• 價格
• 稅務

如圖 1 所示，前四種 Web 服務僅包含基本功能的資料，而最後兩個主要使用業務邏輯來達到向零售商傳送帳單的目的。我將所有的都結合到複合的具備帳單功能的應用程式中，也就是在結帳應用程式中進行處理。

圖 1. 獨立 SOA 的場景

我使用零售商識別符號的 Web 服務來啟動流程，該服務向零售商名稱的 Web 服務發出請求來獲得與零售商識別符號相匹配的名稱。當確認資訊的時候，零售商名稱的 Web 服務與零售商地址的 Web 服務、定購數量的 Web 服務、價格的 Web 服務和稅務的 Web 服務相結合來建立具備零售商帳單功能的複合應用程式。隨後，在基於服務的業務邏輯的結帳應用程式中處理了該複合應用程式。

多重 SOA 的場景

我們假設小公司缺乏內部的 Tax Service 部門。對於更新、維護的業務有外來的稅務服務並且管理外來稅務的 Web 服務。對於該公司，我將第一個場景中的前五種 Web 服務結合進具有帳單功能的複合應用程式中，同時假設裝載流程的效能是令人滿意的。

我們假設 Web 服務發出了請求——將第二個 SOA 中外來的 Web 服務與第一個 SOA 中的複合應用程式相結合。如果接受並實現了該請求，那麼在基於價格和稅務服務的業務邏輯的結帳應用程式中將處理高階的複合應用程式。如圖 2 所示，第二個 SOA 與第一個 SOA 交疊，該交疊的部分可能包含 SOA 中普遍的 Web 服務和非 Web 服務。

圖 2. 多重 SOA 的場景

獨立 SOA 呼叫 EAI 應用程式

重在關聯、鏈式管理，資源規劃的 Web 服務有不同的整合規則（或虛擬的整合集線器），即使它們在整合企業之間的應用程式的過程中可以互相合作。相反，EAI 系統的元件可以通過中介軟體技術的整合集線器來互相傳遞資訊使得 EAI 應用程式能夠同遺留系統、資料庫、Web 服務及非 Web 服務進行互動。

我們將 SOA 作為實現多重 EAI 應用程式（在防火牆內部及防火牆外部）的業務功能的主要的中介軟體技術。為了避免 SOAP 開銷，限制 Web 服務的數量。同時，避免降低裝載由 Web 服務呼叫的 EAI 應用程式的速度。

在獨立 SOA 呼叫多重 EAI 應用程式的場景中，零售商識別符號的 Web 服務首先呼叫了 Retail Management System（請見圖 3）。在成功地裝載了所應呼叫的應用程式之後，Web 服務發出了將識別符號與名稱及地址相連結的請求。

圖 3. 呼叫多重 EAI 應用程式的獨立 SOA

然後 EAI 應用程式在資料庫中搜尋請求的專案。如果找到了名稱及地址，那麼它就向 SOA 發出資訊來將定購數量及價格的 Web 服務新增到複合應用程式中。同時解除安裝 Retail Management System 來為今後呼叫其它 EAI 應用程式提供空間。

接下來，複合應用程式呼叫了 Finance Management System，該系統維護 Tax Service 流程規則的資料庫。在成功地裝載了該 EAI 應用程式之後，定購的數量及價格的應用程式與其相連。高階複合帳單功能就形成了。同時解除安裝 Finance Management System。

多重 SOA 呼叫 EAI 應用程式

現在，我們假設需要兩個 SOA 連線兩個 EAI 應用程式。在該場景中，我將 Order Quantity 和 Order Description Web Services 結合到第一個 SOA 中。我重複了第三個場景中的流程，呼叫並裝載了零售商識別符號的 Web 服務，並且向 Retail Management System（請見圖 4）發出搜尋請求。在成功搜尋完之後，該 EAI 應用程式向 SOA 發出資訊來將其新增到複合應用程式中。

圖 4. 多重 SOA 呼叫多重 EAI 應用程式

接下來，複合應用程式呼叫並向 Order Management System 發出請求來搜尋 Pricing Policies 資料庫。在成功搜尋之後，Order Management System 將其本身與第二個 SOA 中的稅務 Web 服務相連線。然後，稅務 Web 服務被併入了第一個 SOA 的複合帳單功能中。所有裝載及解除安裝的流程都成功地完成了，沒有出現 SOAP 開銷問題。

有多少 SOA？

您用於連結 EAI 應用程式的可用的 SOA 的數量依賴於對專案的複雜性、互用性問題、業務流程及裝載效能問題的權衡。同您避免 SOAP 的開銷一樣，您需確保在整個開發週期中不會出現 SOA 超載問題。您應當在開發的每個階段都進行超載測試。

轉自IBM DW中國

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-600850/，如需轉載，請註明出處，否則將追究法律責任。