本文档详细介绍了Java EE 6平台的应用程序编程接口，包括必须的API、Java技术、编程约束、安全权限集以及Java SE标准。Java EE 6要求支持多种技术，如JDBC、JNDI、RMI-IIOP、JAX-WS等，同时也定义了应用程序组件的编程约束和安全需求。此外，文档还提到了推荐可选和可选的Java技术，如JAX-RPC和JAX-RS，以及Java持久化API、Bean Validation等标准。
来至: http://www.chinaitlab.com/Java/Special/java_ee/Chapter6.html
第6章 应用程序编程接口
本章描述了JavaTM平台企业版(Java EE)的API标准。Java EE要求为Java EE应用程序提供大量API，首先是Java核心API，还包含了很多其它的Java技术。
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.1 编程约束
Java EE编程模型划分了应用程序组件供应商和Java EE产品供应商的职责: 应用程序组件供应商致力于编写业务逻辑，而Java EE产品供应商致力于提供一套可管理的基础系统框架，使应用程序可以部署进去。
这种分工要求对应用程序组件在功能上进行约束。如果应用程序组件也提供同样的功能，就会与基础系统框架发生冲突，并且难于管理。
例如，倘若允许一个企业Bea
最低0.47元/天 解锁文章
扫一扫
863
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
