· Web容器和EJB容器是不同的，两者相对独立，可以是来自不同厂商的产品。这两种容器都可以使用企业服务。也就是说，无论是Web容器的组件还是EJB，都可以访问数据库连接、email服务、目录服务和消息服务。组件只能通过一个或者多个以驱动程序或适配器形式实现的企业服务访问EIS资源。
· 最好把所有应用组件频繁调用的用户自定义服务和库集中到一个独立的层。在图二的J2EE模型中，用户自定义的服务和库被合并到“自定义组件库”。这些库由用户自己开发，不属于标准J2EE应用服务器的一部分，一般它们会随着软件项目的成熟而日渐丰富。例如，配置文件工具库就是一个很好的例子：它根据指定的配置文件名字，打开该文件，然后以整数或字符串的形式返回指定的配置选项。
· 另一种常见的现象是，开发者在J2EE提供的核心企业服务的基础上编写自定义的访问例程。把这些自定义的服务访问例程组织成一个单独的“服务访问库”层是值得的。例如，假设我们在一个项目中用IBM的MQ Series作为消息系统。通常，我们会编写一些在JMS基础上访问MQ Series服务的简单API，例如给所有外发的消息加上企业标准的消息头。这时，最好把这些服务整理成“服务访问库”层的公用API，并让它们可被企业平台的所有应用调用。简而言之，服务访问库提供了J2EE API上的一层抽象，它们总是与特定的企业应用平台密切相关。
如前所述，在复杂的企业计算环境中，不同的J2EE组件应当担负不同的角色。下面我们就来看看具体情况。
Web容器组件:
· Servlet
Servlet是服务器端面向表现逻辑的组件，驻留在Web容器内。正如Applet扩展了浏览器的功能，Servlet扩展了Web服务器的功能——除了提供静态HTML之外，Servlet还提供编程和生成动态内容的功能。
Servlet能够处理来自客户端浏览器的请求，处理输入参数，把处理结果以HTTP应答的形式发送到客户端浏览器上显示出来。例如，Servlet可用来开发基于Web的简单认证系统，从客户端浏览器接收用户名字和密码，处理请求，再发回认证通过或不通过的应答。
除了接受来自客户端浏览器的请求之外，Servlet还能够响应其他Servlet的调用。虽然Servlet本身也能够生成发送给客户端的HTTP应答流，但是，就显示处理结果来说，JSP更擅长一些。
· JSP
JSP即Java Server Pages，它也是面向表现逻辑的组件，与Servlet一样，驻留在Web容器之内。但无论在适用场合还是功能方面，JSP与Servlet都有所不同。JSP页面是HTML和Java的混合物，即，JSP页面既能够包含HTML代码，也能够包含Java代码。JSP页面中的HTML代码被直接发送给客户端浏览器，而Java则被抽取出来由服务器处理。因此，JSP最适合于为HTML标签引入程序逻辑。
在JSP页面中，有一种结构化的、可重用的引用Java代码逻辑的途径，即使用JSP标记库。JSP标记库开发方便，能够更清楚地隔离Java代码和HTML代码。
JSP是对Servlet的补充和完善，经常用来显示Servlet的处理结果。但是，在一些应用设计中，只使用JSP（并充分有效地结合运用Javabean）而不使用Servlet的情形也很常见。
· Javabean
Javabean是基本的数据模型组件，在J2EE出现很久之前就已经被引入。在J2EE体系中，Javabean常常驻留在客户端或表现逻辑层，作为对Applet或JSP的补充。Javabean规范定义了Java代码如要成为Bean组件必须符合的条件。例如，一个简单的Java类如果定义了几个变量，并为这些变量定义了get_attribute()方法和set_attribute()方法，就可以认为是标准的Javabean组件。
Javabean与EJB除了名称相似之外，没有任何其他相似之处。EJB是一种完全不同的企业级Java应用组件。
EJB容器组件:
EJB是分布式可伸缩的业务逻辑组件，它们封装了企业Java工程的核心业务逻辑和数据模型元素。EJB驻留在称为EJB容器的特殊环境之内，EJB容器由应用服务器提供。J2EE规范定义了开发者编写的应用EJB与容器环境的关系（contract）。
开发EJB必须符合一定的接口要求，这些接口中的一部分方法由开发者实现，一部分由EJB容器提供者（或应用服务器厂商）实现。从某个方面来看，我们可以把EJB的这种接口要求看成一种隔离业务逻辑实现（开发者编写的方法）与应用基础结构（容器实现的方法）的途径。
EJB组件可以与任意其他EJB交互——不管对方是位于同一个容器之内，还是位于一个远程服务器的不同容器之内。EJB不仅可以调用所有的企业服务，还可以调用所有的自定义组件库和服务访问库。
针对不同的应用情况，EJB规范定义了几种不同的EJB类型，包括：无状态会话Bean、有状态会话Bean、实体Bean、消息驱动的Bean。
结合运用EJB、 Servlet和JSP，可构造出一个具有高度灵活性和可重用性的符合MVC特征的应用体系。
J2EE环境以企业服务的形式提供了支撑企业应用的各种基石，例如邮件、数据库连接、消息和事务处理等。这些最基本的服务以接口、类库、驱动程序、适配器等形式提供。就像一个操作系统一样，J2EE提供了在各种服务之上的一个公共的Java接口。各个底层服务的实现细节不尽相同，可能存在细微的差别，公共的Java接口使得应用的代码完全脱离了细节问题的纠缠。
Web容器和EJB容器之内的应用组件通过调用J2EE企业服务，来访问企业系统内可用的资源和服务。这类资源和服务的范围相当广泛，从简单的数据库访问到通过消息/CICS环境执行的大型主机访问，应有尽有。
J2EE服务API在厂商私有的服务之上提供了一层标准化的Java接口，例如数据库连接和目录访问等，从应用的角度来看，有效地隐藏了与实现有关的细节。因此，应用开发者只需考虑标准的API集，无需依赖于面向具体资源、厂商的API，从而方便了在多种不同的服务实现之间迁移。例如，从一个J2EE应用组件的角度来看，访问Sybase数据库和Oracle数据库的方式非常相似，只要按照数据库类型改用相应的JDBC驱动程序和访问数据库的URL即可。也就是说，程序员根本不必进行任何代码级的修改工作，就能够方便地访问不同的数据库。
JDBC
JDBC即Java DataBase Connectivity。通过JDBC API能够访问范围广泛的关系数据库系统。JDBC API为所有公共的数据库功能提供了一组标准化的接口，J2EE组件利用这组接口查询和更新数据库。这些接口的具体实现则由JDBC驱动程序负责。
因此，应用程序的代码不牵涉到与具体数据库类型有关的调用，从一种数据库切换到另一种数据库通常可以很方便地完成。
JNDI
在分布式环境中，要寻找和识别分散到整个网络上的各种资源，就要用到名称和目录服务。网络上的各种资源用唯一的名字绑定到分布式的分层树形目录结构中，客户程序通过访问目录服务获取一个指向目标资源的句柄。
JNDI（Java Naming and Directory Interface）建立了访问企业级名称和目录服务的标准，它在LDAP、Novell Directory Service和Active Directory Service等具体的目录服务之上，建立了一个标准的服务层，使得J2EE组件能够以一种一致的、标准的形式访问各种底层的目录服务。
JMS
在异种系统的集成中，例如把大型主机系统和其他传统系统连接到J2EE中间件组件，消息服务扮演着至关重要的角色。在这些截然不同的异构系统之间，建立通信链的关键就在于通信双方分别安装一个消息服务进程。应用软件与消息服务进程交互，消息服务进程再以点对点或异步的形式通过网络把消息传递给其他消息服务进程。
JMS（Java Messaging Service）在诸如IBM的MQ Series、Microsoft的MSMQ和TIBCO的Rendezvous之类的消息服务系统之上，建立了调用标准，即在这些私有的消息API调用之上定义了一个标准服务层，使得J2EE应用不再被绑定到实际执行消息服务的私有实现上。
Javamail/JAF
顾名思义，Javamail API是为J2EE组件提供e-mail服务的。它在具体的邮件服务实现（例如SMTP和POP3）之上，统一对各种可能用到的公共服务的访问形式，例如邮件格式、发送/接收邮件、附件处理等。
JavaMail 要求 Java 激活框架（JAF，Javabean Activation Framework）来处理复杂的数据类型，例如MIME。