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