javaEE 6 規範

時間 2019-11-16

標籤 javaee 規範欄目 Java 简体版

原文原文鏈接

來至: http://www.chinaitlab.com/Java/Special/java_ee/Chapter6.htmlhtml

第6章應用程序編程接口java

本章描述了Java^TM平臺企業版(Java EE)的API標準。Java EE要求爲Java EE應用程序提供大量API，首先是Java核心API，還包含了不少其它的Java技術。程序員

6.1 必須的APIweb

Java EE應用程序組件執行在容器提供的運行時環境中，容器是Java EE平臺的一部分。完整的Java EE平臺支持4種類型的容器，適合對應的Java EE應用程序組件類型，它們是: 應用程序客戶端容器，Applet容器，支持Servlet和JSP頁面的Web容器，以及企業Bean容器。Java EE Profile能夠只支持這些組件類型的子集，由單獨的Java EE Profile規範定義。數據庫

本章中的每項技術標準適用於任何包含這項技術的Java EE產品。注意，即便Java EE Profile不要求支持某項特殊技術，基於這項Profile的Java EE產品仍然能夠包含對這項技術的支持。在這種狀況下，能夠爲該項技術應用本章描述的標準。編程

6.1.1 Java兼容性API瀏覽器

容器提供的全部應用程序組件至少帶有Java平臺標準版v6 (Java SE) API。容器能夠提供最新版的Java SE平臺，以知足全部的Java EE平臺標準。Java SE 平臺包含了下列企業級技術:安全

Java IDL服務器

JDBC網絡

RMI-IIOP

JNDI

JAXP

StAX

JAAS

JMX

JAX-WS

JAXB

JAF

SAAJ

Common Annotation

特別是，Applet運行環境必須兼容Java SE 6平臺。因爲主流瀏覽器尚未提供這樣的支持，Java EE產品可使用Java插件來提供這種必須的環境。Java插件的使用不是必須的，但它知足了這個標準，提供了一個兼容Java SE 6平臺的Applet運行環境。本規範沒有給Applet容器增長Java SE平臺以外的標準。

一些Java SE 6平臺包含的企業級技術也能夠從Java SE平臺以外獲取，而且本規範要求使用一些技術的最新版，這將會在下面的小節中進行描述。

Java SE API規範能夠從 http://java.sun.com/javase/6/docs/ 獲取。

6.1.2 必須的Java技術

完整的Java EE平臺爲本規範定義的每種容器也提供了大量的Java技術。表 6-1 標明瞭這些技術及其版本號; 哪一種容器包含此項技術; 此項技術是必須的(REQ)，推薦可選的(POPT)，仍是可選的(OPT)。每項Java EE Profile規範會包含一張相似的表，描述哪項技術對這項Profile是必須的。注意，有些技術帶有標記。

Java技術	App Client	Web	EJB	Status
EJB 3.1	Ya	Y	Y	REQ, POPTb
Servlet 3.0	N	Y	N	REQ
JSP 2.2	N	Y	N	REQ
EL 2.2	N	Y	N	REQ
JMS 1.1	Y	Y	Y	REQ
JTA 1.1	N	Y	Y	REQ
JavaMail 1.4	Y	Y	Y	REQ
Connector 1.6	N	Y	Y	REQ
Web Service 1.3	Y	Y	Y	REQ
JAX-RPC 1.1	Y	Y	Y	REQ, POPT
JAX-WS 2.2	Y	Y	Y	REQ
JAX-RS 1.1	N	Y	N	REQ
JAXB 2.2	Y	Y	Y	REQ
JAXR 1.0	Y	Y	Y	REQ, POPT
JavaEE Management 1.1	Y	Y	Y	REQ
JavaEE Deployment 1.2c	N	N	N	REQ, POPT
JACC 1.4	N	Y	Y	REQ
JASPIC 1.0	N	Y	Y	REQ
JSP Debugging 1.0	N	Y	N	REQ
JSTL 1.2	N	Y	N	REQ
Web Service MetaData 2.1	Y	Y	Y	REQ
JSF 2.0	N	Y	N	REQ
Common Annotations 1.1	Y	Y	Y	REQ
Java Persistence 2.0	Y	Y	Y	REQ
Bean Validation 1.0	Y	Y	Y	REQ
Managed Bean 1.0	Y	Y	Y	REQ
Interceptor 1.1	Y	Y	Y	REQ
Contexts and Dependency Injection for Java EE 1.0	Y	Y	Y	REQ
Dependency for Java 1.0	Y	Y	Y	REQ

a. 僅對客戶端API

b. 僅對實體Bean

c. 請查看 6.18 中的詳細信息

推薦可選項描述在下一小節中。

上面提到的全部類和接口必須由Java EE容器提供。在某些狀況下，不要求Java EE產品提供實現了這些接口的對象，而是交給應用程序服務器。然而，這類接口的定義必須包含在Java EE平臺中。

6.1.3 被修剪的Java技術

隨着Java EE規範的不斷髮展，一些早期的Java EE技術再也不適合當前平臺的需求。Java EE專家組按照最早由Java SE專家組定義的流程，將這些技術從平臺移除(http://blogs.sun.com/mr/entry/removing_features )，此方式是謹慎和有序的，儘量低地影響開發者對這些技術的使用，使這個平臺可以更加健壯地成長。簡而言之，這個流程定義了兩個步驟:

1．發佈平臺N的總專家組(UEG)提出修剪某一特性，並在發佈的規範中記錄此項提議。

2．發佈平臺N+1的UEG決定是否重新的發佈中修剪這一特性，或是將它做爲必須的組件保留下來，也能夠把它定爲「推薦移除」狀態，留給下一個UEG來決定。

成功地爲某一特性應用這個策略並非真正刪除了這個特性，而是在必定程度上淡化這個特性，將它從平臺必須的組件變爲可選的組件。雖然這一特性沒有真正從規範中移除，然而它可能會被產品移除，這是產品供應商的選擇。

在將來發布中可能會修剪的技術在表6-1中被標記爲推薦可選。已經被修剪的技術在表6-1中被標記爲可選。Java EE 6中沒有標記爲可選的技術。

6.2 Java平臺標準版(Java SE) 標準

6.2.1 編程約束

Java EE編程模型劃分了應用程序組件供應商和Java EE產品供應商的職責: 應用程序組件供應商致力於編寫業務邏輯，而Java EE產品供應商致力於提供一套可管理的基礎系統框架，使應用程序能夠部署進去。

這種分工要求對應用程序組件在功能上進行約束。若是應用程序組件也提供一樣的功能，就會與基礎系統框架發生衝突，而且難於管理。

例如，假若容許一個企業Bean管理線程，Java EE平臺就沒法管理這個企業Bean的生命週期，而且不能正確地管理事務。

咱們不想抽取Java SE平臺的子集，而是但願Java EE產品供應商可以在Java EE平臺上直接使用Java SE產品，所以咱們使用Java SE安全權限機制來表述對應用程序組件供應商的強制編程約束。

在本節中，咱們指定的Java SE安全權限，必須由Java EE產品供應商爲每一個應用程序組件類型提供。咱們把這些權限叫作Java EE安全權限集。Java EE安全權限集被要求做爲Java EE API協議的組成部分。可移植的應用程序只信任在此規定的權限集。

6.2.2 Java EE安全權限集

Java EE安全權限集定義了應用程序組件指望的最小權限集。全部Java EE產品必須可以部署須要這些權限集的應用程序組件。產品供應商必須確保應用程序組件使用的功能不會與Java EE安全權限集衝突。

在特定設備環境中爲應用程序組件確立最佳的安全權限集是一個策略性的問題，不屬於本規範討論的範疇。Java EE產品容許應用程序在沒有任何安全管理器的狀況下運行，也能夠配置一個強制實施了任何安全權限集的安全管理器，正如企業環境所要求的。運行應用程序的全部Java EE產品，必須且至少支持這裏描述的權限集。一些Java EE產品容許組件配置安全權限集，爲一些組件提供比這裏描述的更多或更少的權限。本規範的將來版本將容許在應用程序組件的部署描述符中指定這些安全標準。目前，所需權限不在這個最小集合裏的應用程序組件只能在它們的文檔中描述本身標準。注意，須要更多權限的應用程序可能沒法部署在某些Java EE產品上。

有關Java SE安全權限的完整描述，參見http:// java.sun.com/javase/6/docs/technotes/guides/security/permissions.html

6.2.3 Java EE安全權限集列表

表 6-2 列出了Java EE安全權限集。這個典型權限集是每一個類型的組件理應享有的。

表 6-2 Java EE安全權限集

安全權限	目標	行爲
應用程序客戶端
java.aw.AWTPermission	accessClipboard
java.aw.AWTPermission	accessEventQueue
java.aw.AWTPermission	showWindowWithoutWainingBanner
java.lang.RuntimePermission	exitVM
java.lang.RuntimePermission	loadLibrary
java.lang.RuntimePermission	queuePrintJob
java.net.SocketPermission	*	connect
java.net.SocketPermission	localhost:1024-	accept,listen
java.io.FilePermission	*	read,write
java.util.PropertyPermission	*	read
Applet客戶端
java.net.SocketPermission	codebase	connect
java.util.PropertyPermission	limited	read
Web組件和EJB組件
java.lang.RuntimePermission	loadLibrary
java.lang.RuntimePermission	queuePrintJob
java.net.SocketPermission	*	connect
java.io.FilePermission	*	read,write
java.util.PropertyPermission	*	read

注意，安裝Java EE產品的操做系統能夠強制附加本身的安全約束，必須考慮到這一點。比方說，組件使用的用戶標識不能有權讀寫全部文件。

6.2.4 附加標準

6.2.4.1 網絡

Java SE平臺包含了支持多種URL協議的即插即用機制，這須要使用java.net.URLStreamHandler類和java.net.URLStreamHandlerFactory接口。

必須支持下面的URL協議:

file: 只須要支持從file URL讀取。更確切地說，對應的URLConnection對象的getOutputStream方法將會拋出UnknownServiceException異常。而且根據上面描述的權限，文件訪問也是有限制的。
http: 必須支持HTTP協議1.1。http URL必須同時支持輸入和輸出。
https: https URL對象必須支持SSL3.0和TLS1.0，也必須同時支持輸入和輸出。

Java SE平臺也包含一種機制，將URL字節流轉換成相應的對象，這是經過java.net.ContentHandler類和java.net.ContentHandlerFactory接口來完成的。ContentHandler 對象可以將MIME字節流轉換成對象。一般使用URL和URLConnection對象的getContent方法間接地訪問ContentHandler對象。

當使用getContent方法訪問下面的MIME類型數據時，必須返回表 6-3中列出的相應Java對象類型。

表 6-3 getContent方法返回對象的Java類型

MIME類型	Java類型
image/gif	java.awt.Image
image/jpeg	java.awt.Image
image/png	java.awt.Image

不少環境使用HTTP代理而不是直接鏈接到HTTP服務器。若是想在本地環境中使用HTTP代理，Java SE平臺的HTTP支持應該使用合適的代理進行配置。不要求應用程序組件爲使用http URL而配置代理支持。

大多數企業環境會包含防火牆，限制內部網絡(局域網)到國際互聯網的訪問，反過來也是如此。一般使用HTTP協議來穿過這種防火牆進行訪問，也可能使用代理服務器。一般不會使用總的TCP/IP通訊來穿過防火牆，這包括RMI-JRMP和RMI-IIOP。

還須要考慮到使用各類協議的應用程序組件之間的通訊。本規範要求，本地策略容許HTTP訪問可以經過防火牆。一些Java EE產品能夠爲其它通訊開闢通道，但這既不是規定也不是必須的。

6.2.4.2 JDBC^TM API

JDBC API是Java SE平臺的組成部分，它能夠訪問普遍的數據存儲系統。然而，Java SE平臺不要求知足Java兼容性質量標準的系統提供的數據庫必須經過JDBC API來訪問。

爲容許部署可移植的應用程序，Java EE規範不要求Java EE產品經過JDBC API來使用和訪問這類數據庫。Web組件，企業Bean和應用程序客戶端必須可以訪問這樣的數據庫，對Applet不做要求。另外，數據庫驅動必須知足JDBC規範中描述的JDBC兼容性標準。

Java EE應用程序不該該試圖直接加載JDBC驅動，而是應該使用JDBC規範推薦的技術並執行JNDI查找來定位數據源對象。選擇數據源對象的JNDI名稱應該依據5.7,「資源管理器鏈接工廠的引用」中的描述。當獲取數據庫鏈接時，Java EE平臺必須可以提供一個數據源，它不須要應用程序提供任何驗證信息。固然，鏈接數據庫時應用程序也能夠提供用戶名和密碼。

當企業Bean使用JDBC API鏈接時，事務特徵一般由容器控制。組件不該該試圖改變鏈接的事務特徵，也不該該試圖提交事務，回滾事務或設置自動提交方式。與當前事務上下文不兼容的改變將拋出SQLException異常。EJB規範對企業Bean定義了嚴格的規則。

注意，當組件使用JTA UserTransaction接口建立事務時，會使用相同的約束。組件不該該試圖操做上面列出的JDBC Connection對象，這會與事務上下文衝突。

Java EE環境中支持JDBC API的驅動必須知足JDBC 4.0兼容性標準，正如JDBC 4.0規範6.4節中描述的。

JDBC API支持JNDI命名的鏈接，鏈接池和分佈式事務。鏈接池和分佈式事務特性用來配合應用程序服務器。不要求Java EE產品使用這些API來加強應用程序服務器的能力，可是它們被證實是有用的。

鏈接器體系結構定義了一個SPI，經過附加的安全功能和對資源適配器完整的打包部署功能，它從根本上擴展了JDBC SPI的功能。支持鏈接器體系結構的Java EE產品必須支持部署和使用JDBC驅動，它們已經被編寫並打包，做爲鏈接器體系結構的資源適配器。

JDBC 4.0規範參見http://java.sun.com/products/jdbc/download.html

6.2.4.3 Java IDL

本節中的標準僅適用於經過CORBA提供互用性的Java EE產品。

Java IDL 使應用程序能夠訪問任何語言編寫的CORBA對象，這須要使用標準的IIOP協議。Java EE安全約束一般會阻止全部應用程序組件類型(應用程序客戶端除外)建立和導出CORBA對象，可是全部Java EE應用程序組件類型能夠做爲CORBA對象的客戶端。

Java EE產品必須支持Java IDL，正如CORBA 2.3.1規範的1-8, 13和15章所定義的，參見http://www.omg.org/cgi-bin/doc?formal/99-10-07和 IDL-Java語言映射規範http://www.omg.org/cgi-bin/doc?ptc/2000-01-08

IIOP協議支持單鏈接多元調用功能。全部Java EE產品必須爲來自客戶端的請求支持：在一個鏈接上多元調用Java IDL服務器對象或RMI-IIOP服務器對象(例如企業Bean)。服務器必須能夠按任意順序進行響應，以免一個調用等待另外一個調用的完成而引發死鎖。不要求Java EE 客戶端支持多元調用，但這是很是值得推薦的。

Java EE產品必須爲CORBA Portable Object Adapter (POA)提供支持，從而支持可移植的存根(stub)，骨架(skeleton)和銜接(tie)類。定義或使用CORBA對象的Java EE應用程序(企業Bean除外)必須在應用程序包中包含這種可移植的存根(stub)，骨架(skeleton)和銜接(tie)類。

Java EE應用程序須要使用org.omg.CORBA.ORB 對象的實例來執行不少Java IDL和RMI-IIOP操做。調用ORB.init(new String[0], null)方法默認返回的ORB 必須可用於這樣的用途；應用程序不須要知道爲支持ORB和RMI-IIOP提供的實現類。

另外，考慮到性能因素，在應用程序的組件間共享ORB實例經常是有益的。爲支持這種用法，要求全部Web，企業Bean和應用程序客戶端容器在JNDI命名空間java:comp/ORB下提供一個ORB實例。容器能夠決定是否在組件間共享這個實例。容器本身也可使用這個ORB實例。爲支持應用程序的分隔，不該該在不一樣應用程序的組件間共享ORB實例。爲保證組件安全地共享這個ORB實例，可移植的組件必須約束它們對某些ORB API和功能的使用:

不要調用ORB的shutdown方法。
不要使用容器使用的id來調用org.omg.CORBA_2_3.ORB的register_value_factory 和 unregister_value_factory方法。

Java EE產品必須提供COSNaming服務來支持EJB交互性標準。必須可以使用Java IDL COSNaming API來訪問這種COSNaming服務。帶有適當特權的應用程序必須可以在COSNaming服務中查找對象。COSNaming定義在互用性命名服務規範中，參見http://www.omg.org/cgi-bin/doc?formal/2000-06-19

6.2.4.4 RMI-JRMP

JRMP是Java特有的遠程方法調用(RMI)協議。Java EE安全約束一般會阻止全部應用程序組件類型(應用程序客戶端除外)建立和導出RMI對象，可是全部Java EE應用程序組件類型能夠做爲RMI對象的客戶端。

6.2.4.5 RMI-IIOP

本節中的標準僅適用於包含了EJB容器並使用RMI-IIOP支持互用性的Java EE產品。

RMI-IIOP容許使用IIOP協議訪問RMI風格的接口定義的對象。必須可以經過RMI-IIOP訪問遠程企業Bean。經過RMI-IIOP，一些Java EE產品很容易地就能讓全部遠程企業Bean老是(而且只是)可訪問的；經過管理和部署行爲，其它產品能夠對其進行控制。只要使用RMI-IIOP能夠訪問任何遠程企業Bean(或擴展到全部遠程企業Bean)，這些途徑或別的途徑就是容許的。

全部組件必須使用javax.rmi.PortableRemoteObject類的narrow方法來訪問遠程企業Bean，正如EJB規範所描述的。由於遠程企業Bean可使用RMI協議部署，可移植的應用程序不能依賴RMI-IIOP對象的特徵(例如，使用Stub和Tie基類)，這些特徵超出了EJB規範。

Java EE安全約束一般會阻止全部應用程序組件類型(除了應用程序客戶端)建立和導出RMI-IIOP對象。全部Java EE應用程序組件類型能夠做爲RMI-IIOP對象的客戶端。Java EE應用程序也應該使用JNDI來查找非EJB RMI-IIOP對象。這種非EJB RMI-IIOP對象使用的JNDI名稱應該在部署時進行配置，這須要使用標準環境入口機制(參見5.2,「JNDI命名上下文」)。應用程序應該使用環境入口從JNDI取得一個名稱，而後使用這個名稱查找RMI-IIOP對象。一般這樣的名稱會被配置成COSNaming命名服務中的名稱。

本規範沒有爲應用程序提供一種可移植的方式，將對象綁定到命名服務中的名稱。一些產品能夠支持使用JNDI和COSNaming來綁定對象，但這不是必須的。可移植的Java EE應用程序客戶端能夠建立非EJB RMI-IIOP服務器對象，將它做爲回調對象使用，或傳遞到對其它RMI-IIOP對象的調用中。

注意，雖然RMI-IIOP沒有指定怎樣傳遞當前安全上下文或事務上下文，但EJB互用性規範定義了這種上下文的傳遞。本規範只要求在使用RMI-IIOP訪問企業Bean時支持上下文信息的傳遞，正如EJB規範所描述的。不要求在使用RMI-IIOP訪問非企業Bean對象時傳遞上下文信息。

RMI-IIOP規範描述了怎樣建立可移植的Stub和Tie類。爲了移植全部使用CORBA便攜式對象適配器(POA)的實現，Tie類必須繼承org.omg.PortableServer.Servant類。一般這是使用rmic命令的-poa選項來實現。一個Java EE產品必須提供對這些可移植的Stub和Tie類的支持，一般是使用必要的CORBA POA。然而，對於沒有使用POA來實現RMI-IIOP的系統的可移植性，應用程序不該該依賴Tie繼承Servant類來達到。定義或使用了RMI-IIOP對象(而非企業Bean)的Java EE應用程序必須在應用程序包中歸入這種可移植的Stub和Tie類。然而，企業Bean的Stub和Tie對象不能包含在應用程序中: 若是須要，它們會被Java EE產品在部署或運行時生成。

RMI-IIOP定義在CORBA 2.3.1規範的五、六、13章和10.6.2節中，參見http://www.omg.org/cgi-bin/doc?formal/99-10-07以及Java^TM語言-IDL映射規範http://www.omg.org/cgi-bin/doc?ptc/2000-01-06.

6.2.4.6 JNDI

支持下述對象類型的Java EE產品必須使它們在JNDI命名空間中可用: EJBHome對象，EJBLocalHome對象，JTA UserTransaction對象，JDBC API DataSource對象，JMS ConnectionFactory和Destination對象，JavaMail Session對象，URL對象，資源管理器ConnectionFactory對象(在鏈接器規範中指定)，ORB對象，EntityManager對象以及5,「資源，命名和注入」中描述的其它Java語言對象。Java EE產品中的JNDI實現必須可以在單個應用程序組件中使用單個JNDI InitialContext支持全部這些對象的使用。應用程序組件一般會使用默認的無參構造方法建立一個JNDI InitialContext，以後就能夠用這個InitialContext查找上面指定的對象。

用於查找Java EE對象的名稱依賴於應用程序。應用程序組件的部署描述符列出對象指望的名稱和類型。部署者配置JNDI命名空間使相應的組件可用。用於查找這種對象的JNDI名稱必須是在JNDI的java:命名空間中。詳細信息請查看5,「資源，命名和注入」。

本規範爲這些狀況定義了兩個特殊的名稱，當Java EE產品包含相應的技術時。全部訪問JTA UserTtransaction接口的應用程序組件，可使用名稱java:comp/UserTransaction找到對應的UserTransaction對象。在全部容器(Applet除外)中，應用程序組件可使用名稱java:comp/ORB查找CORBA ORB實例。

用於查找特定Java EE對象的名稱因不一樣的應用程序組件而異。通常來講，JNDI名稱不能做爲參數在遠程組件的調用中傳遞(例如，在企業Bean調用中)。

JNDI的java:命名空間通常做爲連接到其它命名系統的符號而實現。不一樣的基礎命名服務能夠用來保存不一樣類型的對象，甚至對象的不一樣實例。Java EE產品有責任提供必需的JNDI服務提供方來訪問本規範中定義的各類對象。

本規範要求Java EE平臺提供執行以上查找操做的功能。不一樣的JNDI服務提供方能夠提供不一樣的功能，例如，一些服務提供方在命名服務中只提供對數據的只讀操做。

能夠要求Java EE產品提供一個COSNaming命名服務來知足EJB互用性標準。在這種狀況下，COSNaming JNDI服務提供方必須對Web，EJB和應用程序客戶端容器可用。它一般對Applet容器也是可用的，但這不是必須的。

COSNaming JNDI服務提供方是Sun的Java SE 6 SDK和JRE的一部分，但不是Java SE規範的必須組件。關於COSNaming JNDI服務提供方規範，請查看http://java.sun.com/javase/6/docs/technotes/guides/jndi/jndi-cos.html

Java EE平臺完整的命名標準，請查看5,「資源，命名和注入」。關於JNDI規範，請查看http://java.sun.com/products/jndi/docs.html

6.2.4.7 上下文類加載器

本規範要求Java EE容器爲每一個線程的上下文配置類加載器，使它們能夠動態地加載應用程序提供的系統和類庫中的類。EJB規範要求全部EJB客戶端容器爲每一個線程的上下文配置類加載器，使它們能夠動態地加載系統參數類。使用Thread的getContextClassLoader方法能夠訪問每一個線程的上下文類加載器。

這些應用程序使用的類一般由不一樣層次的類加載器加載。從頂層的應用程序類加載器到擴展類加載器，直到最底層的系統類加載器。頂層應用程序類加載器須要委託下層的類加載器進行加載。被下層類加載器加載的類，例如可移植的EJB系統參數類，須要可以發現用於加載應用程序類的頂層應用程序類加載器。

本規範要求容器爲每一個線程的上下文配置類加載器，可以用來加載上面描述的頂層應用程序類。請查看8.2.5,「動態類加載」瞭解動態類加載的建議。

6.2.4.8 Java^TM驗證和受權服務(JAAS)標準

全部EJB容器和全部Web容器必須支持JAAS API的使用，正如鏈接器規範所規定的。全部應用程序客戶端容器必須支持JAAS API的使用，正如10,「應用程序客戶端」所規定的。

JAAS規範參見http://java.sun.com/products/jaas

6.2.4.9 Logging API 標準

Logging API 提供的類和接口在java.util.logging包中，這個包是Java^TM平臺的核心日誌工具。本規範不要求提供對日誌的附加支持。Java EE應用程序一般沒有日誌權限來控制日誌的配置，可是可使用日誌API來導出日誌記錄。本規範的將來版本可能會要求Java EE容器使用日誌API來記錄某些事件。

6.2.4.10 Preferences API標準

java.util.prefs包中Preferences API使應用程序能夠保存和恢復用戶和系統的preference(偏好)和配置信息。Java EE應用程序一般沒有運行時權限(「preferences」)來使用Preferences API。本規範沒有在Java EE應用程序使用的主體和Preferences API定義的用戶偏好樹之間定義任何關係。本規範的將來版本可能會定義Java EE應用程序對Preferences API的使用。(譯者注，例如可使用Preferences API來操做Windows註冊表)

6.3 企業級JavaBeans^TM (EJB) 3.1 標準

本規範要求Java EE產品爲企業Bean提供支持，正如EJB規範所規定的。EJB規範參見http://java.sun.com/products/ejb/docs.html

本規範此時沒有強制實施任何附加標準。注意，EJB規範包含了基於RMI-IIOP的EJB互用性協議。全部支持EJB客戶端的容器必須可以使用EJB互用性協議來調用企業Bean。全部EJB容器必須支持使用EJB互用性協議的企業Bean調用。Java EE產品也能夠支持其它協議來調用企業Bean。

Java EE產品能夠支持多種對象系統(例如，RMI-IIOP和RMI-JRMP)。不必定老是可以將對象的引用從一個對象系統傳遞給另外一個對象系統中的對象。然而，當企業Bean使用了RMI-IIOP協議，它必須可以將RMI-IIOP或Java IDL對象的引用做爲參數傳遞給這類企業Bean的方法，而且可以經過這類企業Bean的方法返回這些對象的引用。另外，必須可以將基於RMI-IIOP的企業Bean的Home或Remot接口的引用傳遞給RMI-IIOP或Java IDL對象的某個方法，或是可以從RMI-IIOP或Java IDL對象返回這類企業Bean對象的引用。

在同時包含EJB容器和Web容器的Java EE產品中，要求這兩種容器都支持對本地企業Bean的訪問。不支持應用程序客戶端容器或Applet容器訪問本地企業Bean。

6.4 Servlet 3.0 標準

Servlet規範定義了Web應用程序的打包和部署是否能夠單獨進行，或做爲Java EE應用程序的組成部分。Servlet規範也闡述了獨立打包部署和嵌入Java EE平臺的安全問題。這些可選的Servlet組件是Java EE平臺的標準。

Servlet規範包含了對Web容器的附加標準，這些容器是Java EE產品的組成部分，而且Java EE產品也必須知足這些標準。

Servlet規範定義了分佈式Web應用程序。爲了支持分佈式的Java EE應用程序，本規範增長了下述標準。

Web容器必須支持Java EE分佈式Web應用程序，使用setAttribute或putValue方法將任意下列類型的對象(若是Java EE產品支持)放入javax.servlet.http.HttpSession對象中:

java.io.Serializable
javax.ejb.EJBObject
javax.ejb.EJBHome
javax.ejb.EJBLocalObject
javax.ejb.EJBLocalHome
javax.transaction.UserTransaction
java:comp/env上下文的 javax.naming.Context對象
一個EJB本地或遠程業務接口的引用

Web容器也能夠支持其它類型的對象。若是Java EE分佈式會話對應的HttpSession對象中的setAttribute或putValue方法接收的對象不是上述類型，也不是任何Web容器支持的類型，那麼容器必須拋出java.lang.IllegalArgumentException異常。這個異常告訴程序員Web容器不支持在虛擬機間傳送此對象。支持多虛擬機操做的Web容器必須確保，當一個會話從一個虛擬機傳到另外一個時，全部合法類型的對象能正確地在目標虛擬機上重建。

Servlet規範將訪問本地企業Bean定義爲一個可選特性。本規範要求，同時包含Web容器和EJB容器的全部Java EE產品支持從Web容器訪問本地企業Bean。

Servlet規範參見 http://java.sun.com/products/servlet

6.5 JavaServer Pages^TM (JSP) 2.2 標準

JSP規範依賴並構建在Servlet框架上。Java EE產品必須徹底支持JSP規範。

JSP規範參見 http://java.sun.com/products/jsp

6.6 Expression Language (EL) 2.2 標準

表達式語言規範之前是JSP規範的一部分。如今它分離出來有了本身規範，所以能夠獨立於JSP使用。Java EE產品必須支持表達式語言。

表達式語言規範參見 http://jcp.org/en/jsr/detail?id=245

6.7 Java^TM Message Service (JMS) 1.1 標準

Java消息服務提供方必須包含在Java EE產品中。JMS的實現必須同時支持JMS「點對點」和「發佈-訂閱」消息發送功能，要讓使這些功能可用，須要使用ConnectionFactory和Destination API。

JMS規範定義了幾個接口，用於整合到應用程序服務器。Java EE產品不須要提供實現了這些接口的對象，而且可移植的Java EE產品不能使用下列接口:

javax.jms.ServerSession
javax.jms.ServerSessionPool
javax.jms.ConnectionConsumer
全部javax.jms XA接口

下面的方法只能被運行在應用程序客戶端容器中的應用程序組件使用:

javax.jms.Session的setMessageListener方法
javax.jms.Session的getMessageListener方法
javax.jms.Session的run方法
javax.jms.QueueConnection的createConnectionConsumer方法
javax.jms.TopicConnection的createConnectionConsumer方法
javax.jms.TopicConnection的createDurableConnectionConsumer方法
javax.jms.MessageConsumer的getMessageListener方法
javax.jms.MessageConsumer的setMessageListener方法
javax.jms.Connection的setExceptionListener方法
javax.jms.Connection的stop方法
javax.jms.Connection的setClientID方法

若是應用程序組件違反了這些限制，Java EE容器能夠拋出JMSException異常(若是方法容許)。

Web和EJB容器中的應用程序組件不能試圖爲每一個鏈接建立多個活動的Session對象(沒有關閉)。當那個鏈接存在一個活動的Session對象時，容器應該禁止嘗試使用Connection對象的createSession方法。若是應用程序組件違反了此限制，容器能夠拋出JMSException異常。應用程序客戶端容器必須支持在一個鏈接上建立多個會話。

通常而言，JMS提供方在EJB容器和Web容器中的行爲應該是一致的。EJB規範描述了在EJB容器中使用JMS的約束，以及在EJB容器中多事務JMS的交互。運行在Web容器中的應用程序應該遵循相同的約束。

JMS規範參見 http://java.sun.com/products/jms

6.8 Java^TM Transaction API (JTA) 1.1 標準

JTA定義了UserTransaction接口，它被應用程序用來啓動，提交或停止事務。應用程序組件能夠獲取UserTransaction對象，這須要經過JNDI名稱java:comp/UserTransaction 進行查找，或者請求UserTransaction對象的注入。

JTA也定義了TransactionSynchronizationRegistry接口，它能夠被系統級組件使用，好比用在持久化管理器與事務管理器的交互中。這些組件能夠獲取TransactionSynchronizationRegistry 對象，這須要經過JNDI名稱java:comp/TransactionSynchronizationRegistry進行查找，或者請求TransactionSynchronizationRegistry對象的注入。

JTA定義的一些接口被應用程序服務器用來與事務管理器進行通訊，而後由事務管理器與資源管理器進行交互。這些接口必須獲得支持，正如鏈接器規範所描述的。另外，Java EE產品能夠顯式地爲應用程序提供其它事務功能的支持。

JTA規範參見 http://java.sun.com/products/jta

6.9 JavaMail^TM 1.4 標準

JavaMail API容許訪問消息存儲層中的郵件消息，也容許使用消息輸送層來建立和發送郵件消息。互聯網標準的MIME消息須要包含特殊的支持。訪問消息存儲層和消息輸送層須要經過協議提供方支持的特定存儲和輸送協議。JavaMail API規範不要求任何特殊的協議提供方，可是JavaMail引用的實現包含一個IMAP消息存儲提供方，一個POP3消息存儲提供方和一個SMTP消息輸送提供方。

一般是在一個Properties對象的屬性中對JavaMail API進行配置，這個對象用來建立javax.mail.Session對象，這須要使用一個靜態的工廠方法。爲了使Java EE平臺能夠配置和管理JavaMail API的會話，使用這個JavaMail API的應用程序組件應該使用JNDI請求一個Session對象，而且應該在它的部署描述符中使用resource-ref元素列出這個對象的需求，或者也可使用Resource註解。JavaMail API Session對象應當看做是一個資源工廠，正如5.7,「資源管理器鏈接工廠的引用」所描述的。本規範要求Java EE平臺支持 javax.mail.Session對象做爲資源工廠。

Java EE平臺提供的消息輸送層必須可以處理javax.mail.internet.InternetAddress類型的地址和javax.mail.internet.MimeMessage類型的消息。必須正確地配置默認的消息輸送系統，並使用javax.mail.Transport類的send方法來發送這類消息。默認的輸送層所需的任何驗證必須獲得處理，而不須要應用程序提供javax.mail.Authenticator或顯式地鏈接到輸送層來獲取驗證信息。

本規範不要求Java EE產品支持任何消息存儲協議。

注意，JavaMail API建立線程來遞交Store，Folder，和Transport事件的通知。這些通知功能的使用受到各類容器在線程使用約束上的影響。例如，一般不能在EJB容器中建立線程。

JavaMail API使用JavaBean激活框架API來支持各類MIME數據類型。JavaMail API必須包含處理下列MIME數據類型的javax.activation.DataContentHandlers，它們對應的Java編程語言類型標明在表 6-4中。

表 6-4 JavaMail API MIME數據類型映射的Java類型

MIME類型	Java類型
text/plain	java.lang.String
text/html	java.lang.String
text/xml	java.lang.String
multipart/*	javax.mail.internet.MimeMultipart
message/rfc822	javax.mail.internet.MimeMessage

JavaMail API規範參見 http://java.sun.com/products/javamail

6.10 Java EE^TM鏈接器體系結構1.6標準

在整個Java EE產品中，全部EJB容器和全部Web容器都必須支持整套鏈接器API。全部這種容器必須支持任何指定了事務功能的資源適配器。Java EE部署工具必須支持資源適配器的部署，正如鏈接器規範所定義的，而且必須支持使用了資源適配器的應用程序的部署。

鏈接器規範參見 http://java.sun.com/j2ee/connector/

6.11 Java EE Web服務1.3標準

Java EE Web服務規範定義的功能要求Java EE應用程序服務器必須支持Web服務終端的部署。定義完整的部署模型須要包含一些新的部署描述符。全部Java EE產品必須支持Web服務的部署和執行，正如Java EE Web服務規範(JSR-109)所指定的。

Java EE Web服務規範參見 http://jcp.org/en/jsr/detail?id=109

6.12 Java^TM API for XML-based RPC (JAX-RPC) 1.1標準 (推薦可選)

JAX-RPC規範定義了用於訪問Web服務的客戶端API以及實現Web服務終端的技術。Java EE Web服務規範描述了基於JAX-RPC的服務和客戶端的部署。EJB和Servlet規範也描述了這類部署的相關問題。必須可以使用這些部署模型來部署基於JAX-RPC的應用程序。

JAX-RPC規範描述了對消息處理器的支持，它們能夠處理消息請求和響應。通常而言，這些消息處理器執行在同一容器中，其權限和執行上下文與JAX-RPC客戶端或終端組件相同，並與之關聯的。這些消息處理器訪問的JNDI命名空間java:comp/env，與它們關聯的組件相同。若是支持自定義的序列化和反序列化，會用與消息處理器相同的方式對待它們。

注意，JAX-RPC服務終端和處理器既不支持Web服務註解也不支持注入。鼓勵新的應用程序使用JAX-WS來利用這些新功能，以簡化Web服務的開發。

JAX-RPC規範參見 http://java.sun.com/Webservices/jaxrpc

6.13 Java^TM API for XML Web Services (JAX-WS) 2.2 標準

JAX-WS規範提供對Web服務的支持，並使用JAXB API將XML數據綁定到Java對象。 JAX-WS 規範定義了訪問Web服務的客戶端API以及實現Web服務終端的技術。Java EE Web服務規範描述了基於JAX-WS的服務和客戶端的部署。EJB和Servlet規範也描述了這類部署的相關問題。必須可以使用這些部署模型來部署基於JAX-WS的應用程序。

JAX-WS規範描述了對消息處理器的支持，它們能夠處理消息請求和應答。通常而言，這些消息處理器執行在同一容器中，其權限和執行上下文與JAVA-WS客戶端或終端組件相同，並與之關聯。這些消息處理器訪問的JNDI命名空間java:comp/env，與它們關聯的組件相同。若是支持自定義的序列化和反序列化，會用與消息處理器相同的方式對待它們。

JAX-WS規範參見 http://java.sun.com/Webservices/jaxws

6.14 Java^TM API for RESTful Web Services (JAX-RS) 1.1 標準

JAX-RS定義了部署Web服務的API，這些Web服務根據Representational State Transfer (REST)體系風格構建。

在整個Java EE產品中，要求全部Java EE Web容器支持使用JAX-RS技術的應用程序。

此規範描述了做爲Servlet對服務進行部署。必須可以使用相應的部署模型來部署基於JAX-RS的應用程序，這種部署模型使用了web.xml描述符的servlet-class元素，它的名稱是應用程序提供的JAX-RS ApplicationConfig抽象類的擴展類。

此規範定義了一套可選的容器管理的功能和資源，它們會在Java EE容器中使用，全部這樣的特性和資源必須可用。

JAX-RS規範參見 http://jcp.org/en/jsr/detail?id=311

6.15 Java^TM Architecture for XML Binding (JAXB) 2.2 標準

Java Architecture for XML Binding (JAXB) 提供了一種簡便的方式將XML Schema綁定到Java語言程序。JAXB能夠獨立使用，也能夠與JAX-WS進行組合，它爲Web消息服務提供了一種標準的數據綁定。在整個Java EE產品中，要求全部的Java EE應用程序客戶端容器，Web容器和EJB容器支持JAXB API。

Java API for XML Data Binding規範參見 http://java.sun.com/webservices/jaxb

6.16 Java^TM API for XML Registries (JAXR) 1.0 標準 (推薦可選)

JAXR規範爲客戶端定義了用於訪問基於XML的註冊表的API，好比，ebXML註冊表和UDDI註冊表。支持JAXR的Java EE產品必須包含一個JAXR註冊表提供方，它至少知足JAXR 0級標準。

JAXR規範參見 http://java.sun.com/xml/jaxr

6.17 Java^TM Platform, Enterprise Edition Management API 1.1 標準

Java EE Management API 爲部署工具提供API來查詢Java EE應用程序服務器，並肯定它的當前情況，已部署的應用程序等等。全部Java EE產品必須支持它的規範中描述的這種API。

Java EE Management API規範參見 http://jcp.org/jsr/detail/77.jsp

6.18 Java^TM Platform, Enterprise Edition Deployment API 1.2 標準 (推薦可選)

Java EE Deployment API定義了部署工具的運行時環境和Java EE應用程序服務器提供的插入式組件之間的接口。這些插入式組件執行在部署工具中，實現了特定Java EE產品的部署機制。要求全部Java EE產品提供這些在工具中使用的插入式組件，它們能夠來自其它供應商。

注意，Java EE部署規範沒有定義Java EE應用程序直接使用的新的API。然而，必須可以建立做爲部署工具的Java EE應用程序，讓它提供Java EE部署規範要求的運行時環境。

Java EE Deployment API 規範參見 http://java.sun.com/j2ee/tools/deployment

6.19 Java^TM Authorization Service Provider Contract for Containers (JACC) 1.4 標準

JACC規範在Java EE應用程序服務器和受權策略供應商之間定義了一個協議。在整個Java EE產品中，要求全部的Java EE應用程序容器，Web容器和企業Bean容器支持此協議。

JACC規範參見 http://jcp.org/jsr/detail/115.jsp

6.20 Java^TM Authentication Service Provider Interface for Containers (JASPIC) 1.0 標準

JASPIC規範定義了一個服務供應商接口(SPI)，經過它，實現消息驗證機制的驗證提供方能夠在運行時集成到客戶端或服務器消息處理容器中。用這個接口集成的驗證提供方操做容器提供給它們的網絡消息。它們對傳出的消息進行加工，使消息源能夠被接收它的容器驗證，而且消息接收方能夠被消息發送方驗證。它們驗證新的消息並將驗證後產生的標識返回給調用它們的容器。

在整個Java EE產品中，要求全部Java EE應用程序容器，Web容器和企業Bean容器支持基線兼容標準，正如JASPIC規範所定義的。在整個Java EE產品中，全部Web容器也必須支持JASPIC規範定義的Servlet Container Profile。

JASPIC規範參見 http://jcp.org/jsr/detail/196.jsp

6.21 Debugging Support for Other Languages (JSR-45) 標準

JSP頁面一般被翻譯成Java語言類文件。Debugging Support for Other Languages規範描述了包含在類文件中的特殊信息，它將類文件數據關聯到最初的源文件數據。要求全部Java EE產品可以在JSP頁面生成的類文件中包含這樣的信息。

Debugging Support for Other Languages 規範參見 http://jcp.org/en/jsr/detail?id=45

6.22 Standard Tag Library for JavaServer Pages^TM (JSTL) 1.2 標準

JSTL 定義了一個標準標籤庫，用來簡化JSP頁面的開發。要求全部Java EE產品提供全部JSP頁面都能使用的JSTL。

Standard Tag Library for JavaServer Pages規範參見 http://jcp.org/en/jsr/detail?id=52

6.23 Web Services Metadata for the Java^TM Platform 2.1 標準

Java平臺Web服務元數據規範定義了可用來簡化Web服務部署工做的Java語言註解。這些註解能夠和JAX-WS服務組件一塊兒使用。

Web Services Metadata for the Java Platform規範參見 http://jcp.org/en/jsr/detail?id=181

6.24 JavaServer Faces^TM 2.0 標準

JavaServer Faces 技術爲JavaServer應用程序簡化了用戶界面的開發。不一樣技能水平的開發者能夠快速構建Web應用程序，經過: 在頁面中組裝可重複使用的UI組件;將這些組件鏈接到應用程序數據源;而且將客戶端產生的事件聯繫到服務器端事件處理器。在整個Java EE平臺中，要求全部Java EE Web容器支持使用JavaServer Faces技術的應用程序。

JavaServer Faces規範參見 http://jcp.org/en/jsr/detail?id=252

6.25 Java^TM平臺公共註解 1.1 標準

公共註解規範定義了其它某些規範使用的Java語言註解，包括本規範。使用這些註解的規範完整地定義了這些註解的標準。Applet容器不須要支持任何這樣的註解。全部其它容器必須爲全部這類註解提供定義，而且必須支持這些註解的語義，它們描述在對應的規範中，下表對它們進行了總結。

表 6-5 容器支持的公共註解

註解	App Client	Web	EJB
Resource	Y	Y	Y
Resources	Y	Y	Y
PostConstruct	Y	Y	Y
PreDestroy	Y	Y	Y
Generated	N	N	N
RunAs	N	Y	Y
DeclareRoles	N	Y	Y
RolesAllowed	N	Y	Y
PermitAll	N	Y	Y
DenyAll	N	Y	Y

Common Annotations for the Java Platform 規範參見 http://jcp.org/en/jsr/detail?id=250

6.26 Java^TM Persistence API 2.0 標準

Java Persistence是一種標準的API，用於管理持久化和對象/關係映射。Java持久化規範提供了一種對象/關係映射功能，幫助應用程序開發者使用Java域模型來管理關係數據庫。要求在Java EE中支持Java持久化。它也能夠用在Java SE環境中。

按照Java持久化規範的委任機制，在Java EE環境中，應用程序類加載器及其雙親類加載器不該該加載持久化單元的類，直到建立了持久化單元的實體管理器工廠。

Java持久化規範由EJB專家組制定，參見 http://jcp.org/en/jsr/detail?id=220

6.27 Bean Validation 1.0 標準

Bean Validation規範定義了爲JavaBean檢驗定義了一種元數據模型和API。註解是默認的元數據源，經過使用XML檢驗描述符，能夠重寫和擴展元數據。

Java EE平臺要求Web容器讓一個ValidatorFactory實例對JSF實現可用，這須要將它保存在一個叫作java.faces.validator.beanValidator.ValidatorFactory的Servlet上下文環境屬性中。

Java EE平臺也要求ValidatorFactory實例對JPA提供方可用，它將做爲Map中的屬性傳給PersistenceProvider接口的createContainerEntityManagerFactory(PersistenceUnitInfo,Map)方法的第二個參數，這個接口在javax.persistence.validation.factory包中。

Bean Validation 規範參見http://jcp.org/en/jsr/detail?id=303

6.28 Managed Beans 1.0 標準

Managed Beans 規範定義了一個輕量級的組件模型，它支持Java平臺現有的基本的生命週期模型，資源注入功能和攔截器服務。

Managed Beans規範參見 http://jcp.org/en/jsr/detail?id=316

6.29 Interceptors 1.1 標準

攔截器規範使攔截器功能得以更廣泛地使用，起初它們定義在EJB 3.0規範中。

攔截器規範參見 http://jcp.org/en/jsr/detail?id=318

6.30 Contexts and Dependency Injection for the Java EE Platform 1.0 標準

CDI (JSR-299) 定義了一套上下文相關的服務，這些服務由Java EE容器提供，目的在於簡化同時使用Web層和業務層的應用程序的建立。

CDI 規範參見 http://jcp.org/en/jsr/detail?id=299

6.31 Dependency Injection for Java 1.0標準

Dependency Injection for Java (JSR-330)爲可注入的類定義了一套標準的註解(和一個接口)。