j2ee購物車

7. 京東購物車是怎麼實現的用什麼保存的 實現購物車有沒有什麼好的建議

選好商品直接加入購物車啊，最後才一起結算。購物網站上都有的功能。

8. J2EE開發中的MVC框架指的是什麼啊

MVC是一個設計模式，它強制性的使應用程序的輸入、處理和輸出分開。使用MVC應用程序被分成三個核心部件：模型、視圖、控制器。它們各自處理自己的任務。

視圖
視圖是用戶看到並與之交互的界面。對老式的Web應用程序來說，視圖就是由HTML元素組成的界面，在新式的Web應用程序中，HTML依舊在視圖中扮演著重要的角色，但一些新的技術已層出不窮，它們包括Macromedia Flash和象XHTML，XML/XSL，WML等一些標識語言和Web services.

如何處理應用程序的界面變得越來越有挑戰性。MVC一個大的好處是它能為你的應用程序處理很多不同的視圖。在視圖中其實沒有真正的處理發生，不管這些數據是聯機存儲的還是一個雇員列表，作為視圖來講，它只是作為一種輸出數據並允許用戶操縱的方式。

模型
模型表示企業數據和業務規則。在MVC的三個部件中，模型擁有最多的處理任務。例如它可能用象EJBs和ColdFusion Components這樣的構件對象來處理資料庫。被模型返回的數據是中立的，就是說模型與數據格式無關，這樣一個模型能為多個視圖提供數據。由於應用於模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重復性。

控制器
控制器接受用戶的輸入並調用模型和視圖去完成用戶的需求。所以當單擊Web頁面中的超鏈接和發送HTML表單時，控制器本身不輸出任何東西和做任何處理。它只是接收請求並決定調用哪個模型構件去處理請求，然後用確定用哪個視圖來顯示模型處理返回的數據。

現在我們總結MVC的處理過程，首先控制器接收用戶的請求，並決定應該調用哪個模型來進行處理，然後模型用業務邏輯來處理用戶的請求並返回數據，最後控制器用相應的視圖格式化模型返回的數據，並通過表示層呈現給用戶。

為什麼要使用 MVC

大部分Web應用程序都是用像ASP，PHP，或者CFML這樣的過程化語言來創建的。它們將像資料庫查詢語句這樣的數據層代碼和像HTML這樣的表示層代碼混在一起。經驗比較豐富的開發者會將數據從表示層分離開來，但這通常不是很容易做到的，它需要精心的計劃和不斷的嘗試。MVC從根本上強制性的將它們分開。盡管構造MVC應用程序需要一些額外的工作，但是它給我們帶來的好處是無庸質疑的。

首先，最重要的一點是多個視圖能共享一個模型，正如我所提及的，現在需要用越來越多的方式來訪問你的應用程序。對此，其中一個解決之道是使用MVC，無論你的用戶想要Flash界面或是 WAP 界面；用一個模型就能處理它們。由於你已經將數據和業務規則從表示層分開，所以你可以最大化的重用你的代碼了。

由於模型返回的數據沒有進行格式化，所以同樣的構件能被不同界面使用。例如，很多數據可能用HTML來表示，但是它們也有可能要用Macromedia Flash和WAP來表示。模型也有狀態管理和數據持久性處理的功能，例如，基於會話的購物車和電子商務過程也能被Flash網站或者無線聯網的應用程序所重用。

因為模型是自包含的，並且與控制器和視圖相分離，所以很容易改變你的應用程序的數據層和業務規則。如果你想把你的資料庫從MySQL移植到Oracle，或者改變你的基於RDBMS數據源到LDAP，只需改變你的模型即可。一旦你正確的實現了模型，不管你的數據來自資料庫或是LDAP伺服器，視圖將會正確的顯示它們。由於運用MVC的應用程序的三個部件是相互對立，改變其中一個不會影響其它兩個，所以依據這種設計思想你能構造良好的松偶合的構件。

對我來說，控制器的也提供了一個好處，就是可以使用控制器來聯接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據用戶的需求選擇模型進行處理，然後選擇視圖將處理結果顯示給用戶。

MVC的缺點
MVC的缺點是由於它沒有明確的定義，所以完全理解MVC並不是很容易。使用MVC需要精心的計劃，由於它的內部原理比較復雜，所以需要花費一些時間去思考。

你將不得不花費相當可觀的時間去考慮如何將MVC運用到你的應用程序，同時由於模型和視圖要嚴格的分離，這樣也給調試應用程序到來了一定的困難。每個構件在使用之前都需要經過徹底的測試。一旦你的構件經過了測試，你就可以毫無顧忌的重用它們了。

根據我個人經驗，由於我們將一個應用程序分成了三個部件，所以使用MVC同時也意味著你將要管理比以前更多的文件，這一點是顯而易見的。這樣好像我們的工作量增加了，但是請記住這比起它所能帶給我們的好處是不值一提。

MVC並不適合小型甚至中等規模的應用程序，花費大量時間將MVC應用到規模並不是很大的應用程序通常會得不償失。

MVC是一條創建軟體的好途徑
MVC設計模式是一個很好創建軟體的途徑，它所提倡的一些原則，像內容和顯示互相分離可能比較好理解。但是如果你要隔離模型、視圖和控制器的構件，你可能需要重新思考你的應用程序，尤其是應用程序的構架方面。如果你肯接受MVC，並且有能力應付它所帶來的額外的工作和復雜性，MVC將會使你的軟體在健壯性，代碼重用和結構方面上一個新的台階。

Java開發Web Application有幾種符合MVC設計模式的開發方式。

1:Jsp+Servlet+JavaBean(EJB)

2:Jsp+JavaBean(Controller)+JavaBean(EJB)(Model)

3:TDK(Turbine，Velocity...)

4:Xsp

5:Jsp+Struts+JavaBean(EJB)

9. j2ee的核心技術

為了聯系實際，GOULD基於WEBLOGIC應用伺服器（來自BEASYSTEMS公司的一種廣為應用的產品）環境來介紹J2EE的這些技術。JAVA最初是在瀏覽器和客戶端機器中閃亮登場的。當時，很多人質疑它是否適合做伺服器端的開發。隨著對JAVA2平台企業版（J2EE）第三方支持的增多，JAVA被廣泛接納為開發企業級伺服器端解決方案的首選平台之一。
J2EE平台由一整套服務（SERVICES）、應用程序介面（APIS）和協議構成，它對開發基於WEB的多層應用提供了功能支持。在本文中我將解釋支撐J2EE的13種核心技術：JDBC,JNDI,EJBS,RMI,JSP,JAVA SERVLETS,XML,JMS,JAVA IDL,JTS,JTA,JAVA MAIL 和 JAF，同時還將描述在何時、何處需要使用這些技術。當然，我還要介紹這些不同的技術之間是如何交互的。此外，為了讓您更好地感受J2EE的真實應用，我將在WEBLOGIC應用伺服器（來自BEA SYSTEMS公司的一種廣為應用的產品）環境下來介紹這些技術。不論對於WEBLOGIC應用伺服器和J2EE的新手，還是那些想了解J2EE能帶來什麼好處的項目管理者和系統分析員，相信本文一定很有參考價值。
宏觀印象： 分布式結構和J2EE
過去，二層化應用--通常被稱為CLIENT/SERVER應用--是大家談論的最多的。在很多情況下，伺服器提供的唯一服務就是資料庫服務。在這種解決方案中，客戶端程序負責數據訪問、實現業務邏輯、用合適的樣式顯示結果、彈出預設的用戶界面、接受用戶輸入等。CLIENT/SERVER結構通常在第一次部署的時候比較容易，但難於升級或改進，而且經常基於某種專有的協議（通常是某種資料庫協議）。它使得重用業務邏輯和界面邏輯非常困難。更重要的是，在WEB時代，二層化應用通常不能體現出很好的伸縮性，因而很難適應INTERNET的要求。
SUN設計J2EE的部分起因就是想解決二層化結構的缺陷。於是J2EE定義了一套標准來簡化N層企業級應用的開發。它定義了一套標准化的組件，並為這些組件提供了完整的服務。J2EE還自動為應用程序處理了很多實現細節，如安全、多線程等。用J2EE開發N層應用包括將二層化結構中的不同層面切分成許多層。一個N層化應用A能夠為以下的每種服務提供一個分開的層：顯示：在一個典型的WEB應用中，客戶端機器上運行的瀏覽器負責實現用戶界面。
動態生成顯示： 盡管瀏覽器可以完成某些動態內容顯示，但為了兼容不同的瀏覽器，這些動態生成工作應該放在WEB伺服器端進行，使用JSP、SERVLETS，或者XML（標准通用標記語言下的一個子集可擴展標記語言）和XSL（可擴展樣式表語言）。
業務邏輯：業務邏輯適合用SESSION EJB（後面將介紹）來實現。
數據訪問：數據訪問適合用ENTITY EJB（後面將介紹）和JDBC來實現 。
後台系統集成： 後台系統的集成可能需要用到許多不同的技術，至於何種最佳需要根據後台系統的特徵而定。
您可能開始詫異：為什麼有這么多的層？事實上，多層方式可以使企業級應用具有很強的伸縮性，它允許每層專注於特定的角色。例如，讓WEB伺服器負責提供頁面，應用伺服器處理應用邏輯，而資料庫伺服器提供資料庫服務。
由於J2EE建立在JAVA2平台標准版（J2SE）的基礎上，所以具備了J2SE的所有優點和功能。包括「編寫一次，到處可用」的可移植性、通過JDBC訪問資料庫、同原有企業資源進行交互的CORBA技術以及一個經過驗證的安全模型。在這些基礎上，J2EE又增加了對EJB（企業級JAVA組件）、JAVA SERVLETS、JAVA伺服器頁面（JSPS）和XML（標准通用標記語言的子集）技術的支持。
分布式結構與WEBLOGIC應用伺服器
J2EE提供了一個框架--一套標准API--用於開發分布式結構的應用，這個框架的實際實現留給了第三方廠商。部分廠商只是專注於整個J2EE架構中的的特定組件，例如APACHE的TOMCAT提供了對JSP和SERVLETS的支持，BEA系統公司則通過其WEBLOGIC應用伺服器產品為整個 J2EE規范提供了一個較為完整的實現。
WEBLOGIC伺服器已使建立和部署伸縮性較好的分布式應用的過程大為簡化。WEBLOGIC和J2EE代理處理了大量常規的編程任務，包括提供事務服務、安全領域、可靠的消息、名字和目錄服務、資料庫訪問和連接池、線程池、負載平衡和容錯處理等。通過以一種標准、易用的方式提供這些公共服務，像WEBLOGIC伺服器這樣的產品造就了具有更好伸縮性和可維護性的應用系統，使其為大量的用戶提供了增長的可用性。
J2EE技術在接下來的部分里，我們將描述構成J2EE的各種技術，並且了解WEBLOGIC伺服器是如何在一個分布式應用中對它們進行支持的。最常用的J2EE技術應該是JDBC、JNDI、EJB、JSP和SERVLETS，對這些我們將作更仔細的考察。
JAVA DATABASE CONNECTIVITY (JDBC)
JDBC API以一種統一的方式來對各種各樣的資料庫進行存取。和ODBC一樣，JDBC為開發人員隱藏了不同資料庫的不同特性。另外，由於JDBC建立在JAVA的基礎上，因此還提供了資料庫存取的平台獨立性。
JDBC定義了4種不同的驅動程序，現分述如下：
類型 1: JDBC-ODBCBRIDGE
在JDBC出現的初期，JDBC-ODBC橋顯然是非常有實用意義的，通過JDBC-ODBC橋，開發人員可以使用JDBC來存取ODBC數據源。不足的是，他需要在客戶端安裝ODBC驅動程序，換句話說，必須安裝MICROSOFT WINDOWS的某個版本。使用這一類型你需要犧牲JDBC的平台獨立性。另外，ODBC驅動程序還需要具有客戶端的控制許可權。
類型 2: JDBC-NATIVE DRIVER BRIDGE
JDBC本地驅動程序橋提供了一種JDBC介面，它建立在本地資料庫驅動程序的頂層，而不需要使用ODBC。JDBC驅動程序將對資料庫的API從標準的JDBC調用轉換為本地調用。使用此類型需要犧牲JDBC的平台獨立性，還要求在客戶端安裝一些本地代碼。
類型 3: JDBC-NETWORK BRIDGE
JDBC網路橋驅動程序不再需要客戶端資料庫驅動程序。它使用網路上的中間伺服器來存取資料庫。這種應用使得以下技術的實現有了可能，這些技術包括負載 均衡、連接緩沖池和數據緩存等。由於第3種類型往往只需要相對更少的下載時間，具有平台獨立性，而且不需要在客戶端安裝並取得控制權，所以很適合於 INTERNET上的應用。
類型 4: PURE JAVA DRIVER
第4種類型通過使用一個純JAVA資料庫驅動程序來執行資料庫的直接訪問。此類型實際上在客戶端實現了2層結構。要在N-層結構中應用，一個更好的做法是編寫一個EJB，讓它包含存取代碼並提供一個對客戶端具有資料庫獨立性的服務。
WEBLOGIC伺服器為一些通常的資料庫提供了JDBC驅動程序，包括ORACLE,SYBASE,MICROSOFT SQLSERVER以及INFORMIX。它也帶有一種JDBC驅動程序用於CLOUDSCAPE，這是一種純JAVA的DBMS，WEBLOGIC伺服器中帶有該資料庫的評估版本。
以下讓我們看一個實例。
JDBC實例在這個例子中我們假定你已經在CLOUDSCAPE中建立了一個PHONEBOOK資料庫，並且包含一個表，名為CONTACT_TABLE ，它帶有2個欄位：NAME 和 PHONE。開始的時候先裝載CLOUDSCAPE JDBC DRIVER，並請求DRIVER MANAGER得到一個對PHONEBOOK CLOUDSCAPE資料庫的連接。通過這一連接，我們可以構造一個STATEMENT 對象並用它來執行一個簡單的SQL查詢。最後，用循環來遍歷結果集的所有數據，並用標准輸出將NAME和PHONE欄位的內容進行輸出。 importjava.sql.*;publicclassjdbcexample{publicstaticvoidmain(stringargs[]){try{class.forname("com.cloudscape.core.jdbcdriver");connectionconn=drivermanager.getconnection("jdbc:cloudscape:phonebook");statementstmt=conn.createstatement();stringsql="selectname,phonefromcontact_tableorderbyname";resultsetresultset=stmt.executequery(sql);stringname;stringphone;while(resultset.next()){name=resultset.getstring(1).trim();phone=resultset.getstring(2).trim();system.out.println(name+","+phone);}}catch(exceptione){//handleexceptionheree.printstacktrace();}}}OK。接著我們來看一看JDBC是如何在企業應用中的進行使用。JDBC在企業級應用中的應用以上實例其實是很基本的，可能有些微不足道。它假定了一個2層結構。在一個多層的企業級應用中，更大的可能是在客戶端和一個EJB進行通信，該EJB將建立資料庫連接。為了實現和改進可伸縮性和系統性能，WEBLOGIC伺服器提供了對連接緩沖池CONNECTION POOL的支持。CONNECTION POOL減少了建立和釋放資料庫連接的消耗。在系統啟動以後即可建立這樣的緩沖池，此後如故再有對資料庫的請求，WEBLOGIC伺服器可以很簡單地從緩 沖池中取出數據。數據緩沖池可以在WEBLOGIC伺服器的WEBLOGIC.PROPERTIES 文件中進行定義。（可參考 WEBLOGIC.PROPERTIES 文件中的例子，WEBLOGIC伺服器的文檔中還有更詳細的參考信息）在企業級應用的另一 個常見的資料庫特性是事務處理。事務是一組申明STATEMENT，它們必須做為同一個STATEMENT來處理以保證數據完整性。預設情況下JDBC使 用 AUTO-COMMIT 事務模式。這可以通過使用CONNECTION類的 SETAUTOCOMMIT() 方法來實現。
現在我們已經對JDBC有了一些認識，下面該轉向JNDI了。
JAVA NAMING AND DIRECTORY INTERFACE (JNDI)
JNDI API被用於執行名字和目錄服務。它提供了一致的模型來存取和操作企業級的資源如DNS和LDAP，本地文件系統，後者在應用伺服器中的對象。
在JNDI中，在目錄結構中的每一個結點稱為CONTEXT。每一個JNDI名字都是相對於CONTEXT的。這里沒有絕對名字的概念存在。對一個應用來說，它可以通過使用 INITIALCONTEXT 類來得到其第一個CONTEXT:
CONTEXT CTX = NEW INITIALCONTEXT();
應用可以通過這個初始化的CONTEXT經有這個目錄樹來定位它所需要的資源或對象。例如，假設你在WEBLOGIC伺服器中展開了一個EJB並將 HOME介面綁定到名字 MYAPP.MYEJB ，那麼該EJB的某個客戶在取得一個初始化
CONTEXT以後，可以通過以下語句定位HOME介面：
MYEJBHOME HOME = CTX.LOOKUP( "MYAPP.MYEJB" );
在這個例子中，一旦你有了對被請求對象的參考，EJB的HOME介面就可以在它上面調用方法。我們將在下面的"ENTERPRISE JAVA BEANS"章節中做更多的介紹。
以上關於JNDI的討論只是冰山之一角而已。如果要更進一步地在CONTEXT中查找對象，JNDI也提供了一些方法來進行以下操作：
將一個對象插入或綁定到CONTEXT。這在你展開一個EJB的時候是很有效的。
從CONTEXT中移去對象。
列出CONTEXT中的所有對象。
創建或刪除子一級的CONTEXT。
接下來，我們要開始關注EJB了。
ENTERPRISE JAVA BEANS (EJB)
J2EE技術之所以贏得某體廣泛重視的原因之一就是EJB。它們提供了一個框架來開發和實施分布式商務邏輯，由此很顯著地簡化了具有可伸縮性和高度復雜的企業級應用的開發。EJB規范定義了EJB組件在何時以及如何與它們的容器進行交互作用。容器負責提供公用的服務，例如目錄服務、事務管理、安全性、資源緩沖池以及容錯性。
EJB規范定義了3中基本的BEAN類型：
STATELESS SESSION BEANS: 提供某種單一的服務，不維持任何狀態，在伺服器故障發生時無法繼續存在，生命期相對較短。例如，一個STATELESS SESSION BEAN可能被用於執行溫度轉換計算。
STATEFUL SESSION BEAN: 提供了與客戶端的會話交互，可以存儲狀態從而代表一個客戶。典型例子是購物車。STATEFUL SESSION BEAN在伺服器故障時無法繼續生存，生命期相對較短。每一個實例只用於一個單個的線程
ENTITY BEANS: 提供了一致性數據的表示-- 通常存放在資料庫中 -- 在伺服器故障發生後能繼續存在。多用戶情況下可以使用EJB來表示相同的數據。ENTITY EJB的一個典型例子是客戶的帳號信息。
盡管有以上的區別，所有的EJB還是有許多的共同之處：
它們都處理HOME INTERFACE。它定義了一個客戶端是如何創建與消亡EJB的。
可以在BEAN中對定義了客戶端方法的遠程介面進行調用；
BEAN類則執行了主要的商務邏輯描述
EJB的開發已經超出了本文的范圍。但是，如果一個EJB已經被開發了或者從第三方進行了購買，它就必須在應用伺服器中進行發布。WEBLOGIC SERVER 5.1帶有一個EJB DEPLOYER TOOL來協助處理EJB的發布。當你使用EJB DEPLOYER TOOL的時候，你要定義客戶端所用的JNDI名字來定位EJB。DEPLOYER TOOL將生成WRAPPER類來處理和容器的通信以及在一個JAR文件中把被請求的JAVA類綁定在一起。一旦EJB被發布，客戶端就可以使用它的JNDI名字來定位EJB。
首先，它必須得到一個到HOME介面的REFERENCE。
然後，客戶端可以使用該介面，調用一個 CREATE() 方法來得到伺服器上運行的某個BEAN實例的句柄；
最後，客戶端可以使用該句柄在BEAN中調用方法。
了解 EJB後，讓我們再來看JSP。
JAVA SERVER PAGES (JSPS)
我們中間可能已經有許多人已經熟悉MICROSOFT的ACTIVE SERVER PAGES (ASP）技術了。JSP和ASP相對應的，但更具有平台對立性。他們被設計用以幫助WEB內容開發人員創建動態網頁，並且只需要相對較少的代碼。即使WEB設計師不懂得如何編程也可以使用JSP，因為JSP應用是很方便的。JSP頁面由HTML（標准通用標記語言下的一個應用）代碼和嵌入其中的JAVA代碼所組成。伺服器在頁面被客戶端所請求以後對這些JAVA代碼進行處理，然後將生成的HTML頁面返回給客戶端的瀏覽器。
下面我們來看一個JSP的簡單實例。它只顯示了伺服器的當前日期和時間。雖然，對語法的具體解釋已經超出了本文的范圍，但我們還是可以很直觀地看到，JAVA代碼被放在<%和%>；的中間，而JAVA的表達式則放在<%=和%>；之間。 <html><head><title>SampleJSPPage</title></head><body><h1>DateJSPsample</h1><%response.setHeader("Refresh",5);%>Thecurrentdateis<%=newDate()%>.</body></html>您可能有時候聽說過JHTML。這是JSP以前的一種較老的標准。WEBLOGIC伺服器既可支持JSP，又可支持JHTML。
請注意，在預設狀況下，JSP在WEBLOGIC伺服器中並沒有處於有效狀態。要使之有效，你可以編輯WEBLOGIC.PROPERTIES文件。如果WEB伺服器還沒有處於有效狀態，則要先使之有效。SERVLET的情況和JSP是一樣的。
下面是：JAVA SERVLETS
JAVA SERVLETS
SERVLET提供的功能大多與JSP類似，不過實現的方式不同。JSP通常是大多數HTML代碼中嵌入少量的JAVA代碼，而SERVLETS全部由JAVA寫成並且生成HTML。
SERVLET是一種小型的JAVA程序，它擴展了WEB伺服器的功能。作為一種伺服器端的應用，當被請求時開始執行，這和CGI PERL腳本很相似。SERVLETS和CGI腳本的一個很大的區別是：每一個CGI在開始的時候都要求開始一個新的進程 -- 而SERVLETS是在SERVLET引擎中以分離的線程來運行的。因此SERVLETS在可伸縮性上提供了很好的改進。在開發SERVLETS的時候，您常常需要擴展JAVA X.SERVLET.HTTP.HTTPSERVLET 類，並且OVERRIDE一些它的方法，其中包括：
SERVICE(): 作為DISPATCHER來實現命令-定義方法
DOGET(): 處理客戶端的HTTP GET請求。
DOPOST(): 進行HTTP POST操作
其它的方法還包括處理不同類型的HTTP請求-- 可以參考HTTPSERVLET API文檔。
以上描述的是標准J2EE SERVLET API的各種方法。WEBLOGIC伺服器提供了一個該API完整的實現途徑。一旦你開發了一個SERVLET，你就可以在 WEBLOGIC.PROPERTIES 中加以注冊並由此可以在WEBLOGIC伺服器中對它進行配置。通過JAVA SERVLETS，我們已經到達了J2EE主要技術的末尾了。但J2EE所提供的並不止於這些。
下面的段落中我們將簡要地看一下現存的一些技術，包括RMI,JAVA IDL和CORBA,JTA，以及XML（標准通用標記語言的子集），等等。
REMOTE METHOD INVOCATION (RMI)
正如其名字所表示的那樣，RMI協議是在遠程對象上調用一些方法。它使用了連續序列方式在客戶端和伺服器端傳遞數據。RMI是一種被EJB使用的更下層的協議。
JAVA IDL/CORBA
在JAVA IDL的支持下，開發人員可以將JAVA和CORBA集成在一起。他們可以創建JAVA對象並使之可在CORBA ORB中展開，或者他們還可以創建JAVA類並作為和其它ORB一起展開的CORBA對象的客戶。後一種方法提供了另外一種途徑，通過它JAVA可以被用於將你的新的應 用和LEGACY系統相集成。
JAVA TRANSACTION ARCHITECTURE (JTA)/JAVA TRANSACTION SERVICE (JTS)
JTA定義了一種標準的API，應用系統由此可以存取各種事務監控。
JTS是CORBA OTS事務監控的基本實現。JTS規定了事務管理器的實現方式。該事務管理器是在高層支持JAVA TRANSACTION API (JTA）規范，並且在較底層實現OMG OTS SPECIFICATION的JAVA映像。JTS事務管理器為應用伺服器、資源管理器、獨立的應用以及通信資源管理器提供了事務服務。
JAVA MAIL AND JAVA BEANS ACTIVATION FRAMEWORK
JAVA MAIL是用於存取郵件伺服器的API，它提供了一套郵件伺服器的抽象類。不僅支持SMTP伺服器，也支持IMAP伺服器JAVA MAIL利用JAVA BEANS ACTIVATION FRAMEWORK (JAF）來處理MIME-編碼的郵件附件。MIME的位元組流可以被轉換成JAVA對象，或者轉換自JAVA對象。由此大多數應用都可以不需要直接使用JAF。
JAVA MESSAGING SERVICE (JMS)
JMS是用於和面向消息的中間件相互通信的應用程序介面（API）。它既支持點對點的域，又支持發布/訂閱（PUBLISH/SUBSCRIBE）類型的域，並且提供對下列類型的支持：經認可的消息傳遞、事務型消息的傳遞、一致性消息和具有持久性的訂閱者支持。JMS還提供了另一種方式來對您的應用與LEGACY BACKEND系統相集成。
XML（標准通用標記語言的子集）
XML是一種可以用來定義其它標記語言的語言。它被用來在不同的商務過程中共享數據。XML的發展和JAVA是相互獨立的，但是，它和JAVA具有的相同目標正是平台獨立性。通過將JAVA和XML的組合，您可以得到一個完美的具有平台獨立性的解決方案。目前正有許多不同的公司在為JAVA和XML的組合而努力。如果要了解更多的這方面的信息，可以訪問SUN的JAVA-XML頁面，或者IBM DEVELOPERWORKS的XML ZONE。
總結
在本文中，我們介紹了建立在J2EE上的分布式應用結構，並且描述了WEBLOGIC伺服器對J2EE的各種支持。然而，我們所揭示的僅僅是冰山之一角而已，要以一篇數千字的文章來展示J2EE潛在的對您的企業級應用的影響可是很不公平的。
我們已經關注了在您開始用J2EE進行工作時最有可能遇到的各類技術：JDBC,JNDI,EJB,JSP和SERVLET。我們也為您提供了一些尚未常見的J2EE技術的背景知識。不管您是一名開發人員，商務應用分析師，或者項目經理，都應該對J2EE和WEBLOGIC伺服器所能提供給我們，給我們的企業以及我們的企業級應用所帶來的意義有一個更好的認識。
J2EE 帶動了Java在企業級的發展，但隨著一些輕量級組件的出現，J2EE的臃腫和開發難度高的缺點越來越引起了許多人的注意，EJB2.0也被許多人稱為累贅。隨著Spring,Hibernate的不斷完善和發展，EJB3.0出現了，成為了未來Java 企業級開發的新的方向。
使用元數據，注釋代替傳統的配置文件成為了新的熱點。JPA更是代替了傳統的CMP作為了更加便捷的持久化的方案。

10. 求J2EE簡單的購物車

寫個Email,給你發個完整項目!