J2EE 是针对 Web Service 、 业务对象 、 数据访问和消息报传送的一组规范。这组应用编程接口确定了 Web 应用与驻留它们的服务器之间的通信方式。
J2EE 注重两件事，一是建立标准，使 Web 应用的部署与服务器无关；二是使服务器能控制构件的生命周期和其他资源，以便能够处理扩展 、 并发 、 事务处理管理和安全性问题。
J2EE 规范定义了以下几种构件：应用客户端构件 、 EJB构件 、 Servlets和JSP 、 Applet构件。 J2EE 采用的是多层分布式应用模型，意味着应用逻辑将根据功能分成几个部分，用户可以在相同或不同的服务器上安装不同应用构件组成的 J2EE 应用。这些层次可以参见图 1。
1 表示层
J2EE 客户端可以基于 Web ，也可以基于 Java 。 在 HTML 、 Java script 、 XML 等技术的帮助下， Web 浏览器可以支持强大 、 快速的用户界面。实际上，如果 HTML 足以捕获和显示应用所需的信息，则 HTML 为首选；如果 HTML 不足以达到此目的，则应该由客户端执行必要的捕获和操作。无论是 Applet 还是独立的 Java 程序，都可提供更丰富的图形用户界面。
Applet 还可以与中层通信，从而进一步加强程序控制和系统灵活性。分布式企业应用可以同时包括多种客户端，并且这些客户端都可以访问相同的业务逻辑。如图 2所示：当客户端是 HTML 时， JSP/Servlet 组合将成为能实现业务目标的真正客户端。当客户端是 Java 程序或基于 COM 程序时，它可以直接访问业务逻辑。
2 应用服务层
一般情况下，应用服务层包含表示层请求的表示逻辑和业务逻辑。表示层由显示 HTML 页面的 JSP 页面和 Servlets 实现。业务逻辑通过 RMI 对象和 EJB 实现。 EJB 依靠容器来实现事务处理 、 生命周期和状态管理 、 资源池 、 安全等问题，容器是 EJB 运行的环境。
2.1 Servlet
Java Servlet s 是指可以扩展 Web 服务器功能的程序 。 Servlet 从客户端接受请求，动态生成响应，然后将包含 HTML 或 XML 文档的请求发送给客户端 。 Servlet 类似于 CGI （公共网关接口），但 Servlet 使用 Java 类和流，更易于编写；由于 Servlet 可编译为 Java 字节码，在运行时， Servlet 例程驻留在内存中，每一个用户请求都生成一条新线程，故而它们的执行速度也更快。
2.2 JSP
JSP 页面是基于文本的 Servlet 开发方式。 JSP 页面具有 Servlet 的所有优点，如果与 Java Beans 类结合在一起，可以容易地将内容和显示逻辑分开。这使得无须了解 Java 代码就能更新页面的外观，更新 Java Beans 类的人也无须深入了解 Web 页面的设计。相对 CGI 而言，由于 CGI 依赖于平台，消耗资源更多，而且程序不能容易地访问参数数据等缺点，故而 JSP 页面和 Servlet 都比 CGI 应用广泛。
用户可以使用带 Java Beans 类的 JSP 页面定义 Web 模板，以便建立由外观相似的页面组成的 Web 站点，而 Java Beans 类负责组织数据。用户还可以借助标记和脚本将内容与应用逻辑捆绑在一起，或是嵌入一些 Java 小应用程序来实现一些简单的 Web 应用。
2.3 JMS
JMS 是支持 Java 程序之间信息交换的 J2EE 机制。这也是 Java 支持异步通信的方法 —— 发送者和接收者无须相互了解，因此可以独立操作。
JMS 支持两种消息传播模式：
点到点（ pointtopoint ）。基于消息队列，消息产生者将消息发送到队列中。消息消费者可以将自身与队列连接，以倾听消息。当消息到达队列时，客户可以从队列中取走，并给出响应。消息只能发送到一个队列，只能由一个消费者使用。消费者可以过滤消息，以便获得希望获得的消息。
出版和订阅（ publish/subscribe ）。消息生产者将消息发送到一个话题（ topic ），注册到此话题的消费者都能接收到这些消息。这种情况下，许多消费者都能接收到同样的消息。
2.4 JNDI
由于 J2EE 应用的构件可以独立运行，而且是在不同的设备上运行，因此客户端和应用服务器层代码必须以某种方式查找和参考其他代码和资源。客户端和应用代码使用 JNDI （ Java Namingand Directory Interface ， Java 命名和目录接口）查找用户定义对象（如 EJB ）和环境实体（ Environment Entities ）。在 JDBC2.0 中，数据源可以绑定到 JNDI 上，并允许应用程序访问。
2.5 事务处理
J2EE 事务处理模型可以在部署过程中定义组成一个事务处理的方法之间的联系，以便事务处理中的所有方法可以作为一个整体存在。如果用户希望完成这一任务，因为事务处理是一系列步骤，要么全部执行成功，要么全部回滚。例如， EJB 中可能有一系列方法，其作用是将资金从一个账户转到另一个账户，方法是借记第一个账户和贷记第二个账户。用户可能希望将全部操作作为一个整体，这样，如果借记之后，贷记之前出现故障，借记将滚回。
事务处理的属性在应用构件的集成过程中确定。它可以将各种方法组合成应用构件间的事务处理，即用户可以在 J2EE 应用中方便地重新分配应用构件的事务处理属性，无须修改代码和重新编译。
J2EE 事务处理 API （ JTA ）和 Java 事务处理服务（ JTS ）形成 J2EE 中事务处理支持的基础，而且更适合 EJB 和JDBC2.0。 JTS 是低级事务处理管理 API ，主要作用是将 Java 映射到对象管理组（ OMG ）的对象事务处理服务。 JTA 是高级 API ，包括两个部分：
-
事务处理接口。该接口允许事务处理定界，通过分布式构件由进行全局事务处理登记来完成工作。这种方法可以令多组操作组成一个事务处理 。
-
XA 资源接口。基于能处理分布式事务处理的 X/Open/ XA 接口，有时也称为两步提交事务处理，需要多种资源之间的协调，如数据库或序列。分布式事务处理由两步提交协议协调，可跨越用 XA 兼容的 JDBC 驱动程序访问的多个数据库，如针对Oracle/ XA 的 BEAWeb Logic Driver 等 。
EJB 规范定义了 Bean 管理的事务处理和 Container 管理的事务处理。当 EJB 用 Container 管理的事务处理部署时，应用服务器将自动协调事务处理。如果 EJB 由 Bean 管理事务处理部署， EJB 参数必须提供事务处理代码。基于 JMS 或 JDBC API的应用代码可以启动事务处理，或参与先前启动的事务处理。一个事务处理联系与执行应用的应用服务器线程相关，所有事务处理操作都在参与当前事务处理的线程上执行。多数情况下，用户无须担心用 JTA 编写明确事务处理的问题，因为此项工作由 JDBC 完成， EJB API由 Container 处理，并由应用部署说明符配置。这样，用户就可以将精力集中在事务处理设计而非实施上。
