javaEE 6 规范

来至: http://www.chinaitlab.com/Java/Special/java_ee/Chapter6.html

第6章应用程序编程接口

本章描述了Java^TM平台企业版(Java EE)的API标准。Java EE要求为Java EE应用程序提供大量API，首先是Java核心API，还包含了很多其它的Java技术。

6.1 必须的API

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规范的5、6、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)为可注入的类定义了一套标准的注解(和一个接口)。