利用Ｊ２ＥＥ架構高效構造商用軟件

摘要：在現在的商業軟件開發領域，越來越多的公司使用J2EE架構來開發商用軟件。J2EE架構有很多自身的優勢。在J2EE架構所包含的眾多技術中，如何選擇合適與應用的技術來使我們的軟件開發達到最好的效果是一個很值得研究的問題。有些開發人員傾向于使用最新的技術，但是在很多情況下我們應該根據項目的具體情況選擇技術。該文用一個真實的商用軟件開發來展示如何根據項目需求在有限資源下幫助項目達到最大的效率。

關鍵詞：J2EE；SERVLET；applet；network

中圖法分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)29-0379-03

Construct Business Software Effectively

XIA Yi-fan

(School of Software Engineering，Tongji University，Shanghai 201804，China)

Abstract: Nowadays more and more company prefer to use the J2EE structure to develop the commercial software. The J2EE has too many advantages. Among the various technologies in J2EE， sometimes we really get confused and wonder what to use. Some people tender to use the latest technology. But in some occasions we should choose the technology we want to use according to the situations. In this article I want to use a real business project as an example to show how to choose between different technologies and make the project run more effectively under limited resources.

Key words: J2EE; SERVLET; applet; network

J2EE在現今的商用軟件開發中已經變得越來越流行了。J2EE架構有很多獨有的游戲。首先J2EE框架是基于java的一種開發框架，在多數情況下你不需要做太多的修改就能把已有的程序移植到其他平臺。其次J2EE是一種面向企業開發定制的架構，提供了很技術幫助我們可以高效迅速的開發適合企業應用的軟件。最后J2EE能夠幫助我們開發基于internet的web應用程序，在提供良好的用戶界面的同時也能夠隱藏復雜的業務邏輯，用戶只需要瀏覽器就可以使用系統，而后臺業務邏輯的變化也不需要通知用戶做出任何更改。所以在短短的幾年中，J2EE在全世界商用軟件開發領域變得越來越流行。

但是在使用J2EE架構的同時，我們也要注意J2EE提供了許多不同的技術，選在適合的技術就顯得非常的重要了。有些開發人員認為最新的技術是最適合開發的。但是在有些情況下也不盡然。對于任何一種開發語言來說在經過了一段時間的應用之后都會做出一些更改，這些更改一般而言是針對現有版本的一些錯誤做出的調整。但是任何技術都會隨著應用做出一些創新同時引入一些新的技術。但是有的時候這些新的技術在應用中被證明不適合商用軟件的開發。例如EJB是J2EE中一種很著名的技術，但是在實踐應用中被證明EJB的應用比較復雜難以控制。所以現在有很多開發者傾向于使用其他結構替代EJB的使用。所以在商用軟件開發中選擇什么樣的技術將直接影響項目的成功與否。

在J2EE的項目開發中有幾種技術組合使用的比較廣泛，在下面我將列出幾種最常用的組合。

1) JSP

這是開發系統比較簡單的一種方式。簡單是這種開發方式最大的優點。開發周期短，適合小型項目的開發。但是這種開發方式也有明顯的缺陷，在網頁中列出所有的業務邏輯是一種非常危險的開發方式。

2) JSP+SERVLET

這種方式下，JSP負責處理客戶端邏輯，SERVLET負責服務器端的事物處理。在很多情況下這是一種簡單高效的組合。

3) JSP+SEVLET+JAVABEAN+(XML)

這種組合在很多復雜的商用軟件中得到了非常廣泛的應用。JSP收集客戶端的信息，SERVLET 和 JAVABEAN負責客戶端和服務器端的通信。XML主要負責配置服務器信息，便于系統在不同的操作平臺間能夠順利的進行移植。

上面僅僅列出了一些常用的組合，現在HIBERNATE和SPRING技術也變得越來越流行。下面將用本人參與的一個項目作為例子來介紹一種安全高效的構建中型商用軟件的方式。

該系統是為電器公司開發的信息管理系統，用于從工程師處收集虛擬模擬所需要的數據，數據收集后會被傳送到服務器端存儲，同時服務器會調用一定算法將各個任務發送到后臺的工作站，工作站會使用傳送來的數據調用相關的分析軟件對數據進行分析。分析后的結果將會傳送回服務器相應的位置。同時工程師可以在服務器上查看，下載分析后的結果。同時如果任務計算時間長，用戶可以向服務器發送命令，暫停或刪除任務。圖1顯示了整個系統的結構。

如圖1所示，該系統是一個三層架構的系統。在該系統中有幾點需要考慮。首先我們想采取什么樣的方式來構建用戶界面。對于用戶來說他們希望有一個易于操作的界面，而對于系統設計者應該在界面設計上充分的考慮到將來業務的擴展。其次在服務端的數據存取方式也是需要著重考慮的一個方面。最后在三層架構中如何傳輸數據也需要得到合適的處理，保證系統達到最高的效率。如今很多大公司都采取這種三層架構的結構來構造商業軟件，在本文中我將結合自己的項目經驗來闡述如何有效地利用J2EE架構構造商用軟件。

首先我想先從客戶端的構建說起。在客戶端的構建中有幾點標準需要考慮。用戶界面應該易于操作而且能夠應對將來可能出現的變更。同時我們還應該考慮到安全的因素。所以在本系統我們采用applet開發用戶界面，applet有兩大優勢能夠保證滿足系統的需要。

1) 首先applet不需要安裝。Applet是平臺無關的一種技術，同時還能夠容易的播放視頻音頻文件。所以在不同的系統之間移植時你不需要對代碼進行任何的修改同時也沒有安裝的問題需要考慮。實際上，在用戶每次打開網頁的時候系統就自動加載了所需要的applet。所以applet的更新和安裝都是自動發生的，用戶不需要知道具體的更新，軟件自動升級擴展。在傳統的軟件中軟件的安裝和更新往往對于開發人員和用戶都是惡夢一般的經歷。

2) 其次你不需要擔心惡意的代碼可能對用戶的機器造成任何的損壞，因為java語言和applet都內建了完整的安全機制，這也是java語言非常流行的原因之一，

利用J2EE架構可以構建基于網絡的客戶端服務器架構，便于開發者控制系統。

Applet在一開始就是為了java客戶端的開發而設計的一種技術。所以applet本身在使用的時候有一些限制。Applet不能夠讀寫客戶端的本地磁盤。這是很明智的一種設計，因為沒有用戶希望applet讀取用戶本地的信息然后在用戶沒有察覺的情況下在互聯網上進行傳播。同時applet寫用戶的本地磁盤也是不被允許的，因為這樣就會使用戶的本地磁盤有被病毒或者木馬等感染的風險。這些applet本身所擁有的安全屬性正好能夠幫助我們很好的構建安全可靠的客戶端，保證我們系統的安全。

接下來我要詳細地分析一下如何有效地構建服務端的結構。在構建服務端架構時，SERVLET成為了第一選擇。SERVLET是J2EE架構中負責處理服務器端的通信任務。而applet和SERVLET之間有自己一套獨特的通信方式。這套獨特的通訊方式使用起來比較簡單同時又非常的高效。對于為遠程客戶機提供服務的服務器來說有兩個最主要的職責。第一個是處理網絡連接，第二個是負責對發起連接的客戶機產生相應的回應。對于第一個職責來說牽涉到了socket上的編程，系統需要從每個請求中獲取相應的信息，實現客戶端和服務端通信的相關協議，比如HTTP或者FTP協議等。而對于第二個任務來說，產生相應的方式就有很多種了，主要是根據所采用的傳輸協議不同。如果服務器采用FTP協議，那么產生的回應就相應來說比較簡單，只需要把文件存放在客戶機的制定位置即可。而對于采用HTTP作為傳輸協議服務器來說，服務器的功能比較齊全，所以產生回應的方式就相對復雜很多。服務器必須動態的產生回應。產生動態回應就涉及到了很多復雜的任務，包括從數據庫存取數據，應用復雜的商業邏輯，生成不同用戶需要的輸出格式等等。在構造HTTP服務器時，一種辦法是把所有的業務邏輯編寫成一個可執行的程序部署在服務端。這個可執行的程序復雜處理，包括管理網絡連接，存儲數據，產生回應等。但是對于處理企業級應用的HTTP服務器來說，我們需要服務器有很高的靈活性能夠應付復雜的業務擴展，如果我們用一個可執行文件處理所有的這些任務，當業務需要擴展的時候我們需要對我們的代碼進行徹底的更改，這是我們不希望看到的。在這種情況下，SERVLET可以很好的完成我們的任務。SERVLET是使用Java SERVLET應用程序設計接口及相關類和方法的Java程序。它在Web服務器上或應用服務器上運行并擴展了該服務器的能力。Java SERVLET對于Web服務器就好像Java Applet對于Web瀏覽器。Applet裝入Web瀏覽器并在Web瀏覽器內執行，而SERVLET則是裝入Web服務器并在Web服務器內執行。Java SERVLET API 定義了SERVLET和服務器之間的一個標準接口，這使得SERVLET具有跨服務器平臺的特性。SERVLET通過創建一個框架擴展服務器的能力，采用請求-響應模式提供Web服務。當客戶機發送請求至服務器時，服務器將請求信息發送給SERVLET，SERVLET生成響應內容并將其傳給Server，然后再由Server將響應返回給客戶端。在傳統的CGI中，每個請求都要啟動一個新的進程，如果CGI程序本身的執行時間較短，啟動進程所需要的開銷很可能反而超過實際執行時間。而使用SERVLET時，服務器上僅有一個Java虛擬機在運行，只有當SERVLET被調用時，它才被加載，且直到SERVLET更改時，它才會被再次加載。在傳統CGI中，如果有N個并發的對同一CGI程序的請求，則該CGI程序的代碼在內存中重復裝載了N次；而對于SERVLET，處理請求的是N個線程，只需要一份SERVLET類代碼。在性能優化方面，SERVLET也比CGI有著更多的選擇，比如緩沖以前的計算結果，保持數據庫連接的活動，等等。 通過使用SERVLET API，開發人員不必擔心服務器的內部運作方式。表格資料、服務器頭、cookies等皆可通過SERVLET處理。另外，因為SERVLET是用Java寫的，能將其從一個服務器移到另一個服務器以供發布，同時不必擔心操作系統或服務器的類型。這一優點充分體現了Java\"一次編寫，隨處運行\"的優越特性。圖2顯示了SERVLET的生命周期。

我們接下來需要著重解決的一個問題就是applet和SERVLET之間如何通信的問題。與傳統的通過socket來進行網絡連接的方式不同，applet和SERVLET之間通信有一種更為簡單有效的方式。我們不需要在客戶端和服務端都編寫相應的socket來傳輸數據，我們只需要發送post和get來完成客戶端和服務端之間的通信。如果你想使用GET消息來進行通信，那么applet需要在URL里面顯式的封裝變量名/值這樣的一對參數。比如我們想要發送LastName=Jones這樣的一對參數，那么我們的URL就可能變成這樣的形式，http://127.0.0.1/SERVLET/TestSERVLET?LastName=Jones。如果有多對參數需要發送，那么他們之間需要用進行分隔。所以如果我們還需要添加FirstName=Joe這樣地一對參數那么我們的URL的形式就變成了

http://127.0.0.1/SERVLET/TestSERVLET?LastName=JonesFirstName=Joe.

使用這樣的通信形式帶來了一個問題就是用戶能夠從URL中得到一些信息，例如用戶名密碼等私人的信息，這是我們不希望看到的，因為這會給系統的安全帶來潛在的威脅。所以我們選擇POST消息來進行通信。POST的通信方式的優點是我們只需要知道服務器端的SERVLET地址即可，我們不需要在URL中顯式的寫明任何參數，服務器需要的內容將以包的形式發送給服務器。這樣就不用擔心信息的泄漏可能給系統帶來的威脅。而且GET消息方式只適用于少量的信息發送，如果我們需要發送給服務端的信息量比較大的時候，POST方法是我們唯一的選擇。以下的代碼展示了POST方法是如何在客戶端和服務器端進行通信的。

// connect to the SERVLET

String location = \"http://www.foo.com/SERVLET/TestSERVLET\";

URL testSERVLET = new URL( SERVLETLocation );

URLConnection SERVLETConnection = testSERVLET.openConnection();

// inform the connection that we will send output and accept input

SERVLETConnection.setDoInput(true);

SERVLETConnection.setDoOutput(true);

// Don't use a cached version of URL connection.

SERVLETConnection.setUseCaches (1);

SERVLETConnection.setDefaultUseCaches (1);

// Specify the content type that we will send binary data

SERVLETConnection.setRequestProperty

(\"Content-Type\"， \"\");

// get input and output streams on SERVLET

. . .

// send your data to the SERVLET

SERVLETConnection = testSERVLET.openConnection();

SERVLETConnection.setDoInput(true);

SERVLETConnection.setDoOutput(true);

SERVLETConnection.setUseCaches(1);

SERVLETConnection.setRequestProperty(\"Content-Type\"， \"application/octet-stream\");

outputToSERVLET = new ObjectOutputStream(SERVLETConnection. getOutputStream());

outputToSERVLET.writeObject(p);

outputToSERVLET.flush();

outputToSERVLET.close();

ObjectInputStream inputFromSERVLET = 1;

inputFromSERVLET = new ObjectInputStream(SERVLETConnection.getInputStream());

try{

dataTrans = (VCDataTransfer) inputFromSERVLET.readObject();

}

catch (Exception e){

e.printStackTrace();

}

inputFromSERVLET.close();

在SERVLET從客戶端收到請求和相應的包后，SERVLET進行相應的操作，將用戶請求的數據返還給applet。SERVLET使用OUTPUTSTREAM和WRITEOBJECT方法將數據寫回發送請求的客戶端，下面的代碼段顯示了這個過程。

public void sendback(HttpSERVLETResponse response， Vector dataVector)

{

ObjectOutputStream outputToApplet;

try

{

outputToApplet = new ObjectOutputStream(response.getOutputStream());

System.out.println(\"Sending student vector to applet...\");

outputToApplet.writeObject(dataVector);

outputToApplet.flush();

outputToApplet.close();

System.out.println(\"Data transmission complete.\");

}

catch (IOException e)

{

e.printStackTrace();

}

}

到現在我已經簡要的介紹了在使用J2EE架構開發商用軟件的各個方面。重點介紹了如何使用APPLET和SERVLET配合開發出適合企業級需要的商用軟件。隨著開發語言的不斷發展，各種語言都不斷的推出一些新技術，但是老的技術模式在多年的應用之后已經變得非常的成熟完備，所以我認為我們不應該一味的追求技術的新奇，而是應該根據項目的需求來進行分析。如果一些老的模式能夠高效的完成我們所需要到任務，我們就不應該著急的使用新的技術來替代老的技術。首先新的技術在發布之初并不一定非常的穩定，在一些情況下可能產生一些意想不到的錯誤。其實使用新的技術意味著更多財力物力人力的投入，是一件費時費力的事情。所以如果老的技術模式能夠完成任務的情況下，使用一些老的技術模式能夠為公司節省人力和物力。在工程的角度上來說這就尤為重要了。就像本文中介紹的APPLET和SERVLET的組合在很多情況下都能夠高效安全的完成我們的任務，同時還具有很好的可擴展性并且易于維護。所以在任何情況下我們都應該更關注我們的需求而不是技術的新舊，選擇最有效最經濟的方式來構建高效的商用軟件。

參考文獻 ：

[1] Eckel B.Thinking In Java[M].3版.陳昊鵬，饒若楠，譯.北京:機械工業出版社，2005.

[2] JavaTM SERVLET Specification Version 2.4[EB/OL].http://java.sun.com/products/Servlets.

[3] Java Programming Language(SUN_SL275)[EB/OL].http://sun-microsystem.javaeye.com/.

[4] Stephanie B，Eric A，Jennifer B，et al.The J2EETM 1.4 Tutorial[M].Addison-Wesley Professional，2004.