隨著J2EE的飛速發(fā)展，已經(jīng)有越來越多的企業(yè)應(yīng)用程序以J2EE技術(shù)為其構(gòu)建的基石，J2EE本身并不是產(chǎn)品，它只是制定了一套創(chuàng)建企業(yè)應(yīng)用程序的規(guī)范，不同廠商根據(jù)J2EE規(guī)范，創(chuàng)建了符合J2EE規(guī)范的產(chǎn)品，這給予了我們更多的選擇創(chuàng)建企業(yè)應(yīng)用的平臺。

一個(gè)典型的J2EE的應(yīng)用，至少應(yīng)該包括以下三部分：表現(xiàn)層，業(yè)務(wù)邏輯層和數(shù)據(jù)持久層，為了更加輕易地創(chuàng)建企業(yè)應(yīng)用程序，許許多多的Framework涌現(xiàn)出來，表現(xiàn)層我們可以選擇Struts, JSF, Tapestry, WebWork, Velocity等，數(shù)據(jù)持久層我們可以選擇原始的JDBC, ORMapping tools(Hibernate,toplink等),SQLMapper tools(Ibatis),JDO, EJB(Entity Bean)等，業(yè)務(wù)邏輯層我們可以用普通的java Beans,也可以用EJB(session Bean)。

每種技術(shù)都有它的優(yōu)點(diǎn)與缺點(diǎn)，各自有各自的適用范疇，例如EJB可以很好地進(jìn)行分布式處理和Object Cache等，但EJB的運(yùn)行需要EJB容器，開發(fā)調(diào)試起來很不方便，非凡在需求不確定性很大、模型不穩(wěn)定的情況下，實(shí)在是一種重量級別的開發(fā)；而JAVA BEAN則是一種很輕量級的方式，開發(fā)調(diào)試輕易，但又很難實(shí)現(xiàn)分布式處理。

在各種技術(shù)紛爭的今天，暫時(shí)還沒有一種技術(shù)處于絕對的霸主地位，在這種條件下，我們不能把“賭注“押在任何一種技術(shù)上，如何使我們的應(yīng)用程序有很高的靈活性和易擴(kuò)展性是我們要仔細(xì)研究的課題。

在實(shí)際的項(xiàng)目中，關(guān)于應(yīng)用程序開發(fā)時(shí)所用技術(shù)的問題，大致存在兩種情況，一種是構(gòu)架師或技術(shù)經(jīng)理沒有嚴(yán)格限定用什么技術(shù)來實(shí)現(xiàn)具體的業(yè)務(wù)邏輯或者只有簡單的開發(fā)規(guī)范，程序員在開發(fā)時(shí)，只是依據(jù)自己的技術(shù)背景，選擇自己熟悉的實(shí)現(xiàn)方式，這種情況一般屬于橫向開發(fā)，在小的項(xiàng)目中，每個(gè)人只做自己負(fù)責(zé)的一個(gè)模塊，從表現(xiàn)層，業(yè)務(wù)邏輯層，一直到數(shù)據(jù)層，都由同一個(gè)人來負(fù)責(zé)，這種方式給了技術(shù)人員更多的自我發(fā)揮能力的空間，但不便于后期維護(hù)，非凡是人員流動(dòng)頻繁的情況下，問題更是嚴(yán)重。

第二種情況是構(gòu)架師或技術(shù)經(jīng)理在項(xiàng)目初期從開發(fā)成本，項(xiàng)目需求等等各個(gè)方面做出評估，經(jīng)過幾番取舍，確定項(xiàng)目各個(gè)層面使用什么樣的技術(shù)實(shí)現(xiàn)方式，按不同層面進(jìn)行分工，不同的工作人員負(fù)責(zé)不同層面的技術(shù)實(shí)現(xiàn)，這種方式比第一種方式要好得多，適合校大項(xiàng)目的開發(fā)，但也存在很多問題。

在目前各種實(shí)現(xiàn)技術(shù)紛爭的情況下，沒有一種技術(shù)是萬能的，在做取舍時(shí)，難免和某一技術(shù)或?qū)崿F(xiàn)方式依靠性過強(qiáng)，同時(shí)限定了技術(shù)人員個(gè)人技術(shù)特長的很好發(fā)揮，當(dāng)由于某些原因要更改實(shí)現(xiàn)方式時(shí)，經(jīng)常是牽一發(fā)而動(dòng)全身，造成資源的極大浪費(fèi)和開發(fā)成本的提高。

所以，在構(gòu)建企業(yè)應(yīng)用時(shí)，應(yīng)該有個(gè)好的技術(shù)框架，這個(gè)框架應(yīng)該考慮到各種主流的實(shí)現(xiàn)技術(shù)，我們既可以根據(jù)實(shí)際情況進(jìn)行取舍，同時(shí)在從一種實(shí)現(xiàn)方式變更為另一種實(shí)現(xiàn)方式時(shí)，又可以進(jìn)行平滑過度，讓多種技術(shù)實(shí)現(xiàn)并存，發(fā)揮技術(shù)人員的最大優(yōu)勢，降低項(xiàng)目成本，提高開發(fā)效率。

基于SOA的構(gòu)架

圖一

SOA的優(yōu)勢在于降低了服務(wù)的提供者與使用者之間的耦合性，服務(wù)的提供者將自己提供的服務(wù)注冊在中介那里，服務(wù)使用者先通過中介查找自己所需服務(wù)，使用者獲得的是服務(wù)接口，但并不知道服務(wù)的具體實(shí)現(xiàn)，它根據(jù)調(diào)用接口調(diào)用服務(wù)，這樣即使服務(wù)的實(shí)現(xiàn)方式發(fā)生了變化，只要供使用者調(diào)用接口沒有改變，服務(wù)使用者就不會受到任何影響，這種思想正是我們應(yīng)該學(xué)習(xí)和借鑒的地方。

那么既然Web service是基于SOA的，我們的企業(yè)應(yīng)用是不是就可以完全構(gòu)架在Web service上呢？我們并不建議這么做，Web service對于企業(yè)內(nèi)部的應(yīng)用并不太適合，在一個(gè)應(yīng)用內(nèi)部使用Web service，系統(tǒng)大量的資源花費(fèi)在進(jìn)行XML消息的解析和進(jìn)行遠(yuǎn)程調(diào)用上，造成系統(tǒng)運(yùn)轉(zhuǎn)緩慢。

當(dāng)然，從某種意義上講，EJB也是SOA的一種實(shí)現(xiàn)，服務(wù)的提供者把服務(wù)注冊在JNDI上，使用者通過JNDI找到自己想要的服務(wù)，通過遠(yuǎn)程接口使用服務(wù)，但EJB的運(yùn)行需要EJB容器，開發(fā)調(diào)試起來不方便，非凡對于需求經(jīng)常變化的系統(tǒng)，進(jìn)行EJB調(diào)試的時(shí)間會更久。

我們所需要的是一個(gè)輕量級的構(gòu)架，能兼顧各種主流的技術(shù)，但又不依靠具體的某個(gè)實(shí)現(xiàn)方式，當(dāng)實(shí)現(xiàn)方式從一種技術(shù)變更為另一種技術(shù)時(shí)，對于服務(wù)的使用者來說幾乎沒有影響，從而實(shí)現(xiàn)客戶端和服務(wù)器端的松耦合，這樣，我們的表現(xiàn)層，業(yè)務(wù)邏輯層和數(shù)據(jù)持久層都可以依據(jù)實(shí)際需求情況與偏好隨意選擇各種實(shí)現(xiàn)方式。

隨著J2EE的飛速發(fā)展，已經(jīng)有越來越多的企業(yè)應(yīng)用程序以J2EE技術(shù)為其構(gòu)建的基石，J2EE本身并不是產(chǎn)品，它只是制定了一套創(chuàng)建企業(yè)應(yīng)用程序的規(guī)范，不同廠商根據(jù)J2EE規(guī)范，創(chuàng)建了符合J2EE規(guī)范的產(chǎn)品，這給予了我們更多的選擇創(chuàng)建企業(yè)應(yīng)用的平臺。

一個(gè)典型的J2EE的應(yīng)用，至少應(yīng)該包括以下三部分：表現(xiàn)層，業(yè)務(wù)邏輯層和數(shù)據(jù)持久層，為了更加輕易地創(chuàng)建企業(yè)應(yīng)用程序，許許多多的Framework涌現(xiàn)出來，表現(xiàn)層我們可以選擇Struts, JSF, Tapestry, WebWork, Velocity等，數(shù)據(jù)持久層我們可以選擇原始的JDBC, ORMapping tools(Hibernate,toplink等),SQLMapper tools(Ibatis),JDO, EJB(Entity Bean)等，業(yè)務(wù)邏輯層我們可以用普通的JAVA Beans,也可以用EJB(Session Bean)。

每種技術(shù)都有它的優(yōu)點(diǎn)與缺點(diǎn)，各自有各自的適用范疇，例如EJB可以很好地進(jìn)行分布式處理和Object Cache等，但EJB的運(yùn)行需要EJB容器，開發(fā)調(diào)試起來很不方便，非凡在需求不確定性很大、模型不穩(wěn)定的情況下，實(shí)在是一種重量級別的開發(fā)；而JAVA BEAN則是一種很輕量級的方式，開發(fā)調(diào)試輕易，但又很難實(shí)現(xiàn)分布式處理。

在各種技術(shù)紛爭的今天，暫時(shí)還沒有一種技術(shù)處于絕對的霸主地位，在這種條件下，我們不能把“賭注“押在任何一種技術(shù)上，如何使我們的應(yīng)用程序有很高的靈活性和易擴(kuò)展性是我們要仔細(xì)研究的課題。

在實(shí)際的項(xiàng)目中，關(guān)于應(yīng)用程序開發(fā)時(shí)所用技術(shù)的問題，大致存在兩種情況，一種是構(gòu)架師或技術(shù)經(jīng)理沒有嚴(yán)格限定用什么技術(shù)來實(shí)現(xiàn)具體的業(yè)務(wù)邏輯或者只有簡單的開發(fā)規(guī)范，程序員在開發(fā)時(shí)，只是依據(jù)自己的技術(shù)背景，選擇自己熟悉的實(shí)現(xiàn)方式，這種情況一般屬于橫向開發(fā)，在小的項(xiàng)目中，每個(gè)人只做自己負(fù)責(zé)的一個(gè)模塊，從表現(xiàn)層，業(yè)務(wù)邏輯層，一直到數(shù)據(jù)層，都由同一個(gè)人來負(fù)責(zé)，這種方式給了技術(shù)人員更多的自我發(fā)揮能力的空間，但不便于后期維護(hù)，非凡是人員流動(dòng)頻繁的情況下，問題更是嚴(yán)重。

第二種情況是構(gòu)架師或技術(shù)經(jīng)理在項(xiàng)目初期從開發(fā)成本，項(xiàng)目需求等等各個(gè)方面做出評估，經(jīng)過幾番取舍，確定項(xiàng)目各個(gè)層面使用什么樣的技術(shù)實(shí)現(xiàn)方式，按不同層面進(jìn)行分工，不同的工作人員負(fù)責(zé)不同層面的技術(shù)實(shí)現(xiàn)，這種方式比第一種方式要好得多，適合校大項(xiàng)目的開發(fā)，但也存在很多問題。

在目前各種實(shí)現(xiàn)技術(shù)紛爭的情況下，沒有一種技術(shù)是萬能的，在做取舍時(shí)，難免和某一技術(shù)或?qū)崿F(xiàn)方式依靠性過強(qiáng)，同時(shí)限定了技術(shù)人員個(gè)人技術(shù)特長的很好發(fā)揮，當(dāng)由于某些原因要更改實(shí)現(xiàn)方式時(shí)，經(jīng)常是牽一發(fā)而動(dòng)全身，造成資源的極大浪費(fèi)和開發(fā)成本的提高。

所以，在構(gòu)建企業(yè)應(yīng)用時(shí)，應(yīng)該有個(gè)好的技術(shù)框架，這個(gè)框架應(yīng)該考慮到各種主流的實(shí)現(xiàn)技術(shù)，我們既可以根據(jù)實(shí)際情況進(jìn)行取舍，同時(shí)在從一種實(shí)現(xiàn)方式變更為另一種實(shí)現(xiàn)方式時(shí)，又可以進(jìn)行平滑過度，讓多種技術(shù)實(shí)現(xiàn)并存，發(fā)揮技術(shù)人員的最大優(yōu)勢，降低項(xiàng)目成本，提高開發(fā)效率。

基于SOA的構(gòu)架

圖一