讓SOA為Java應用增加價值,而不是複雜性
阿新 • • 發佈：2019-02-10
摘要
術語SOA（面向服務架構）正處於失支所有軟體工程中有意義的東西的危險境地。為什麼會這樣？因為他的 核心基礎是簡單並且可以應用到所有技術，所有平臺，所有工業標準，如J2EE，.Net和所有LAMP的變體（如在Linux/Apache/Perl/Python/PHP 中使用MySQL），Ruby on Rails，公共部門，商業系統，航天系統，醫療系統等等。結果是：由於SOA已經成為IT銷售部門提升業績而用來附加 的華而不實的東西，並且成為開必廠商用來給包裝他們應用的一種噱頭。通過本文，作者解釋了SOA在J2EE中適用的地方，可編輯SOA如何增加 實際的商業價值，並且如何在J2EE應用中最佳的使用SOA。
作者:Humphrey Sheil;
原文:http://www.javaworld.com/javaworld/jw-01-2006/jw-0109-soa.html
譯文:http://www.matrix.org.cn/resource/article/44/44221_SOA+Simple+Java.html
關鍵字:SOA;Simple;Java
最近，SOA成為跨技術平臺（特別是J2EE和.Net）軟體開發中的熱門話題。然而，如果我們比較一下圍繞著SOA的宣傳和90年代後期EJB 和服務件的宣傳，你會發現這沒有什麼區別。1998年，EJB帶領網際網路的潮流並推翻了以CORBA的統治和由PB/Oracle Forms和其他主導的CS架構 標準。SOA，作為一種新技術的術語，還不具有那麼大的破壞性。SOA只是一種想法/概念和一組構建應用功能的最佳實踐。相反地，J2EE是一套 完整地開發技術，可以用來設計所有的東西。
我對SOA的主要關注在於企業級Java應用通用的問題：複雜性。次要關注的是SOA通 常作為一種解決方案被用來跨越J2EE應用各層，雖然這好像沒有什麼意義。本文提取出SOA的基本元素並介紹他們。一旦我們理解這些，就可以 理解SOA系統中的更復雜的元件了。最後，我們可以瞭解一下SOA給J2EE應用帶來的實際價值，同時並不增加無用的複雜性。
本文分為個 部分：首先，提出了我對SOA作為一種標準參考點的定義。其次，檢查那些主要的軟體工種問題通過SOA可以解決而不是用SOA來檢查。再次，會 給出基於複雜需求的SOA的建議分類。最後，給出三種主要SOA分類的建議實現。
SOA是什麼？
SOA有很多定義。下面是我的定義：
SOA是巨集級別的應用到應用架構級的設計模式：
1、 可選地暴露應用的功能作為一組離散的元件。
2、 使這些元件能被用來構建更復雜的元件和應用。
3、 僅包含基於訊息的元件內部通訊。
我還遺漏了什麼呢？還有一些方面，包 括：
1、 安全性
2、 事務
3、 狀態或無狀態會話
4、 訊息無資料
5、 訊息特性
6、 訊息協議
7、 消 息內容
8、 具體技術實現
這些方面也是重要的，但不是主要的。我的 定義提取了SOA的核心規則，但沒有拋棄概念本身。
注意我在定義中引用了設計模式。我認為這是關鍵。SOA不是什麼新技術，事實上， 其最吸引人的一個地方是可以利用現有的技術並使其泛出新的光芒。對我來說，SOA更像是一幅藍圖，一組最佳實踐，或者說是一個定義下一代 的軟體應用應該如何設計和實現的規範。
基礎SOA方法
從上面的定 義，我們應該可以標識出組成SOA應用的必須提供的軟體服務的最小集合。簡潔地說，這些服務是：
1、 訊息層，允許訊息通過特定的協議傳輸和接收。用SOA的說法，這一層稱為企業服務母線 或簡寫為ESB。
2、 一個元件模型，如應用必須遵循的傳送和接收來訊息母線的消 息的最小約定。
取決於你自己的業務需求，這兩種服務可以極度的擴大，但在核心來說，訊息層和通用元件模型就代表了SOA。
注意，我沒有在SOA的定義中包含自動定位和發現服務（在大部分JEE場景中，這是很有殺傷力的）。在UDDI（通用描述/發現/集 成協議）後的原始想法是認為企業最終會使用軟體服務（通過一個大的基於元資料搜尋服務倉庫）來購買和銷售。這個美夢至少也得十年後， 也許永遠不會實現，因為人們是需要做的實際的業務而不是軟體。
JEE應用不需要自動發現服務，例如登入或支付服務，這些服務 應該在初始化時設定。不要誤導我，如果這些服務的實現不應該硬編碼到應用中，那麼你也不需要SOA來解決這些問題了。
下一節 ，我們會來考慮一下究竟需要SOA來解決什麼，或者他能替代什麼。
為什麼要SOA？
最近的兩撥企業級軟體開發的主浪潮是C/S架構和多層架構。雖然多層架構提供了C/S架構中佈署/平臺支援/效能/伸 縮性上更好的效果，但兩者都沒有解決一個關鍵的企業級計算機領域的軟體工程問題：如何重用軟體功能。
作為軟體開發人員和架構師 ，我們始終沒有完全解決軟體重用的問題。再往下看，你會看到我也不認為SOA能解決這個問題。然而，我認為軟體重用是SOA出現的最重要原 因（至少在JEE應用中是這樣）。
其他SOA使用現有的Jini和風格計算。基於Jini環境的特點如下：
1、 自動發現元件/服務
2、 自 愈的
然而，這些特性並沒有與JEE應用等同的重要性。使用JDBC配置資料庫的位置只需要一次。我期望資料庫來提供容錯和除錯功 能，而且我不需要JEE應用來嘗試當產品例項當機時自動發現其他的資料庫例項。另一方面，對一個有2000個工作站的辦公室來說自動發現一個 彩色印表機是一件好事，這也是符合Jini硬體的一個關鍵好處。
平等地主，在一個真實的全球網格計算環境中，自動發現和列舉 計算資源來解決問題是基礎框架的關鍵部分，但這不是一個JEE環境，那兒硬體預先計算的以便在定義使用者資料和服務效能之間平衡。
我的觀點是，SOA對不同的需求需要不同對待。在本文中，我只關心JEE架構方面的SOA，而我認為這意味著功能重用。其他從JEE觀點 來看SOA的優點還有：
1、 鬆耦合的元件，這是軟體設計中重要的部分
2、 引入ESB作為訊息層意味著強制“面向介面程式設計，而不是實現”
3、 非同步訊息增加了應用的伸縮性
讓我們通過問三個特定的問題來看一下軟體 重用中更細節的問題：
1、 為什麼重用軟體是重要的？
2、 SOA是如何提出解決軟體重用問題的？
3、 是否SOA的允諾能夠使軟體重用應用到現實中？
首先，軟體重用是重要的原 因如下：
1、 時間和花費上的效率—能夠重用已經的元件來滿足陳述的業務 需求將節省大量的時間和金錢。
2、 重要的特性包括但不限於如穩定性/效能/可管 理性/文件/可配置性。因為一個元件被重用的次數越多，對這個元件的投資也越多，他的優勢也越多。
3、 良好設計的可重用框架無論在哪裡被使用都擁有正面的效果，而且你願意的話可以封裝 更好的想法來解決通用問題。
因此我們需要重用性。那麼最簡單的方法是什麼呢？就是打包軟體作為一組良好定義的元件來滿足 離散的功能需求。然後，如果其他應用需要相同的元件，他就可以重用了。還有些細節需要考慮，如如何配置，但這些細節已經偏離了主題： 重用任何語言編寫的程式碼，那些程式碼必須被設計成一組離散的元件或重構為集合。
可以參考我在JavaWorld上的第一篇文章， “節省時間的框架”（2000.9），有更多細節善於JEE專案的軟體重用。
其次，SOA是如何解決軟體重用的問題呢？是 通過基於元件模型來構建和引入一個重要的強制約定：元件間的通訊要通過下發到ESB的訊息來進行，而這就確保了鬆耦合。實際上，最廣泛布 署的SOA實現—Web services可以通過使訊息層技術中性來縫合用不同語言開發的元件。
最後，SOA對軟體重用的允諾真有實 際意義嗎？不，我想念如果SOA在1945（大概是和ENIAC同時代吧）被髮明的話確實可以解決軟體重用的問題。但沒有，現存的大量程式碼是用不 同的開發語言編寫的，有COBOL/C/C++/Java/C#和其他語言。
這些程式碼沒有作為離散的元件來編寫，因此也沒有SOA魔法來解決。事實上 ，我認為有大量的SOA專案的工作是花費在重構相同的程式碼庫。
現在，讓我們來看一下對於JEE應用SOA可以解決的一些問題。
SOA缺點
SOA 缺點包括下面三方面：
1、 SOA自身的缺點，主要當前還沒有成熟的實現
2、 SOA的複雜性
3、 廠商對SOA 在更廣泛的JEE產品和方案中的位置
那麼我們就心批判的眼光來看一下：
·並沒有像JEE規範那樣有自己的正式規範 。雖然有一個釋出的規範，但那個太複雜了並且沒有遵循80:20法則（80%的應用需要簡單的SOA，只有20%的應用需要更強大而複雜的功能）
·有狀態會話依然存在廣泛爭議而且現在還沒有被SOA的預設實現（Web services）所解決。而無狀態會話已經是完全支援了。
·由於預設正式或推薦的規範，Web services已經成為許多人眼裡SOA的代名詞了，但Web services通常是過於強大了。
·SOA增加了複雜性。可能你更喜歡硬編碼和緊耦合，而不需要XML配置檔案來執行簡單的應用。
·SOA相容的應用對本身 來說沒有什麼意義。其商業價值來自於能夠提供離散的功能塊通過SOA被用於其他的應用和模組。例如，如果你對訂單的較驗規則是通過JSP頁 面中的Java程式碼來實現的，那麼你還需要重構程式碼將其放到服務端物件中以便於SOA呼叫—但很多廠商並沒有提及這一點。
·在某些情況下，廠商將SOA作為網頁應用框架的替代者！我認為，WAF是SOA定義功能中的消費者，只是作為一種補充，而不存在竟爭 關係。
· 與廠商提供的相反，一些應用根本不需要SOA而只需要簡單使用MVC框架就可以了。這很短視嗎？我不這麼認為，即使 SOA的特性是需要的，在上面的情況下，最重要的部分是用來服務於企業服務匯流排的良好定義的業務邏輯層，而不是ESB自身。
雖 然我不認為SOA是一顆解決現有和新建應用中問題的銀彈，便我相信SOA在他相應的位置上還是有其內在的價值的。現在讓我們來看一下在應用 中增加有效的SOA解決方案是如何提供體現其商業價值的。
建議的SOA分類
現在，你應該對我保持事物的簡單性的熱忱表示感激吧。但我本質上並不是簡單論者，我是一個實用主義者。對軟體專案來說，我認 為實用主義是一方面要平衡專案的商業和實際價值，另一方面是使用軟體設計上的最佳實踐。簡單的說，就是在我們現有條件下構建我們所能 建立的最好的系統。
一個實用主義的好例子來自於民間的工程歷史。在修鐵路時常修木橋，而我們知道用鐵橋會更好。當鐵路公 司的股東想使用鐵路儘快開工而且初始投資要有限制時，他就是這是最好的工程方案了。是否聽起來耳熟？同樣的原則可以應用於軟體工程。
根據實用主義的精神，我建議將SOA分為三個級別：簡單/中等/複雜，衡量標準是需要滿足的業務需求。如果你需要簡單的SOA， 那麼不要浪費時間和金錢在複雜的SOA上。
級別1：簡單的SOA
樣例實現：
1、 使用自己的POJO佇列實現來發送和接收訊息。
2、 帶有MDB（訊息驅動Bean）的JMS佇列/主題作為訊息的消費者。
這裡涵蓋的 關鍵SOA概念有：
1、 企業服務匯流排
2、 生產者/消費者的元件模型。
Figure 1. Schematic illustrating the core components of the simple SOA. Click on thumbnail to view full-sized image.
級別2：中等的SOA
樣例實現：
1、 帶有MDB的JMS佇列/主題作為訊息的消費者，並附加其他特性如安全性/事務/JMS元資料 屬性等
2、 Web services，例如Apache Axis
這裡涵蓋的關鍵SOA概念在包含 簡單SOA外還有：
1、 用來增加健壯性和可靠性的錯誤/重試佇列。
2、 引入XML作為訊息的有效負載內容來代替序列化Java物件，從而支援其他技術如.Net
Figure 2. Schematic illustrating the core components of the medium-complexity SOA. Click on thumbnail to view full-sized image.
級別3：複雜的SOA
樣例實現：
1、 帶有MDB的JMS佇列/主題作為訊息的消費者，並附加其他特性如安全性/事務/JMS元資料 屬性等
2、 Web services
3、 廠商/標準相關的SOA相容工具包（如專門的金融服務）
這裡涵蓋的關鍵SOA 概念在包含中等SOA外還有：
1、 良好定義而且嚴格的元件模型（例如Java業務集 成/服務元件架構及其他）
2、 增強的廠商支援，如可插拔的新生產者/消費者元件 建立
3、 詳細列舉特定SOA實現上可用服務的元件登錄檔。
Figure 3. Schematic illustrating the core components of the complex SOA. Click on thumbnail to view full-sized image.
小結
目前SOA是作為一種架構 體現，也將會成為與C/S或多層架構一樣存在。但是，他目前還是不夠成熟而且只是作為廠商利用的工具。我對SOA的建議是，從簡單的做起並 保持SOA儘可能的簡單。不要將SOA與Web services等同起來，也不要強制使用SOA的設計模式在JEE應用的各層上，告別是網頁層。
那麼我會為大多數JEE應用推薦哪一個SOA實現呢？級別2上的SOA實現如帶有MDB的JMS佇列作為消費者，而POJO或無狀態的會話Bean作為訊息 生產者。當然，如果你確信你需要整合非Java應用,那麼考慮一下Web services實現。還要考慮你現在採用的解決方案在以後要有足夠的擴充套件空 間。雖然預測多久通常都有爭議的，但我還是建議最遠不超過36個月。如果你預見到那個時間段內有額外的SOA需求，那麼現在就來構建吧。
關於作者
Humphrey Sheil是英國服務業企業級應用供應商CedaropenAccounts的首席技術架構師。特別擅長於整合 領域。擁有愛爾蘭都柏林大學的電腦科學碩士學位。點選這裡進入他的部落格。
資源
·Jini技術，最早的 SOA實現之一:http://www.jini.org
·JEE規範:http://java.sun.com/j2ee/download.html#platformspec
·學 習.Net的的入門點：http://msdn2.microsoft.com/en-us/library/ms310245(en-us,MSDN.10).aspx
·http://www.uddi.org UDDI協議
·建立SOA的準備：http://weblog.infoworld.com/techwatch/archives/004644.html
·Java業務整合， 用來為Java應用（特別指基於SOA的應用）定義元件模型的規範。這更正規些，因此允許廠商根據標準提供工具和框架以實現最終的互動性。目 前許多失敗就是因為缺少這些支援：http://www.jcp.org/en/jsr/detail?id=208
·http://ws.apache.org/axis/ 開源的JEE網 頁服務實現- Apache Axis
術語SOA（面向服務架構）正處於失支所有軟體工程中有意義的東西的危險境地。為什麼會這樣？因為他的 核心基礎是簡單並且可以應用到所有技術，所有平臺，所有工業標準，如J2EE，.Net和所有LAMP的變體（如在Linux/Apache/Perl/Python/PHP 中使用MySQL），Ruby on Rails，公共部門，商業系統，航天系統，醫療系統等等。結果是：由於SOA已經成為IT銷售部門提升業績而用來附加 的華而不實的東西，並且成為開必廠商用來給包裝他們應用的一種噱頭。通過本文，作者解釋了SOA在J2EE中適用的地方，可編輯SOA如何增加 實際的商業價值，並且如何在J2EE應用中最佳的使用SOA。
作者:Humphrey Sheil;
原文:http://www.javaworld.com/javaworld/jw-01-2006/jw-0109-soa.html
譯文:http://www.matrix.org.cn/resource/article/44/44221_SOA+Simple+Java.html
關鍵字:SOA;Simple;Java
最近，SOA成為跨技術平臺（特別是J2EE和.Net）軟體開發中的熱門話題。然而，如果我們比較一下圍繞著SOA的宣傳和90年代後期EJB 和服務件的宣傳，你會發現這沒有什麼區別。1998年，EJB帶領網際網路的潮流並推翻了以CORBA的統治和由PB/Oracle Forms和其他主導的CS架構 標準。SOA，作為一種新技術的術語，還不具有那麼大的破壞性。SOA只是一種想法/概念和一組構建應用功能的最佳實踐。相反地，J2EE是一套 完整地開發技術，可以用來設計所有的東西。
我對SOA的主要關注在於企業級Java應用通用的問題：複雜性。次要關注的是SOA通 常作為一種解決方案被用來跨越J2EE應用各層，雖然這好像沒有什麼意義。本文提取出SOA的基本元素並介紹他們。一旦我們理解這些，就可以 理解SOA系統中的更復雜的元件了。最後，我們可以瞭解一下SOA給J2EE應用帶來的實際價值，同時並不增加無用的複雜性。
本文分為個 部分：首先，提出了我對SOA作為一種標準參考點的定義。其次，檢查那些主要的軟體工種問題通過SOA可以解決而不是用SOA來檢查。再次，會 給出基於複雜需求的SOA的建議分類。最後，給出三種主要SOA分類的建議實現。
SOA是什麼？
SOA有很多定義。下面是我的定義：
SOA是巨集級別的應用到應用架構級的設計模式：
1、 可選地暴露應用的功能作為一組離散的元件。
2、 使這些元件能被用來構建更復雜的元件和應用。
3、 僅包含基於訊息的元件內部通訊。
我還遺漏了什麼呢？還有一些方面，包 括：
1、 安全性
2、 事務
3、 狀態或無狀態會話
4、 訊息無資料
5、 訊息特性
6、 訊息協議
7、 消 息內容
8、 具體技術實現
這些方面也是重要的，但不是主要的。我的 定義提取了SOA的核心規則，但沒有拋棄概念本身。
注意我在定義中引用了設計模式。我認為這是關鍵。SOA不是什麼新技術，事實上， 其最吸引人的一個地方是可以利用現有的技術並使其泛出新的光芒。對我來說，SOA更像是一幅藍圖，一組最佳實踐，或者說是一個定義下一代 的軟體應用應該如何設計和實現的規範。
基礎SOA方法
從上面的定 義，我們應該可以標識出組成SOA應用的必須提供的軟體服務的最小集合。簡潔地說，這些服務是：
1、 訊息層，允許訊息通過特定的協議傳輸和接收。用SOA的說法，這一層稱為企業服務母線 或簡寫為ESB。
2、 一個元件模型，如應用必須遵循的傳送和接收來訊息母線的消 息的最小約定。
取決於你自己的業務需求，這兩種服務可以極度的擴大，但在核心來說，訊息層和通用元件模型就代表了SOA。
注意，我沒有在SOA的定義中包含自動定位和發現服務（在大部分JEE場景中，這是很有殺傷力的）。在UDDI（通用描述/發現/集 成協議）後的原始想法是認為企業最終會使用軟體服務（通過一個大的基於元資料搜尋服務倉庫）來購買和銷售。這個美夢至少也得十年後， 也許永遠不會實現，因為人們是需要做的實際的業務而不是軟體。
JEE應用不需要自動發現服務，例如登入或支付服務，這些服務 應該在初始化時設定。不要誤導我，如果這些服務的實現不應該硬編碼到應用中，那麼你也不需要SOA來解決這些問題了。
下一節 ，我們會來考慮一下究竟需要SOA來解決什麼，或者他能替代什麼。
為什麼要SOA？
最近的兩撥企業級軟體開發的主浪潮是C/S架構和多層架構。雖然多層架構提供了C/S架構中佈署/平臺支援/效能/伸 縮性上更好的效果，但兩者都沒有解決一個關鍵的企業級計算機領域的軟體工程問題：如何重用軟體功能。
作為軟體開發人員和架構師 ，我們始終沒有完全解決軟體重用的問題。再往下看，你會看到我也不認為SOA能解決這個問題。然而，我認為軟體重用是SOA出現的最重要原 因（至少在JEE應用中是這樣）。
其他SOA使用現有的Jini和風格計算。基於Jini環境的特點如下：
1、 自動發現元件/服務
2、 自 愈的
然而，這些特性並沒有與JEE應用等同的重要性。使用JDBC配置資料庫的位置只需要一次。我期望資料庫來提供容錯和除錯功 能，而且我不需要JEE應用來嘗試當產品例項當機時自動發現其他的資料庫例項。另一方面，對一個有2000個工作站的辦公室來說自動發現一個 彩色印表機是一件好事，這也是符合Jini硬體的一個關鍵好處。
平等地主，在一個真實的全球網格計算環境中，自動發現和列舉 計算資源來解決問題是基礎框架的關鍵部分，但這不是一個JEE環境，那兒硬體預先計算的以便在定義使用者資料和服務效能之間平衡。
我的觀點是，SOA對不同的需求需要不同對待。在本文中，我只關心JEE架構方面的SOA，而我認為這意味著功能重用。其他從JEE觀點 來看SOA的優點還有：
1、 鬆耦合的元件，這是軟體設計中重要的部分
2、 引入ESB作為訊息層意味著強制“面向介面程式設計，而不是實現”
3、 非同步訊息增加了應用的伸縮性
讓我們通過問三個特定的問題來看一下軟體 重用中更細節的問題：
1、 為什麼重用軟體是重要的？
2、 SOA是如何提出解決軟體重用問題的？
3、 是否SOA的允諾能夠使軟體重用應用到現實中？
首先，軟體重用是重要的原 因如下：
1、 時間和花費上的效率—能夠重用已經的元件來滿足陳述的業務 需求將節省大量的時間和金錢。
2、 重要的特性包括但不限於如穩定性/效能/可管 理性/文件/可配置性。因為一個元件被重用的次數越多，對這個元件的投資也越多，他的優勢也越多。
3、 良好設計的可重用框架無論在哪裡被使用都擁有正面的效果，而且你願意的話可以封裝 更好的想法來解決通用問題。
因此我們需要重用性。那麼最簡單的方法是什麼呢？就是打包軟體作為一組良好定義的元件來滿足 離散的功能需求。然後，如果其他應用需要相同的元件，他就可以重用了。還有些細節需要考慮，如如何配置，但這些細節已經偏離了主題： 重用任何語言編寫的程式碼，那些程式碼必須被設計成一組離散的元件或重構為集合。
可以參考我在JavaWorld上的第一篇文章， “節省時間的框架”（2000.9），有更多細節善於JEE專案的軟體重用。
其次，SOA是如何解決軟體重用的問題呢？是 通過基於元件模型來構建和引入一個重要的強制約定：元件間的通訊要通過下發到ESB的訊息來進行，而這就確保了鬆耦合。實際上，最廣泛布 署的SOA實現—Web services可以通過使訊息層技術中性來縫合用不同語言開發的元件。
最後，SOA對軟體重用的允諾真有實 際意義嗎？不，我想念如果SOA在1945（大概是和ENIAC同時代吧）被髮明的話確實可以解決軟體重用的問題。但沒有，現存的大量程式碼是用不 同的開發語言編寫的，有COBOL/C/C++/Java/C#和其他語言。
這些程式碼沒有作為離散的元件來編寫，因此也沒有SOA魔法來解決。事實上 ，我認為有大量的SOA專案的工作是花費在重構相同的程式碼庫。
現在，讓我們來看一下對於JEE應用SOA可以解決的一些問題。
SOA缺點
SOA 缺點包括下面三方面：
1、 SOA自身的缺點，主要當前還沒有成熟的實現
2、 SOA的複雜性
3、 廠商對SOA 在更廣泛的JEE產品和方案中的位置
那麼我們就心批判的眼光來看一下：
·並沒有像JEE規範那樣有自己的正式規範 。雖然有一個釋出的規範，但那個太複雜了並且沒有遵循80:20法則（80%的應用需要簡單的SOA，只有20%的應用需要更強大而複雜的功能）
·有狀態會話依然存在廣泛爭議而且現在還沒有被SOA的預設實現（Web services）所解決。而無狀態會話已經是完全支援了。
·由於預設正式或推薦的規範，Web services已經成為許多人眼裡SOA的代名詞了，但Web services通常是過於強大了。
·SOA增加了複雜性。可能你更喜歡硬編碼和緊耦合，而不需要XML配置檔案來執行簡單的應用。
·SOA相容的應用對本身 來說沒有什麼意義。其商業價值來自於能夠提供離散的功能塊通過SOA被用於其他的應用和模組。例如，如果你對訂單的較驗規則是通過JSP頁 面中的Java程式碼來實現的，那麼你還需要重構程式碼將其放到服務端物件中以便於SOA呼叫—但很多廠商並沒有提及這一點。
·在某些情況下，廠商將SOA作為網頁應用框架的替代者！我認為，WAF是SOA定義功能中的消費者，只是作為一種補充，而不存在竟爭 關係。
· 與廠商提供的相反，一些應用根本不需要SOA而只需要簡單使用MVC框架就可以了。這很短視嗎？我不這麼認為，即使 SOA的特性是需要的，在上面的情況下，最重要的部分是用來服務於企業服務匯流排的良好定義的業務邏輯層，而不是ESB自身。
雖 然我不認為SOA是一顆解決現有和新建應用中問題的銀彈，便我相信SOA在他相應的位置上還是有其內在的價值的。現在讓我們來看一下在應用 中增加有效的SOA解決方案是如何提供體現其商業價值的。
建議的SOA分類
現在，你應該對我保持事物的簡單性的熱忱表示感激吧。但我本質上並不是簡單論者，我是一個實用主義者。對軟體專案來說，我認 為實用主義是一方面要平衡專案的商業和實際價值，另一方面是使用軟體設計上的最佳實踐。簡單的說，就是在我們現有條件下構建我們所能 建立的最好的系統。
一個實用主義的好例子來自於民間的工程歷史。在修鐵路時常修木橋，而我們知道用鐵橋會更好。當鐵路公 司的股東想使用鐵路儘快開工而且初始投資要有限制時，他就是這是最好的工程方案了。是否聽起來耳熟？同樣的原則可以應用於軟體工程。
根據實用主義的精神，我建議將SOA分為三個級別：簡單/中等/複雜，衡量標準是需要滿足的業務需求。如果你需要簡單的SOA， 那麼不要浪費時間和金錢在複雜的SOA上。
級別1：簡單的SOA
樣例實現：
1、 使用自己的POJO佇列實現來發送和接收訊息。
2、 帶有MDB（訊息驅動Bean）的JMS佇列/主題作為訊息的消費者。
這裡涵蓋的 關鍵SOA概念有：
1、 企業服務匯流排
2、 生產者/消費者的元件模型。
Figure 1. Schematic illustrating the core components of the simple SOA. Click on thumbnail to view full-sized image.
級別2：中等的SOA
樣例實現：
1、 帶有MDB的JMS佇列/主題作為訊息的消費者，並附加其他特性如安全性/事務/JMS元資料 屬性等
2、 Web services，例如Apache Axis
這裡涵蓋的關鍵SOA概念在包含 簡單SOA外還有：
1、 用來增加健壯性和可靠性的錯誤/重試佇列。
2、 引入XML作為訊息的有效負載內容來代替序列化Java物件，從而支援其他技術如.Net
Figure 2. Schematic illustrating the core components of the medium-complexity SOA. Click on thumbnail to view full-sized image.
級別3：複雜的SOA
樣例實現：
1、 帶有MDB的JMS佇列/主題作為訊息的消費者，並附加其他特性如安全性/事務/JMS元資料 屬性等
2、 Web services
3、 廠商/標準相關的SOA相容工具包（如專門的金融服務）
這裡涵蓋的關鍵SOA 概念在包含中等SOA外還有：
1、 良好定義而且嚴格的元件模型（例如Java業務集 成/服務元件架構及其他）
2、 增強的廠商支援，如可插拔的新生產者/消費者元件 建立
3、 詳細列舉特定SOA實現上可用服務的元件登錄檔。
Figure 3. Schematic illustrating the core components of the complex SOA. Click on thumbnail to view full-sized image.
小結
目前SOA是作為一種架構 體現，也將會成為與C/S或多層架構一樣存在。但是，他目前還是不夠成熟而且只是作為廠商利用的工具。我對SOA的建議是，從簡單的做起並 保持SOA儘可能的簡單。不要將SOA與Web services等同起來，也不要強制使用SOA的設計模式在JEE應用的各層上，告別是網頁層。
那麼我會為大多數JEE應用推薦哪一個SOA實現呢？級別2上的SOA實現如帶有MDB的JMS佇列作為消費者，而POJO或無狀態的會話Bean作為訊息 生產者。當然，如果你確信你需要整合非Java應用,那麼考慮一下Web services實現。還要考慮你現在採用的解決方案在以後要有足夠的擴充套件空 間。雖然預測多久通常都有爭議的，但我還是建議最遠不超過36個月。如果你預見到那個時間段內有額外的SOA需求，那麼現在就來構建吧。
關於作者
Humphrey Sheil是英國服務業企業級應用供應商CedaropenAccounts的首席技術架構師。特別擅長於整合 領域。擁有愛爾蘭都柏林大學的電腦科學碩士學位。點選這裡進入他的部落格。
資源
·Jini技術，最早的 SOA實現之一:http://www.jini.org
·JEE規範:http://java.sun.com/j2ee/download.html#platformspec
·學 習.Net的的入門點：http://msdn2.microsoft.com/en-us/library/ms310245(en-us,MSDN.10).aspx
·http://www.uddi.org UDDI協議
·建立SOA的準備：http://weblog.infoworld.com/techwatch/archives/004644.html
·Java業務整合， 用來為Java應用（特別指基於SOA的應用）定義元件模型的規範。這更正規些，因此允許廠商根據標準提供工具和框架以實現最終的互動性。目 前許多失敗就是因為缺少這些支援：http://www.jcp.org/en/jsr/detail?id=208
·http://ws.apache.org/axis/ 開源的JEE網 頁服務實現- Apache Axis