在意識到軟體架構的重要性後，應用伺服器必然成為程式設計師的一件必不可少的"武器”。以下是為大家分享的Java應用伺服器的七種武器，供大家參考借鑑，歡迎瀏覽!
第一種武器：信心——理解應用伺服器並不困難
某些技術創造自己的傳奇的方法是很有趣的。我還記得自己在作為程式設計師時處理包含原始碼註釋(例如"不要放入此處"或者稍微文雅一點"此處危險")的產品。我們感覺非常複雜的程式碼是不可管理的。應用伺服器也成了相似的情況，人們毫無理由地恐懼的領域。在市場上，很多僱主把人們對於應用伺服器的應用知識作為強制性的工作要求。實際上應用伺服器並不是很複雜。例如，Sun微系統公司在自己的基於J2EE的應用伺服器中包含了大量的文件資訊。你甚至於可以免費下載它，並在一個很基本的Windows XP專業版計算機上執行那些優秀的示例。
Sun的教程記述了大量的程式碼示例，演示了J2EE和該公司的應用伺服器產品的優勢和易用性。閱讀這些文件是有價值的，因為它為我們洞察這種極其重要的軟體技術的工作情況提供了入口。Sun的競爭者還有BEA、IBM和開放原始碼應用伺服器JBOSS。
BEA甚至於把應用伺服器作為它的"透明計算"的第一步。它具有面向服務的架構的優點，在面向服務的架構中，我們可以利用舊的和新的應用程式來簡化不斷增長的敏捷型組織對服務的需求。BEA的觀點是可能出現一種情況：公司改變它們的IT系統和業務流程可以像從一個應用程式中剪下資料然後貼上到另一個應用程式中那樣簡單。其要點在於這種努力是基於應用程式伺服器技術的。
很明顯，應用伺服器是成熟的軟體工業中的重要元素。它們內容豐富，並且依靠集中的應用程式管理，允許資料的集中儲存。這種技術是可以使用並且不難理解的。
第二種武器 平臺性——應用伺服器是一種軟體平臺
應用伺服器趨向於減少企業需要的中介軟體數量--因為它們是中介軟體!與包含了防火牆的Windows類似，應用伺服器可能吸收一些現有的中介軟體產品所扮演的角色。這是因為應用伺服器自身就是用於軟體部署以供多個客戶端使用的平臺。在應用伺服器中使用的軟體有截然不同的生命週期，包括：
· 開發者建立應用程式或元件
· 包裝成可部署的元素
· 部署在應用伺服器平臺上
· 被終端使用者使用
· 在再次部署中由開發者更新特性或修補
· 應用程式達到使用壽命後期的時候收回
在很多情況下，它與"正常的"應用程式軟體的管理方式是不同的。這一點對於多層分散式軟體系統尤其突出(在這種情況下客戶端使用者與後端伺服器應用程式互動操作)。應用程式伺服器與多層軟體應用程式套件之間最主要的區別在於，應用伺服器提供了大量的軟體包裝支援。換句話說，應用伺服器為很多領域(例如執行緒管理、資料庫連線、網路訪問等等)提供了執行時(runtime)支援。應用伺服器中的這些設施都是自由使用的，但是在傳統的軟體套件中，它們一般要求人們手動編寫程式碼來實現。
簡單的說，應用伺服器有效地分割了主機平臺與應用程式軟體的業務邏輯。通過提供對軟體的大量支援，應用伺服器技術允許軟體設計者和開發者將精力集中在解決自己特定領域的問題上。適當地使用應用伺服器技術可以減少軟體開發的費用。
在上面的軟體生命週期中，我們把標準的應用伺服器工具(例如基於ant的工具)當作專用工具來使用。其它的一些與J2EE應用伺服器部分繫結的應用程式還包括：
· 管理控制檯
· 部署工具
· 除錯工具
· J2EE相容性檢測程式
管理控制檯用於管理應用伺服器上執行的軟體，例如啟用/不啟用、列舉元件等等。部署工具用於為應用伺服器環境準備軟體。除錯工具用於輔助解決那些發生的問題。J2EE相容性檢查對於新軟體的作者來說是非常重要的，因為J2EE元件與標準的Java類是不同的。
Sun的文件表明應用伺服器軟體產品的生產事務是可以在專家之間進行分工的。程式設計師編寫和測試原始碼，接著把這些原始碼傳遞給部署人員。部署人員準備幷包裝軟體供我們在應用伺服器上使用。在這個時候，軟體可能被傳遞迴程式設計師以供除錯和整合測試。另一組專家可以檢測該軟體的J2EE相容性。其要點是一個或多個稱職人員可以執行這麼多不同的複雜的事務。
資料集中管理器對應用伺服器下執行的應用程式擁有更大的控制權。這意味著企業中執行的軟體可以在同一個平臺上集中地管理和部署。在某些方面，應用伺服器技術使我們"後退"到了大型機時代的軟體部署情形。反對的觀點認為這種模型使客戶端不需要寄宿和執行大量的程式碼，但是在客戶端上執行比在一個或多個應用伺服器上執行的效率更高;同樣，由於頻寬的迅速擴大，頻寬的約束力也逐步縮小。
第三種武器 技術傳承——應用伺服器是基於元件的
J2EE應用程式遵循廣泛採用的面向元件的方法。它們被分割成執行在客戶端或伺服器上的應用程式。客戶端寄宿應用程式和applets，伺服器寄宿Java小伺服器程式、JavaServer頁面和企業級JavaBean(EJB)技術。
可以在應用伺服器上部署的主要的元件檔案型別有：Web檔案檔案(WAR)和企業級jar(EAR)檔案。客戶端應用程式都被打包成JAR檔案。我們可以把元件準備好，在Sun應用伺服器上部署它，而大多數準備工作是在嚮導的幫助下或使用工具(例如部署工具、asant和管理控制檯等等)來自動地完成的。
應用伺服器技術的面向元件的特性與軟體工程文化的趨勢是一致的。有趣的是，軟體架構的'演化在描述給定架構的軟體元素的時候趨向於不使用元件這個單詞。作為代替的是，在某個元件不僅僅是執行時實體的時候，推薦使用元素來描述它。應用伺服器技術是否需要更多的架構細節也是很有意思的。
第四種武器 團隊工作——應用伺服器提供了軟體協同工作的能力
J2EE的根基之一是XML，它日益成為粘合各種應用程式的"膠水"。在網路管理領域，由於XML允許我們簡單地定義服務並把它們轉換為軟體，從而顯得光芒耀眼。XML作為改善軟體(特別是寄宿在應用伺服器上的軟體)之間協同工作能力的一種途徑，其重要性還會不斷增加。
J2EE還提供了對資料庫事務的支援。使用ATM取錢就是事務的一個例子。如果在事務的過程中出現電力中斷或網路故障，你不希望帳號多次記入貸方，除非你中了彩 票(哈哈)。因此，事務支援是應用伺服器基礎構造的一個重要的元素，它在J2EE中佔據著重要的位置。
第五種武器 想象力——應用伺服器是高度抽象的
我經常在想，軟體從業人員提升價值鏈的最好辦法就是使用抽象事務。我們不是在分散的和有限的事務上孤獨地工作，而是找出不太明確的抽象事務。抽象事務的例子包括建立儲存備份策略、定義某個重要的應用程式特性的需求等等。
抽象事務是很大的挑戰，它強迫大腦分而治之。應用伺服器為執行在它上面的軟體使用了一個相當抽象的模型。例如，J2EE允許你的軟體訪問後臺的資料庫，用這種方法提供了抽象的支援。它同時還考慮資源情況，隱藏了特定資料來源的複雜性。
第六種武器 獨立性——J2EE與Sun的應用伺服器是獨立的、截然不同的
這是一個很基本的觀點：J2EE本質上是一個高階的API，但是它的確包含了一些在應用伺服器環境之外執行部件。其中一個例子是XSLT，它允許我們把傳統的資料轉換為XML，反之亦然。
J2EE的重要性還在持續增長;有些軟體架構專家甚至於把J2EE作為21世紀軟體工程文化首要的改造部分。它與環球網在90年代改變軟體工程文化的情況類似--這也是花費精力瞭解J2EE和相關技術的另一個原因。更深一層的原因是微軟和Sun目前在讓它們的產品協同工作方面積極地合作。
第七種武器 發展——應用伺服器：軟體未來之窗
應用伺服器對企業中的軟體集中執行的能力是強大的、引人注目的。它可能使IT業對已部署的軟體的控制能力提高了一個很高的層次。當主要的軟體元件基於應用伺服器的時候，我們可以應用體系結構方面的品質屬性，例如安全性、可修改性和可靠性。
這樣，J2EE和應用伺服器技術無疑會成為軟體未來的橋樑。它還符合軟體架構專家和麵向服務的架構典型。
結論
不要害怕應用伺服器技術!即使很便宜的PC也可以寄宿高階的軟體套件(例如Sun的J2EE和它的應用伺服器產品)。當然你也可以使用開放原始碼的。其要點是這種技術越來越流行，同時越來越易於使用。
通過使用這種技術，你將瞭解軟體工程文化的發展趨勢，並會看到某些重要工作的產物。每個人都在談論Web服務，但是都沒有使用和建立自己的例子那麼全面。即使企業級JavaBeans、Servlets和其它的J2EE技術也是如此。使用J2EE免費評估版本或類似的產品可以很容易地實現所有這些事務。
