Java EE啟示錄

前言

??? 最近的這段時間一直在學習Java EE，剛剛完成了從0到1的蛻變，所以順便整理一下我所了解到的Java EE，給剛入門學習的新人一些頭緒，而所謂“啟示錄”，就是這個意思。

一.Java EE是什么？

?? Java EE（Java Enterprise Edition）是一種企業級應用的軟件架構，同時是一種思想，一套規范。

二.Java EE的發展史

histroy

??? Java Enterprise Edition的發展不知不覺已經12年了，不知道大家有沒留意，一開始，Java Enterprise Edition簡稱“J2EE”，直到版本5才改名為Java EE，而現在最新的版本則是Java EE 6。

??? 到這里，或許有人會問，為什么會有這么多套Java EE規范？這些版本的差別是什么？

1.J2EE1.2的出現，主要是將之前各個單獨的規范綁定到一起。

2.J2EE1.3，則是繼續完善J2EE體系結構。

3.J2EE1.4，主要是加入了一個重要主題：Web Service

4.而Java EE 5，主題則是“簡化”，簡化之前復雜的J2EE思想，改善開發體驗。

三.Java EE到底要解決什么問題？

1.Java EE解決什么問題？

??? 從Java EE發展背景看，它與“分布式應用”以及“互聯網應用”的關系密不可分，而這兩者也正是Java EE要解決的問題！

??? 其實，分布式應用隨著90年代互聯網的興起逐漸開始普及。在90年代中，各種分布式應用標準逐漸誕生，如：OMG的CORBA，MS的DCOM等，而Sun在推出Java的RMI（Remote Method Invocation）后，便以RMI作為通信基礎構建了Java EE。我認為，Java EE最核心要解決的問題就是“分布式應用”。而在接下來的競爭中，Java EE也不負所托，逐漸取代了CORBA，DCOM的地位。

2.分布式應用與RPC

??? RPC（Remote Procedure Call），在聊到分布式應用時很多人會第一時間想到它。所謂RPC，就是遠程調用一個服務，但效果和本地調用一樣。在最初的時候，RPC很類似C語言的函數調用，但隨著編程語言和技術的發展，特別是面向對象和面向組件技術的廣泛應用，便出現了“遠程對象/方法調用”。所謂“遠程對象/方法調用”其實就是把調用遠程對象和本地對象的區別隱藏起來，讓調用者可以像使用本地對象那樣調用遠程對象。從本質上說，最初的RPC和后來的“遠程對象/方法調用”稍有不同，在“遠程對象/方法調用”中，被調的服務還需要考慮如：對象生命周期管理，事務處理……這些問題。但籠統地說，最初的RPC和“遠程對象/方法調用”都稱為：RPC，所以之前提到的如：DCOM，CORBA，JAVA的RMI，.NET的Remoting都稱為RPC。而我認為，RPC的本質就是：應用協議 + 傳輸協議。而各種不同的RPC實現之間的區別亦在此。

??? 而所謂的“分布式應用”，實際上可以說是用RPC方式，把各個分布在不同機器的應用模塊聯合成一個系統。可以說RPC是“分布式應用”的基礎，所以就有“以RMI作為通信基礎構建了Java EE”這一說了：>

四.Java EE體系結構

??? 這里，我打算從分析“企業級應用”入手，并藉此逐步建立整個Java EE體系。

1.概述Java EE體系結構

???? 為了有印象，我們先來個最簡單Java EE架構圖看看：

arch_2

從上圖看到，Java EE一般分為4層：

（1）客戶端

（2）web層

（3）業務邏輯層

（4）企業信息層（EIS：Enterprise Information System）

??? 呵呵，不要以為Java EE只是描述服務端規范，實際上，它還是包含了一些客戶端相關東東，比如：Applet...不過，Java EE的重點還是在服務端這方面，而本文重點也是介紹Java EE在服務端這方面的內容。

2.“企業級應用”分析

（1）分布式應用

??? 首先從總的來看，一個“企業級應用”代表著，這個系統肯定是“非常大型的”，這么大型的系統，這么多的應用，是不可能把應用都部署在一臺機器上的，所以“分布式應用”這個需求便順理成章地出現。理想的“企業級應用”中，各種功能模塊應該分布在不同的機器上，在需要某功能的時候，我們可以動態地進行調用。

（2）系統分層

??? 企業應用中，業務的功能會非常復雜。此時，模塊間的解耦以及系統的分層開始顯得重要，解耦與分層會使得系統結構清晰，并且健壯。而傳統的分層模式是一般是：接入層，邏輯層，數據層。

（3）異步

??? 設計分布式應用時，你遇到的第一個問題就是：等待…..在企業級應用中，業務的處理時復雜的。如果把子模塊部署到不同機器后，要處理一個業務，很可能需要到多臺機器上進行調用；另外，子模塊的運算也需要一定的時間，此時，“等待”就出現了。由于你無法預計這個復雜的業務什么時候才能處理完，所以，“異步”這個概念也順理成章地被引入。（其實，這也體現了軟件設計中“快慢分離”的原則）

（4）事務，安全

??? 關于事務的重要性這里就不多說了。

??? 而安全，一般指對某個模塊的授權，身份驗證等等，在企業級應用中，安全絕對是重要的一塊。

（5）Java EE平臺與其他已有資源、服務、系統的整合

??? 在Java EE出來之前，很多公司很可能已經建立了比較完善的企業信息系統（EIS），顯然，和這些已有的系統整合，在企業級應用中顯得尤為重要。

3.Java EE體系結構詳述

??? OK，現在讓我們來逐步了解，Java EE每個部件的作用吧。

（1）Servlet，JSP

??? JSP，Servlet同屬“web層”，并都屬于“動態網頁技術”。所謂“動態網頁技術”和傳統的“靜態網頁技術”不一樣，傳統的“靜態網頁技術”說白就是把做好的html文件直接上傳到服務器并直接供客戶瀏覽，而“動態網頁技術”則是每次都根據用戶請求，動態生成響應頁面并返回。“動態網頁技術”的好處不言自明，無論從靈活性，數據保密性…等方面說都是“靜態網頁”所無法媲美的。但“動態網頁技術”也是有缺點的，就是相對較慢，現在的解決方案一般是：把“動態網頁”中相對固定的部分做緩存，即所謂“靜態頁面”。（額.…..“靜態網頁”和“靜態頁面”本質上沒什么區別，都是靜態頁面，但思想上卻有很大區別。而現在的程序員一般會對“靜態”這個詞賦予一個新的含義：“緩存”）

【1】Servlet

??? Servlet實際上就是按照Servlet規范編寫的一個java類，與傳統的命令行啟動的Java應用程序不同，Servlet位于Web服務器內部，并由Web服務器加載并調用。

【2】JSP

??? JSP全稱是：JavaServer Page。這項技術的推出目的其實很簡單，為了彌補Servlet一個很重要的缺陷：“麻煩”。

??? 先看看Servlet到底什么地方讓人覺得麻煩，下面是一個Servlet處理Get請求例子：

從上面這個例子，相信大家已經發現問題了，Servlet主要是把動態內容混合到靜態內容中以產生html，這導致Servlet代碼中將會輸出大量的html標識，哇，地獄，簡直就是地獄，同時，這也非常不利于程序員和UI美工的配合（不要指望美工人員會和你一起寫html標識）。為了解決這些問題，JSP誕生了。

??? JSP是一種建立在Servlet規范之上的動態網頁技術，通常做法是：在html頁面中嵌入JSP標記和腳本代碼。JSP把靜態內容和動態內容的分離，實現了內容和表示的分離。

【3】Servlet與JSP的關系

??? 上圖描述得比較清楚了，JSP文件先是轉換為Servlet類，然后編譯，并啟動Servlet實例響應客戶端請求。為什么說JSP是建立在Servlet上的動態網頁技術，從這里可以看出來。

??? Web層主要就是JSP以及Sevlet這兩項技術。

arch_2_1

（2）EJB（Enterprise JavaBean）

??? 之前說過，分布式應用是Java EE一個基礎的需求，額……那在不同機器上的“分布式”的應用到底會以一個什么樣的形態出現呢？答案就是：EJB。EJB屬于業務邏輯層上的東東。

??? 所謂Bean，其實是“組件”的意思。EJB可以讓你像搭積木一樣，通過本地/分布式調用組裝不同應用到大型應用中，使你能集中精力來處理企業的業務邏輯，而像事務、網絡、安全等等這些底層服務則統統留給EJB服務器開發商來解決。

??? 利用基于組件的開發，可以把代碼重用上升到一個新的高度。利用面向對象開發，重用的是類，而基于組件時，重用的則是更大的功能塊。

????【1】EJB vs Java Bean

??? 我個人認為，Java Bean相當于是數據存儲類（不涉及具體業務邏輯），專門用來存數數據，提供getter，setter方法，并且在JVM上可直接運行。EJB則相當于一個功能模塊，提供業務邏輯的服務，而運行時，則需要EJB容器的幫助。

??? EJB是業務邏輯層最重要的技術哦！

arch_2_2

（3）Container（容器）

??? Container這個概念經常在Java EE中出現，所謂Container，在Java EE 5 Tutorial中有這樣一段解釋：“Containers?are the interface between a component and the low-level platform-specific functionality that supports the component.”，而Container的作用，我個人的認為是：為“應用程序”提供一個環境，使其可以不必須關注某些問題，如：系統環境變量，事務，生命周期…….通俗地說，Container就像“秘書”，幫“應用程序”管理著各種雜亂的問題，為其提供運行時支持。

??? 其中，Java EE里有兩個很重要的容器：Web容器和EJB容器

【1】Web容器

??? Web容器是用于托管“Web應用程序”的J2EE容器，主要負責管理“Servlet”和“JSP”運行。

WebContainer

【2】Servlet容器

??? 其實，上圖中的Servlet指的就是Servlet容器。而Servlet的設計初衷，實際是基于線程池的更好的線程容器，見下圖：

servletContainer ?

【3】EJB容器

???? EJB容器主要負責管理“EJB”的運行。

??? 而EJB的設計實際上是基于對象池的思想，你可以認為EJB=對象池+遠程對象池。見下圖：

ejbContainer

【4】Servlet與EJB

??? 其實，根據Servlet和EJB的設計初衷，我們已經可以看出Java EE對兩者角色的定義了。線程的本質決定了Servlet只適合一些比較簡單的輕量級應用；一旦問題復雜了，最好的就是使用EJB。

（4）RMI

??? RMI全稱：Java Remote Method Invocation，就是利用Java對象序列化的機制，實現遠程類對象的實例化以及調用的方法。

??? RMI在Java EE中的主要是負責解決通信問題，特別是不同的EJB容器之間的通信。大家知道，在分布式應用中，各個功能模塊（EJB）之間通信需要有統一的RPC協議，否則沒法通信，而RMI就是負責這方面的工作。

【1】RMI 與 CORB

??? 可以說，RMI就是CORBA的Java版實現。

【2】再談“遠程調用”

??? 現在主流的遠程調用方式，不管是com/com+，soap，webservice，rmi，.net remoting，說白了都一樣的，就是序列化，網絡傳輸，反序列化。

??? 序列化方式：同種runtime的，可以native的二進制序列化，序列化的效率高。文本的序列化（xml/json/自定義格式）的方式，可以跨平臺和語言，一般基于中間類型。但此序列化方式的效率低，數據量也偏大。

??? 網絡傳輸：則可以使socket/http或是自定義協議的。 socket數據冗余最小，效率最高。RMI其實是socket上的自定義協議。 http要走http的報文，文本的方式最合適，實現最簡單，開發和部署方便。

（5）JMS

??? JMS：Java Message Service。JMS提供一種消息機制，主要作用是提供異步通信的支持，是Java EE的重要基礎模塊。值得注意，異步通信，一般都采用消息機制，這種情況在Windows中最常見。

（6）JTA

??? JTA：Java Transaction API，主要提供事務服務和分布式事務管理功能，保證分布式事務的一致性，是Java EE的重要的基礎模塊。

（7）JAAS

??? JAAS：Java Authentication Authorization Service（Java認證于授權服務），提供了對Java組件的安全保護，如哪些Servelt，JSP能被哪些用戶訪問，哪些EJB能被調用等。但需要注意的是，JAAS只提供了對JAVAEE組件的保護，對于企業應用業務的權限，它是做不到的。

（8）Connector

??? Connector主要作用就是把其他已有的資源、服務、系統整合到Java EE系統中。不同的服務提供商和Java EE平臺會定義不同的協議，而Connector就是指這些協議的實現。

??? 至此為止，Java EE的核心模塊介紹完畢，讓我們來看看J2EE 1.3的架構圖（當時的J2EE架構還是比較簡單的）：

JAVAEE1.3