我對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的定義中包含自動定位和發現服務(在大部分J2EE場景中，這是很有殺傷力的)。在UDDI(通用描述/發現/集成協議)后的原始想法是認為企業最終會使用軟件服務(通過一個大的基于元數據搜索服務倉庫)來購買和銷售。這個美夢至少也得十年后，也許永遠不會實現，因為人們是需要做的實際的業務而不是軟件。
J2EE應用不需要自動發現服務，例如登錄或支付服務，這些服務應該在初始化時設置。不要誤導我，如果這些服務的實現不應該硬編碼到應用中，那么你也不需要SOA來解決這些問題了。
為什么要SOA?
最近的兩撥企業級軟件開發的主浪潮是C/S架構和多層架構。雖然多層架構提供了C/S架構中布署/平臺支持/性能/伸縮性上更好的效果，但兩者都沒有解決一個關鍵的企業級計算機領域的軟件工程問題：如何重用軟件功能。作為軟件開發人員和架構師，我們始終沒有完全解決軟件重用的問題。再往下看，你會看到我也不認為SOA能解決這個問題。然而，我認為軟件重用是SOA出現的最重要原因(至少在J2EE應用中是這樣)。
其他SOA使用現有的Jini和風格計算�；贘ini環境的特點如下：
1、自動發現組件/服務
2、自愈的
然而，這些特性并沒有與J2EE應用等同的重要性。使用JDBC配置數據庫的位置只需要一次。我期望數據庫來提供容錯和除錯功能，而且我不需要J2EE應用來嘗試當產品實例當機時自動發現其他的數據庫實例。另一方面，對一個有2000個工作站的辦公室來說自動發現一個彩色打印機是一件好事，這也是符合Jini硬件的一個關鍵好處。
平等地說，在一個真實的全球網格計算環境中，自動發現和枚舉計算資源來解決問題是基礎框架的關鍵部分，但這不是一個J2EE環境，那兒硬件預先計算的以便在定義用戶數據和服務性能之間平衡。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
