Java EE 6 规范之平台概述

JavaTM平台企业版(Java EETM)的概述
体系结构
下图展示了Java EE平台体系结构中各元素间的既定关系。注意，此图展示的是元素间的逻辑关系，它并不代表这些元素在物理上的划分方式(不同的机器，进程，地址空间或虚拟机)。

每个独立矩形上半部分标明的容器是Java EE运行时环境，它为应用程序组件提供了必要的服务。这些服务基于矩形下半部分所列出的技术。例如, “Application Client Container”(应用程序客户端容器) 为应用程序客户端提供了链接JMS的接口，其它服务也是如此。所有这些服务会在后续章节详细描述。

这些箭头表示，必须提供对Java EE平台对应部分的访问。应用程序客户端容器为应用程序客户端提供了直接访问数据库的环境。这是通过连接数据库系统的Java API(JDBCTM API)来实现。类似地，Web容器为JSP页面和Servlet，EJB容器为企业Bean也提供了对数据库的访问.

正如图中所示，JavaTM平台标准版(Java SE)API由Java SE运行时环境提供，各种类型应用程序组件都基于这些API。

Profile(自定义规范)

Java EE 6规范提出了”Profile (自定义规范)”的概念。

Profile描绘了Java EE平台针对应用程序特定类的配置。

Profiles不是一个新的概念，也不是Java EE platform特有的。“Java Community Process Document 2.6)”(Java社区进程文档2.6)对Profile给出了如下定义: “一种规范，它参考了某个平台版本的规范，并附加零个或多个其它的JCP规范(它们尚未成为平台版本规范的组成部分)。它必须包含来自参考平台的API，但必须符合那个平台定义的引用规则。其它引进的规范必须在完全符合规则的前提下被引进。”

所有Java EE Profile共享一套公共特征，例如命名和资源注入，打包规则，安全标准等等。这就保证了“Java EE平台”旗下的所有产品的一致性。这也确保了熟悉某一Profile或整个平台的开发者可以很容易地适应其它的Profile，避免了技能和经验上的过度差异。

相对于上面概括的基本功能，Profile可以自由包含这个平台的任何技术，它的平台规范中提供了适用于这些技术的所有规则，可以单独使用也可以组合使用。

最后要强调的是，如果Profile只包含逐点技术，它们将比哪些有很少或没有接入点的API包多一点。作为代替，这里采用的Profile的定义应保证，每当本规范定义了技术组合的标准，这些标准会在所有基于Java EE Profile的产品中兑现。

举一个具体的例子, 让我们思考一下在Servlet容器中事务的使用。在孤立状态下，Servlet规范和JTA规范都没有为可移植的应用程序定义一个完整的编程模型。通过开拓自己的一套标准来结合Servlet和JTA，这种规范就可以弥补这一缺陷。所有基于此Profile并包含了这两种技术的Java EE产品都必须满足这些条件, 这就给应用程序开发者提供了一个更完整的编程模型，并为所有相关的Java EE Profile共享。

一个独立的规范--Java EE 6 Web Profile规范，定义了Java EE Web Profile，它是Java EE 6平台的第一项Profile。

可以依据JCP制定的规则和当前规范包含的规则来定义附加的Profile。特别是，一项Profile的确立必须提交一项Java Specification Request(JSR)，并在完成时公布自己的计划，它应无视平台自身或其它Profile在此时发生的任何修订。这确保了在定义和发布一项新的Profile或更新已有版本时拥有最大灵活性。

根据上面给出的Profile定义，一项Profile最终可以成为这个平台适当的子集或者超集，也可以与它在某一范围上部分重叠。这种灵活性保证了未来的Profile所覆盖的功能将远远超过这个平台规范最初的设想。

正如前面的段落所描述的，建立新的Profile是一项意义深远的任务。决定创建一项Profile时应该重视它潜在的不利因素，尤其是条件的分裂和开发者的困惑。一般而言，要建立一项Profile，需要开发者自然地支持，并且充分衡量应用程序能否从中获益。也推荐Profile在它自己的兴趣范围中扩展功能，尽量避免相互重叠或竞争的Profile出现。Profile可以使用Java EE 6 的平台特征，诸如可选的组件，可扩展性和修剪流程，以更好地实现他们预定的目标。

应用程序组件

Java EE运行时环境定义了Java EE产品必须支持的4种应用程序组件类型:

应用程序客户端是Java编程语言程序，它通常是执行在个人电脑上的图形用户界面(GUI)程序。应用程序客户端提供一种类似于本地应用程序的用户体验，并且能够访问Java EE中间层的所有功能。

Applet是运行在Web浏览器中的一种特殊的GUI组件，但它也可以运行在其它的支持Applet编程模式的应用程序或设备上。Applet可以用来为Java EE应用程序提供强有力的用户界面(简易的HTML页面也能用来为Java EE应用程序提供有限的用户界面)

Servlet, JSP页面, JSF应用程序, 过滤器和Web事件监听器通常运行在Web容器中，并且可以响应来自Web客户端的HTTP请求。Servlets, JSP 页面, JSF应用程序以及过滤器可以用来生成HTML页面，作为应用程序的用户界面。也可以用它们生成供其它应用程序组件使用的XML或其它格式的数据。一种特殊的Servlet使用SOAP/HTTP协议为Web服务提供支持。Servlet, 由JSP技术或JSF技术生成的页面,Web过滤器和Web事件监听器在本规范中统称为“Web组件”。Web应用程序由Web组件和其它数据(如HTML页面)组成。Web组件运行在Web容器中。Web服务器包含一个Web容器以及协议，安全等其它方面的支持，符合Java EE规范的要求。

Enterprise JavaBeans(EJB)组件运行在一个支持事务的环境中接受管理。企业Bean通常包含Java EE应用程序的业务逻辑。企业Bean可以使用SOAP/HTTP协议直接提供Web服务。

Java EE服务器为应用程序组件提供支持

Java EE服务器为符合标准的应用程序组件提供部署，管理和运行的支持。根据它们所以依赖的Java EE服务器，应用程序组件可以分成3类:

部署，管理和运行在Java EE服务器上的组件。这类组件包括Web组件和EJB组件。请查看这些组件各自的规范。
部署和管理在Java EE服务器上，但是被加载到客户机上运行的组件。这类组件包括诸如HTML页面和嵌入THML页面的Applet这样Web的资源。
部署和管理没有完全定义在本规范中的组件。应用程序客户端就属于这种类型。本规范的未来版本可能会更完整地定义应用程序客户端的部署和管理。请查看EE.10, “应用程序客户端”中对应用程序客户端的描述。
容器

容器为Java EE应用程序组件提供了运行时支持。容器提供了一份从底层Java EE API到应用程序组件的联合视图。Java EE应用程序组件不能直接地与其它Java EE应用程序组件交互。它们通过容器的协议和方法来达成它们之间以及它们与平台服务之间的交互。在应用程序组件和Java EE服务之间插入一个容器，这允许该容器透明地为组件注入必须的服务，例如声明式事务管理，安全检查，资源池和状态管理。

一个标准的Java EE产品会为每个应用程序组件类型提供一个容器: 应用程序客户端容器，Applet容器，Web组件容器, 企业Bean容器。
容器的标准

本规范要求容器提供一个由JavaTM平台标准版规范v6 (Java SE)定义的JavaTM兼容性运行时环境。Applet容器可以使用Java插件产品来提供这个环境，或者是使用本地环境。提供JDKTM 1.1 API的Applet容器超出了本规范的范围。

容器工具必须识别部署应用程序组件的打包文件格式。

容器由Java EE产品供应商提供。请查看2.11.1,“Java EE产品供应商”中对产品供应商角色的描述。

本规范定义了一套标准服务，每个Java EE产品必须提供支持。后面会对这些标准服务进行描述。Java EE容器提供了访问这些服务的API，供应用程序组件使用。本规范也描述了用连接器扩展Java EE服务的标准方法，以结合其它的非Java EE应用程序系统，例如大型机系统和ERP系统。

Java EE服务器

Java EE容器是底层服务器的组成部分。Java EE产品供应商通常使用现有的事务处理框架结合Java SE技术来实现Java EE服务器端功能。Java EE客户端功能通常构建于Java SE技术。

资源适配器

资源适配器是一个系统级的组件，它通常实现了对外部资源管理器的网络连接。资源适配器能够扩展Java EE平台的功能。这只需要实现一个Java EE标准服务API(例如JDBCTM驱动程序)，或者定义并实现一个能连接到外部应用程序系统的资源适配器就可以达到。资源适配器也可以提供完整的本地或本地资源的服务。资源适配器接口通过Java EE服务供应商接口(Java EE SPI)来连接Java EE平台。使用Java EE SPI连接到Java EE平台的资源适配器可以和所有的Java EE产品协同工作。

数据库

Java EE平台需要数据库来存储业务数据，通过JDBC API进行访问。可以从Web组件，企业Bean和应用程序客户端组件连接到数据库。不需要从Applet连接到数据库。

Java EE标准服务

Java EE标准服务包括下述服务(后面的章节会进行更详细地描述)。一些标准服务实际上由Java SE提供。

HTTP

HTTP客户端API定义在java.net包中。HTTP服务器端API由Servlet, JSP和JSF接口定义，以及被那些是Java EE平台组成部分的Web服务支持。

HTTPS

支持HTTP协议的客户端和服务器端API也同样支持带SSL协议的HTTP协议。

JavaTM Transaction API (JTA)

Java事务API由两部分组成:

一个应用程序级的边界划分接口，容器和应用程序组件用它来划分事务边界。
一个介于事务管理器和资源管理器之间的Java EE SPI级接口。
RMI-IIOP

RMI-IIOP由API组成，这些API允许使用不依赖于底层协议的RMI风格编程。作为那些API的实现，它同时支持Java SE本地RMI协议和CORBA IIOP协议。通过支持IIOP协议，Java EE应用程序就可以使用RMI-IIOP来访问CORBA服务，并且该应用程序兼容RMI编程约束(请查看RMI-IIOP的详细说明)。这样的CORBA服务通常由Java EE产品之外的组件定义，一般存在于以前遗留下来的系统中。只要求Java EE应用程序客户端可以使用RMI-IIOP API来直接定义它们自己的CORBA服务。通常这样的CORBA对象用于在访问其它的CORBA对象时进行回调。

当访问EJB组件时，Java EE应用程序必须使用RMI-IIOP API，特别是javax.rmi.PortableRemoteObject类的narrow方法，正如EJB规范所描述的。这些企业Bean可以独立于协议。需要注意的是，当使用依赖注入代替JNDI就行查找时，通常不需要使用narrow方法; 在注入对象引用之前，容器会为应用程序执行narrow方法。Java EE产品必须能够使用IIOP协议输出和访问企业Bean，这在EJB规范中被明确规定。对IIOP协议的支持使Java EE产品之间的交互成为可能，不过，Java EE产品也可以使用其它的协议。

Java IDL

通过使用IIOP协议，Java IDL允许Java EE应用程序组件调用外部的CORBA对象。这些 CORBA对象可以用任何语言编写，并且通常存在于Java EE产品外部。Java EE应用程序可以使用Java IDL来担当CORBA服务的客户端，但是只有Java EE应用程序客户端可以直接使用Java IDL提供CORBA服务。

JDBCTM API

JDBC API是用来连接关系数据库系统的API。JDBC API 有两个部分: 一个是应用程序组件用来访问数据库的应用级接口，另一个是JDBC驱动接口。不要求Java EE产品对JDBC驱动接口提供支持。JDBC驱动应该被打包成一个资源适配器，通过使用连接器API的能力来连接Java EE产品。JDBC API包含在了Java SE中, 但是本规范包含了对JDBC设备驱动的额外标准。

JavaTM Persistence API(JPA)

Java持久化API是用于持久化和对象/关系映射管理的标准API。通过使用一个Java域模型来管理关系型数据库，本规范为应用程序开发者提供了一种对象/关系映射功能。Java EE必须对Java持久化API提供支持。它也可以用在Java SE环境中。

JavaTM Message Service (JMS)
Java消息服务是用于消息发送的标准API，它支持可靠的“点对点”消息发送和“发布-订阅”模型。本规范要求JMS供应商同时实现“点对点”消息发送和”发布/订阅”型消息发送。

Java Naming and Directory InterfaceTM (JNDI)

JNDI API是用于命名和目录访问的标准API。它有两个部分: 一个是应用程序组件用来访问命名和目录服务的应用程序级接口，另一个是用于连接命名和目录服务供应商的服务供应商接口。JNDI API包含在Java SE中, 但是本规范为它定义了额外的标准。

JavaMailTM

许多互联网应用程序需要发送邮件的功能，因此Java EE平台包含了JavaMail API以及相应的JavaMail服务供应商API，使应用程序组件可以发送互联网邮件。JavaMail API 有两个部分: 一个是应用程序组件用于发送邮件的应用程序级接口，另一个是Java EE SPI级的服务供应商接口。

JavaBeansTM Activation Framework (JAF)
JAF API提供了一个框架来处理不同MIME类型的数据，它们源于不同的格式和位置。JavaMail API使用了JAF API。JAF API包含在Java SE中，因此它可以被Java EE应用程序使用。

XML处理

JavaTM API for XML Processing (JAXP)支持工业标准化的SAX和DOM API，用以解析XML文档，也支持XSLT转换引擎。 Streaming API for XML (StAX)为XML提供了一种“拉式解析”型的API。JAXP和StAX API都包含在Java SE中，因此它们可以被Java EE应用程序使用。

Java EETM连接器体系结构

连接器体系结构是一种Java EE SPI，它允许将资源适配器插入到任何Java EE产品中，这个资源适配器支持对EIS的访问。连接器体系结构定义了一套标准的介于Java EE服务器和资源适配器之间的系统级协议。这些协议包括:

连接管理协议，它让Java EE服务器将“连接”集中到底层EIS中，然后让应用程序组件与EIS连接。这种方式营造出了一种可伸缩的应用程序环境，它能支持大规模客户端对EIS系统的访问。
事务管理器和EIS之间的事务管理协议，它支持对EIS资源管理器的事务型访问。这个协议让Java EE服务器使用事务管理器来管理跨多个资源管理器的事务。这个协议也支持EIS资源管理器内部管理的事务，而不需要牵连外部的事务管理器。
安全协议，它实现了对EIS的安全访问。这个协议为安全的应用程序环境提供支持，它减少了对EIS的安全威胁并保护了EIS管理的重要信息资源。
线程管理协议，它允许资源适配器将工作委托给其它的线程，并允许应用程序服务器管理线程池。通过工作线程，资源适配器可以控制安全上下文和事务上下文。
消息传递协议，它允许资源适配器将消息传递到消息驱动Bean，此Bean不依赖于特定的消息格式，消息语义和传递消息的底层结构。这个协议也充当标准消息提供方即插即用协议，它允许通过资源适配器将消息提供方插入到任何Java EE服务器中。
事务传递协议，它允许资源适配器将一个被导入的事务上下文传递给Java EE服务器，使得服务器和任意应用程序组件的交互成为被导入的事务的组成部分。这个协议维护了被导入事务的ACID(atomicity, consistency, isolation, durability)属性。
可选协议，它提供了一个介于应用程序和资源适配器之间的通用命令接口。
安全服务

JavaTM Authentication and Authorization Service (JAAS)使服务能够基于用户进行验证和实施访问控制。它实现了一个Java版的标准的的Plugable Authentication Module (PAM)框架，并支持基于用户的授权。JavaTM Authorization Service Provider Contract for Containers (JACC) 定义了Java EE应用程序服务器和授权服务提供方之间的协议，允许将自定义的授权服务提供方插入任何Java EE产品中。

Web服务

Java EE为Web服务的客户端和终端提供了完整的支持。一些Java技术协同为Web服务提供支持。通过使用SOAP/HTTP协议，Java API for XML Web Services (JAX-WS)和Java API for XML-based RPC (JAX-RPC)都能为Web服务的调用提供了支持。新的JAX-WS是支持Web服务的首选API，它出现在JAX-RPC之后。JAX-WS 提供了更广泛的Web服务功能，并提供对多重“绑定-协议”的支持。当使用绑定于HTTP协议的SOAP1.1协议时，JAX-WS和JAX-RPC完全可以协同工作，但要受到WS-I基本概要规范的约束。

JAX-WS和Java Architecture for XML Binding (JAXB)定义了Java类和用于SOAP调用的XML之间的映射，并且对XML Schema提供了100%的支持。SOAP with Attachments API for Java (SAAJ) 对操作低层SOAP消息提供支持。Java EE规范中的Web服务标准完整地定义了Web服务的客户端和终端在Java EE中的部署，以及使用企业Bean的Web服务终端的实现。Web服务元数据规范定义了相应的Java语言注解来简化Web服务的开发。Java API for XML Registries (JAXR) 使客户端可以访问XML注册服务器。

Java API for RESTful Web Services (JAX-RS)对使用REST风格的Web服务提供了支持。RESTful Web服务更符合Web的设计风格，并且常常更易于使用多种编程语言对其进行访问。JAX-RS提供了一个简单的高层API来写入这样的Web服务，以及一个低层API来控制Web服务交互中的所有细节。

管理

Java 2平台企业版管理规范中定义了一种API，通过一种特殊的管理型企业Bean来管理Java EE服务器。JavaTM Management Extensions (JMX) API也提供了一些管理上的支持。

部署
Java 2平台企业版部署规范中定义了部署工具和Java EE产品之间的协议。Java EE产品提供了运行在部署工具上的插入式组件，它允许部署工具将应用程序部署到Java EE产品中。

部署工具提供了插入式组件可以使用的服务。

图 2-2 Java EE的交互

互用性

上面提到的很多API都提供了与非Java EE平台组件之间的互用性。例如，外部的Web服务或CORBA服务。

图 2-2 展示了Java EE平台的互通能力。 (箭头的方向标示了组件间的“客户端→服务器”关系)

产品标准的灵活性

本规范没有要求Java EE产品必须由单个程序，单个服务器，甚至是单个机器实现。一般情况下，本规范没有描述服务或功能在机器，服务器或进程上的划分。只要符合本规范的要求，Java EE产品供应商可以用他们认为最合适的方式来划分功能。Java EE产品必须能够部署应用程序组件，此组件的运行应符合本规范语义的描述

典型的低端Java EE产品会支持Applet，这需要使用主流浏览器中的Java插件，它也会支持在它们自己的Java虚拟机中的每个应用程序客户端，同时，它还会提供一个单独的服务器来支持Web组件和企业Bean。高端Java EE产品将服务器组件分摊到多个服务器上，它们每个都可以通过服务器集群来实现分布式和负载均衡。本规范不限定或阻止它们所进行的任何配置。

符合本规范要求的Java EE产品可能有多种配置和实现。当成功部署到这些产品后，可移植的Java EE应用程序就可以正确地工作。

Java EE产品的扩展

本规范描述了可用于所有Java EE产品的功能的最小集合。Java EE Profile可以包含这些功能中的部分或全部，正如EE.9,“Profile”中所描述的。要实现完整的Java EE平台，产品必须提供这个集合中的所有功能(请查看EE.9.7,“完整的Java EE产品标准”)。大多数Java EE产品会提供比本规范的最低要求更多的功能。本规范对产品提供的扩展性做了很少量的限制。特别是，它对Java API扩展性的限制与Java SE是相同的。Java EE 产品不可以向本规范定义的Java编程语言包中添加类，也不可以向特定类中添加方法或是用其它方式修改它们的签名。

然而，许多其它的扩展是允许的。Java EE产品可以提供额外的Java API，可以是其它的Java可选包，也可以是别的包(恰当地命名)。Java EE产品可以包含对规范外的其它协议或服务的支持。Java EE产品可以支持其它语言编写的应用程序，也可以支持与其它平台或应用程序的连接。

当然，可移植的应用程序不应使用任何对平台的扩展。使用本规范没有定义的功能的应用程序的可移植性将会降低。依赖于这种功能造成的可移植性的丧失所带来的影响可能是很小的，但也可能是不容忽视的。文档--“用Java2平台企业版设计企业级应用程序”提供了相关的信息来帮助应用程序开发者构建可移植的应用程序。并且也建议了怎样最好地来管理非可移植性代码的使用，当这些功能必须被使用的时候。

我们期望Java EE产品在服务品质的各个方面都有很大程度的提升，表现出活跃的竞争力。让产品能够提供不同级别的性能，可伸缩性，健壮性，可用性和安全性。在某些情况下，本规范要求了最低限度的服务水平。本规范的未来版本可能会允许应用程序描述它们在这些领域的要求。

平台角色

本节描述了典型的Java平台企业版的角色。在实际应用中, 组织机构可以划分不同的角色功能来适应自己应用程序开发和部署的工作流程。

本规范稍后会对这些角色进行更详细的描述。这些角色的相关子集在EJB, JSP和Servlet规范中有相应的描述，这些子规范也属于Java EE规范的一部分。

Java EE 产品供应商

Java EE产品供应商是Java EE产品的实现者和提供者，包括组件容器，Java EE平台 API和本规范中定义的其它的功能。一个Java EE产品供应商通常是一个操作系统厂商，一个数据库系统厂商，一个应用程序服务器厂商，或一个Web服务器厂商。Java EE产品供应商透过容器使Java EE API对应用程序组件可用。产品供应商总是将他们的实现建立在现有的基础设施之上。

Java EE产品供应商必须提供应用程序组件到网络协议的映射，正如本规范所指定的。Java EE产品可以自由地实现接口，在具体的实现方式上，本规范没有作出明确的限定。

Java EE 产品供应商必须提供相应的工具来部署和管理应用程序。部署工具允许部署者(参见2.11.4,“部署者”)将应用程序组件部署到Java EE产品中。管理工具允许系统管理员(参加2.11.5,“系统管理员”)管理Java EE产品和部署在其中的应用程序。本规范没有对这些工具的形式作出限定。

应用程序组件供应商

应用程序组件供应商有多种任务可供选择，包括HTML文档设计者，文档程序员和企业Bean开发者。这些任务需要使用工具来生产Java EE应用程序和组件。

应用程序组装者

应用程序组装者将应用程序组件供应商开发的一套组件组装成一个完整的Java EE应用程序，以企业归档文件(.ear)的形式交付。应用程序组装者一般会使用平台供应商或工具供应商提供的GUI工具。应用程序组装者负责提供组装操作说明，描述应用程序的外部依赖关系，以便部署者在部署过程中进行处理。

部署者

部署者负责将应用程序客户端，Web应用程序和EJB组件部署到一个特定的运行环境中。部署者使用由Java EE产品供应商提供的工具来完成部署任务。部署工作通常有3个步骤:

1. 在安装期, 部署者将应用程序资料移动到服务器上，生成容器特有的附加类和接口，使容器能够在运行时管理这些应用程序组件。然后将应用程序组件以及这些附加类和接口安装到相应的Java EE容器中。

2.在配置期, 需要理清应用程序组件供应商声明的外部依赖关系并遵循应用程序组装者定义的操作说明。例如，部署者负责将应用程序组装者定义的安全角色映射到目标运行环境中存在的用户组和账号。

3.最后，部署者启动新安装和配置的应用程序。

在某些情况下, 有特殊资格的部署者可以在部署期间自定义应用程序组件的业务逻辑。例如，使用Java EE产品提供的工具，部署者可以用简单的应用程序代码封装企业Bean的业务方法，或自定义JSP页面的外观。

部署者的产出是Web应用程序，企业Bean，Applet和应用程序客户端，它们为目标运行环境定制，并已经部署到了特定的Java EE容器中。

系统管理员

系统管理员负责配置和管理企业的运作和网络基础设施。系统管理员也负责观察已部署的Java EE应用程序的运行时状态。系统管理员通常使用Java EE产品供应商提供的运行时监测管理工具来完成他们的任务。

工具供应商

工具供应商提供开发和打包应用程序组件的工具。各种工具事先应与Java EE平台支持的应用程序组件类型一致。平台独立的工具可以用于应用程序的整个部署阶段和对应用程序服务器的管理和监测。

系统组件供应商

系统组件供应商可以提供多种系统级组件。连接器体系结构定义了一些基本的API，用它们来提供多种类型的资源适配器。这些资源适配器可以连接到已有的多种类型的企业信息系统，这包括数据库系统和消息系统。系统级组件的另一种类型是授权策略提供方，正如Java容器授权服务提供方协议规范所定义的。

平台协议

本节描述了Java平台企业版协议，实现了完整的Java EE平台的产品供应商必须完全支持这些协议。Java EE Profile可以包含这些功能的部分或全部，在EE.9,“Profiles”中有详细的描述。
Java EE API

Java EE API定义了应用程序组件和Java EE平台之间的协议。此协议同时指定了运行时和部署时的接口。

Java EE产品供应商必须以某种方式实现Java EE API，此方式应支持本规范描述的语义和策略。应用程序组件供应商提供符合这些API和策略的组件。

Java EE Service Provider Interfaces (SPI)

Java EE服务供应商接口(SPI)定义了Java EE平台和服务提供方之间的协议，这些服务提供方可以被插入到Java EE产品中。连接器API定义的服务供应商接口可以将资源适配器整合到Java EE应用程序服务器上。实现了连接器API的资源适配器组件可以被连接器调用。Java EE授权API定义的服务供应商接口可以将安全授权机制整合到Java EE应用程序服务器上。

Java EE产品供应商必须以某种方式实现Java EE SPI。此方式支持本规范中描述的语义和策略。服务提供方组件的供应商(例如，连接器供应商)应该提供符合这些SPI和策略的组件。
网络协议

本规范定义了应用程序组件到工业标准网络协议的映射。此映射允许客户端从尚未安装Java EE产品技术的系统访问应用程序组件。关于网络协议对互用性的支持，参见EE.7,“互用性”。

要求Java EE产品供应商公布应用程序组件使用的行业标准协议。本规范定义了Servlet和JSP页面到HTTP和HTTPS协议的映射，以及EJB组件到IIOP和SOAP协议的映射。

部署描述符和注解

用部署描述符和Java语言注解可以将应用程序组件的需求传达给部署者。部署描述符和类文件的注解是应用程序组件供应商(或组装者)和部署者之间的协议。应用程序组件供应商或组装者必须在组件的部署描述符或类文件注解中说明应用程序组件的外部资源需求，安全需求，环境参数等等。Java EE产品供应商必须提供一个部署工具来解释Java EE部署描述符和类文件注解，并允许部署者将应用程序组件的需求映射到特定Java EE产品的功能和环境上。

J2EE 1.3中的变化

J2EE 1.3规范用新增的企业级整合功能扩展了J2EE平台。连接器API支持对外部企业信息系统的整合。现在，JMS供应商的存在是必须的。JAXP API对处理XML文档提供了支持。JAAS API对连接器API提供了安全支持。EJB规范现在需要对互用性提供支持，这需要使用IIOP协议。

EJB规范有了重大的改变。EJB 规范有了一个新的受容器管理的持久化模型，对消息驱动Bean和本地企业Bean提供了支持。

同样也更新了其它的J2EE API。请查看它们各自的API规范了解详细信息。 最后，J2EE 1.3要求支持J2SE 1.3

J2EE 1.4中的变化

J2EE 1.4的主要焦点是对Web服务提供支持。JAX-RPC和SAAJ API提供了对基本Web服务互用性的支持。J2EE Web服务规范描述了提供和使用Web服务的J2EE应用程序的打包和部署标准。EJB规范也有了新的扩展，通过使用无状态会话Bean实现对Web服务的支持。JAXR API 支持对注册和存储的访问。

J2EE 1.4中添加了几个新的API。J2EE管理和部署API使增强后的工具能够支持J2EE产品。JMX API支持J2EE管理型API。J2EE容器授权协议为安全提供方提供了一个SPI。

许多J2EE API在J2EE 1.4中得到增强。J2EE 1.4构建在J2SE 1.4上。增强后的JSP规范简化了Web应用程序的部署。连接器API现在支持对异步消息系统的整合，包括插入JMS提供方。

J2EE平台的更新包括: 对部署独立于任何应用程序的类库的支持, 部署描述符从DTD向XML Schema的转换。

其它的J2EE API也得到了增强。详细信息参见它们各自的规范。

Java EE 5中的变化

首先，你可能也注意到了，这个平台发布了一个新的名称--Java平台企业版，简称 Java EE。这个新名称去掉了令人费解的“2”，而这个简称强调了这是一个Java平台。以前的版本仍然使用旧的名称“J2EE”。

Java EE 5 的焦点是简化开发。为了帮助刚从Java EE起步的程序员简化开发流程或开发中小型应用，我们大量使用了在J2SE5.0中引入的Java语言注解。

在大多数情况下，注解减少甚至消除了对Java EE部署描述符的处理。甚至大型应用程序也能从注解所带来的简便性中受益。

注解最主要的应用之一是为Java EE组件指定资源注入和其它依赖关系。注入提高了当前JNDI的查找能力，为应用程序提供了一个新的简化模型，使它从运行环境中访问必需资源的效率得到提高。注入也可以和部署描述符一起使用，使部署者可以自定义或重写应用程序源代码中的资源设置。

通过使用注解，优化的默认值将发挥更大的效用。在大多数没有注解或部署描述符的情况下，优化的默认行为和优化的默认配置，可以使大多数应用程序能在大部分时间内获得想要的行为。但是，当默认值不被应用程序需要时，一个简单的注解就可以指定所需的行为或配置。

注解与优化的默认值的组合大大地简化了使用EJB技术的应用程序和使用Web服务的应用程序的部署。现在，开发企业Bean相当地简单。通过使用Web服务元数据规范定义的注解，Web服务的开发也变得更加容易。

Web服务领域的发展日新月异。为了对最新的Web服务提供支持，JAX-RPC演变成了JAX-WS技术，它大量使用JAXB技术将Java对象绑定到XML数据。JAX-WS和JAXB都是本平台的新内容。

Java EE 5新增的主要内容还包括JSTL和JSF技术，用它们可以简化Web应用程序的部署。还有EJB3.0专家组开发的Java持久化API，它极大地简化了从Java对象到数据库的映射。

另外还增加了用于解析XML的StAX API。先前版本的大多数API都得到了或多或少地改善。