组件框架。组件框架是一种中间件系统，它支持遵守一定标准的有不同组件构成的应用程序。应用组件被塞入这种确立它们运行环境和规定它们交互的框架中。这通常是通过容器，组件持有者来实现的。这种容器也提供通常需要的功能以实现命名，安全性，事务，和持久性！组件框架为组件的执行提供了一个集成的环境，因此显著的减少了在设计，实现，部署和维护应用程序时工作。现在工业上的组件框架标准以对象管理组的CORBA组件模型， SUN 公司的JAVA 2 Platform J企业版[J2EE]和微软公司的.NET标准，其中在企业里应用最为广泛的组件框架是2EEE。J2EE. J2EE是开发多层企业应用JAVA程序的综合性的标准。J2EE规范定义如下：
(1) 组件编程模型。
(2) 组件和主服务器的链接。 (3) 服务器提供给组件的服务。 (4) 各种各样的人物角色。
(5) 兼容性检验装置和编译测试程序。
在众多的服务列表中，消息通信，事务处理，命名机制和其它应用组件用到的服务是应用服务器必须提供的。用J2EE进行应用开发必须遵守经典的3层结构—表现层，业务层和企业信息系统层。属于各层的J2EE组件在开发时遵守具体的J2EE标准。 1、表现层或者网络层
这一层实际上又被分为客户端和服务器端。客户端包括浏览器，applets，Java应用程序等和负责和服务器端的表现层或者业务层进行交互。服务器端包括servlet、jsp和静态网页内容。这些组件负责把业务数据传递给终端用户。数据本身通常从业务层获得有时也从企业信息系统层
直接获得。表现层的服务器端通常通过Http协议来进行访问。 2、 业务层或者EJB层
这一层包含EJB，即企业应用的事务逻辑模型。这些组件提供了持久化机制和事务支持。EJB中的组件通过RMI被调用。在Java虚拟机调用或者异步的消息传递，取决与EJB组件的类型。EJB规范定义了很多种组件。它们在调用风格（同步和异步，本地和远程）与状态（完全状态，不可持久状态，可持久）方面不同。同步调用的EJB组件通过特定的工厂代理对象来表现自己。这种工厂代理对象通常被EJB部署者绑定在JNDI中。EJB对象允许或者本地EJB对象是特定EJB实例的代理。 3、企业信息系统或者数据层
这一层指的就是企业信息系统，比如关系数据库，ERP系统，消息系统等。业务层和持久层在资源适配器的帮助下与该层进行通信。资源适配器在Java连结结构中被定义。J2EE编程模型一直被认为是分布式的编程模型，在该模型中应用组件在J2EE服务器上运行并且彼此可以相互交互。经过初始化说明和第一个服务实现后，该技术，更显著的说EJB技术，已经明显地从纯粹的分布式计算模型转向了本地交互。转变的背后有合理的性能有关的原因，然而分布式的特征现在还存在。J2EE规范已经经过了好几次修订，现在最稳定的版本是1.3，1.4版本正处于重审阶段。我们应该把注意力放在1.3版本上，而实际上是在学习后者。适用与商业的J2EE实现可以大量的从BEA系统，IBM，Oracle等赞助商得到。包括JBoss和JOnAS在内的开源实现据称兼容性也不错。最近名单上有多出了新的Apache project Geronimo。 2.2 J2EE组件编程模型
在我们基本的J2EE组件前，先让我们强调一下什么是组件。软件组件是有一系列的具体的接口和明确的上下文环境构成。它可以被独立的部署而且易于被第三方重构。根据以上的定义，如下的组成J2EE应用程序的实体可以看作是软件组件：
(1) EJBS（会话，实体，消息驱动）。 (2) Web组件（Servlet、JSP）。. (3) 消息目的。 (4) 数据源。
EJB和Web组件被部署在由应用服务赞助商提供的容器中.它们有定义良好的容器规则来管理生命周期，线程，持久化和其他问题。EJB和Web组件都利用JNDI目录机制去寻找资源和它们想要交互的其EJB组件。目录被执行的JNDI环境被独立的由容器的每个组件加以维护。该种环境下的绑定机制通常由组件部署的解释者加以配置。消息目的地，像对话和队列，是由消息服务执行所提供的资源。数据源是提供给应用服务器的为事务组件进入到企业信息服务层提供数据接口，通常由被应用服务器管理的JDBC连接池实例化。一个J2EE编程者明确编写的项目只有EJB和Web组件。这些用户编写的组件彼此交互而且系统服务可以是明显的也可以是隐含的。例如，EJB开发者可以选择明确的事务区分方式，这种方式意味着开发者假设通过定义良好接口的事务经理服务平台来书写明确的程序交互。或者，开发者也可选择容器管理事务区分的方式。这样由于组件的事务行为通过他的描述者来定义而且全部用EJB容器来处理，因此作为一个隐式独立的EJB提供潜在的事务管理服务。 2.3 组件间的链接
2.3.1 远程交互
J2EE仅定义了三种可以在不同应用服务器间传递的基本组件间连接类型。在这三种情况下，通信通过特定的Java对象来完成。
(1) 远程EJB调用：同步的EJB调用通过主EJB对象和EJB对象接口来实现。
(2) Java连结器的外部连接：同步消息接收，同步和异步消息发送，用连接工厂和连接接口进行数据库查询。
(3) Java连接器的内部连接：异步消息传递进入消息驱动Bean只能使用Activation Spec 对象。
在前两个实例中，应用组件的开发者不仅书写执行在组件的运行时JNDI环境中的对象目录代码，而且书写发布方法调用，与远程的组件相互发送和接受消息。组件的运行时JNDI环境为每一个组件部署所创建。环境中的绑定在组件部署时由部署者进行初始化。这些绑定被假设为是静态的，因为规格中没有提供任何的容器和组件间协议去提示绑定发生了变化。在 Java连接器的内部通信情景下，Activation Spec 对象查询以及所有的相应的M容器隐式的完成。虽然查询的协议还没有被标准化，但是假设一个基于JMX或者JNDI的查询是合理的。 假设潜在的应用服务器提供了所有的设备去控制部署过程的每一步，那么在两个J2EE组件间确立一个连接需要涉及：
(1) 部署目标组件类。
(2) 创建一个特定的Java对象用作目标组件代理。 (3) 用组件的命名服务去绑定目标。 (4) 启动目标组件。 (5) 部署指定的组件类。
(6) 在主机的命名服务中，创建和进行指定组件的运行环境。 (7) 启动指定的组件。
然而，没有一个现代的应用服务器允许详细的控制所有组件类型的部署过程除了在它们的部署解释器中的有限的选择。因此我们的架构将使用简化的途径，它所依赖的特征在现在的大多数的应用服务器上都可以得到。
(1) 动态部署消息目的和数据源的能力。
(2) 创建和绑定特定的JNDI目标去访问消息目的和数据源的能力。 (3) 把初始绑定的EJB对象到EJB部署组件的能力。
(4) 用在参考组件运行环境中的JNDI指引去指出绑定的参考EJB的能力。
在只有相同的应用服务器的架构中，上面的功能对通过简单的部署控制解释器方式来控件间的连接已经足够了。然而，在不同应用服务器的环境下，由于跨服务器的类下载问题，这种简单的控制解释器的方式是不够的。 2.3.2 本地交互
一些组件间的交互可以发生在同一地点的相同应用服务器虚拟机的组件间，有时候甚至可以发生在只有相同容器的组件间。在Web层，这种交互的例子是 servlet到 servlet的请求转发。在EJB层，这种交互的例子是CMP实体关系和通过EJB本地接口的调用。这种本地部署所关心的不是在分布式架构中去表现而是去增强一致性。因此，这种架构把所有的本地的组件请求当作一个单一的组件加以对待。 2.4 部署J2EE应用程序和系统服务 2.4.1 部署应用程序组件