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

在Java EE平台中，对依赖注入的支持由CDI调节。更具体地说，DI注入点只活动在Bean存档中，正如CDI所规定的。详细信息请查看5.20,“支持依赖注入(JSR-330)”。

DI规范参见 http://jcp.org/en/jsr/detail?id=330