当前J2EE项目中，面临的一个共同问题就是如果控制事务的并发访问，虽然有些持久层框架已经为我们做了很多工作，但是理解原理，对于我们开发来说还是很有用处的。

AD：51CTO云计算架构师峰会 抢票进行中！

当前J2EE项目中，面临的一个共同问题就是如果控制事务的并发访问，虽然有些持久层框架已经为我们做了很多工作，但是理解原理，对于我们开发来说还是很有用处的。

本文结合Hibernate以及JPA标准，对J2EE当前持久层设计所遇到的几个问题进行总结：

事务并发访问控制策略

当前J2EE项目中，面临的一个共同问题就是如果控制事务的并发访问，虽然有些持久层框架已经为我们做了很多工作，但是理解原理，对于我们开发来说还是很有用处的。

事务并发访问主要可以分为两类，分别是同一个系统事务和跨事务访问的并发访问控制，其中同一个系统事务可以采取乐观锁以及悲观锁策略，而跨多个系统 事务时则需要乐观离线锁和悲观离线锁。在讨论这四种并发访问控制策略之前，先需要明确一下数据库事务隔离级别的问题，ANSI标准规定了四个数据库事务隔 离级别，它们分别是：

读取未提交(Read Uncommitted)

这是最低的事务隔离级别，读事务不会阻塞读事务和写事务，写事务也不会阻塞读事务，但是会阻塞写事务。这样造成的一个结果就是当一个写事务没有提交的时候，读事务照样可以读取，那么造成了脏读的现象。

读取已提交(Read Committed)

采用此种隔离界别的时候，写事务就会阻塞读事务和写事务，但是读事务不会阻塞读事务和写事务，这样因为写事务会阻塞读取事务，那么从而读取事务就不能读到脏数据，但是因为读事务不会阻塞其它的事务，这样还是会造成不可重复读的问题。

可重复读(Repeatable Read)

采用此种隔离级别，读事务会阻塞写事务，但是读事务不会阻塞读事务，但是写事务会阻塞写事务和读事务。因为读事务阻塞了写事务，这样以来就不会造成不可重复读的问题，但是这样还是不能避免幻影读问题。

序列化(serializable)

此种隔离级别是最严格的隔离级别，如果设置成这个级别，那么就不会出现以上所有的问题(脏读，不可重复读，幻影读)。但是这样以来会极大的影响到我 们系统的性能，因此我们应该避免设置成为这种隔离级别，相反的，我们应该采用较低的隔离界别，然后再采用并发控制策略来进行事务的并发访问控制)。

其实我们也可以把事务隔离级别设置为serializable，这样就不需要采用并发控制策略了，数据库就会为我们做好一切并发控制，但是这样以来 会严重影响我们系统的伸缩性和性能，所以在实践中，我们一般采用读取已提交或者更低的事务隔离级别，配合各种并发访问控制策略来达到并发事务控制的目的。 下面总结一下常用的控制策略：

1 乐观锁

乐观锁是在同一个数据库事务中我们常采取的策略，因为它能使得我们的系统保持高的性能的情况下，提高很好的并发访问控制。乐观锁，顾名思义就是保持 一种乐观的态度，我们认为系统中的事务并发更新不会很频繁，即使冲突了也没事，大不了重新再来一次。它的基本思想就是每次提交一个事务更新时，我们想看看 要修改的东西从上次读取以后有没有被其它事务修改过，如果修改过，那么更新就会失败,。

最后我们需要明确一个问题，因为乐观锁其实并不会锁定任何记录，所以如果我们数据库的事务隔离级别设置为读取已提交或者更低的隔离界别，那么是不能避免不可重复读问题的(因为此时读事务不会阻塞其它事务)，所以采用乐观锁的时候，系统应该要容许不可重复读问题的出现。

了解了乐观锁的概念以后，那么当前我们系统中又是如何来使用这种策略的呢?一般可以采用以下三种方法：

版本(Version)字段：在我们的实体中增加一个版本控制字段，每次事务更新后就将版本字段的值加1.

时间戳(timestamps)：采取这种策略后，当每次要提交更新的时候就会将系统当前时间和实体加载时的时 间进行比较，如果不一致，那么就报告乐观锁失败，从而回滚事务或者重新尝试提交。采用时间戳有一些不足，比如在集群环境下，每个节点的时间同步也许会成问 题，并且如果并发事务间隔时间小于当前平台最小的时钟单位，那么就会发生覆盖前一个事务结果的问题。因此一般采用版本字段比较好。

基于所有属性进行检测：采用这种策略的时候，需要比较每个字段在读取以后有没有被修改过，所以这种策略实现起来 比较麻烦，要求对每个属性都进行比较，如果采用hiernate的话，因为Hibernate在一级缓存中可以进行脏检测，那么可以判断哪些字段被修改 过，从而动态的生成sql语句进行更新。

下面再总结一下如何在JDBC和Hibernate中使用乐观锁：

JDBC中使用乐观锁：如果我们采用JDBC来实现持久层的话，那么就可以采用以上将的三种支持乐观锁的策略，在实体中增加一个version字段或者一个Date字段，也可以采用基于所有属性的策略，下面就采用version字段来做一演示：

假如系统中有一个Account的实体类，我们在Account中多加一个version字段，那么我们JDBC Sql语句将如下写：

  1. Select a.version....from Account as a where (where condition..)  
  2. Update Account set version = version+1.....(another field) where version =?...(another contidition) 

这样以来我们就可以通过更新结果的行数来进行判断，如果更新结果的行数为0，那么说明实体从加载以来已经被其它事务更改了，所以就抛出自定义的乐观锁定异常(或者也可以采用Spring封装的异常体系)。具体实例如下：

  1. .......  
  2. int rowsUpdated = statement.executeUpdate(sql);  
  3. If(rowsUpdated= =0){  
  4. throws new OptimisticLockingFailureException();  
  5. }  
  6. ........ 

在使用JDBC API的情况下，我们需要在每个update语句中，都要进行版本字段的更新以及判断，因此如果稍不小心就会出现版本字段没有更新的问题，相反当前的 ORM框架却为我们做好了一切，我们仅仅需要做的就是在每个实体中都增加version或者是Date字段。

Hibernate中使用乐观锁：如果我们采用Hibernate做为持久层的框架，那么实现乐观锁将变得非常容易，因为框架会帮我们生成相应的sql语句，不仅减少了开发人员的负担，而且不容易出错。下面同样采用version字段的方式来总结一下：

同样假如系统中有一个Account的实体类，我们在Account中多加一个version字段，

  1. public class Account{  
  2. Long id ;  
  3. .......  
  4. @Version //也可以采用XML文件进行配置  
  5. Int version  
  6. .......  
  7. } 

这样以来每次我们提交事务时，hibernate内部会生成相应的SQL语句将版本字段加1，并且进行相应的版本检测，如果检测到并发乐观锁定异常，那么就抛出StaleObjectStateException.

2 悲观锁

所谓悲观锁，顾名思义就是采用一种悲观的态度来对待事务并发问题，我们认为系统中的并发更新会非常频繁，并且事务失败了以后重来的开销很大，这样以 来，我们就需要采用真正意义上的锁来进行实现。悲观锁的基本思想就是每次一个事务读取某一条记录后，就会把这条记录锁住，这样其它的事务要想更新，必须等 以前的事务提交或者回滚解除锁。

最后我们还是需要明确一个问题，假如我们数据库事务的隔离级别设置为读取已提交或者更低，那么通过悲观锁，我们控制了不可重复读的问题，但是不能避 免幻影读的问题(因为要想避免我们就需要设置数据库隔离级别为Serializable,而一般情况下我们都会采取读取已提交或者更低隔离级别，并配合乐 观或者悲观锁来实现并发控制，所以幻影读问题是不能避免的，如果想避免幻影读问题，那么你只能依靠数据库的serializable隔离级别(幸运的是幻 影读问题一般情况下不严重)。

下面就分别以JDBC和Hibernate来总结一下：

JDBC中使用悲观锁：在JDBC中使用悲观锁，需要使用select for update语句，假如我们系统中有一个Account的类，我们可以采用如下的方式来进行：

  1. Select * from Account where ...(where condition).. for update. 

当使用了for update语句后，每次在读取或者加载一条记录的时候，都会锁住被加载的记录，那么当其他事务如果要更新或者是加载此条记录就会因为不能获得锁而阻塞， 这样就避免了不可重复读以及脏读的问题，但是其他事务还是可以插入和删除记录，这样也许同一个事务中的两次读取会得到不同的结果集，但是这不是悲观锁锁造 成的问题，这是我们数据库隔离级别所造成的问题。

最后还需要注意的一点就是每个冲突的事务中，我们必须使用select for update 语句来进行数据库的访问，如果一些事务没有使用select for update语句，那么就会很容易造成错误，这也是采用JDBC进行悲观控制的缺点。

Hibernate中使用悲观锁：相比于JDBC使用悲观锁来说，在Hibernate中使用悲观锁将会容易很多，因为Hibernate有API让我们来调用，从而避免直接写SQL语句。下面就Hibernate使用悲观锁做一总结：

首先先要明确一下Hibernate中支持悲观锁的两种模式LockMode.UPGRADE以LockMode.UPGRADE_NO_WAIT.(PS:在JPA中，对应的锁模式是LockModeType.Read，这与Hibernate是不一样的呵呵)

假如我们系统中有一个Account的类，那么具体的操作可以像这样：

  1. .......  
  2. session.lock(account, LockMode.UPGRADE);  
  3. ...... 

或者也可以采用如下方式来加载对象：

  1. session.get(Account.class,identity,LockMode.UPGRADE). 

这样以来当加载对象时，hibernate内部会生成相应的select for update语句来加载对象，从而锁定对应的记录，避免其它事务并发更新。

以上两种策略都是针对同一个事务而言的，如果我们要实现跨多个事务的并发控制就要采用其它两种并发控制策略了，下面做一总结：

C++与java是两种完全不同风格的东西，C++是由程序员创造的，由程序员完善的，然后才出的标准的，也就是说C++的标准完全落后与C++的 发展。java恰好相反，它是先有标准(可能还没有实现)，然后后有的实现，而且它是由公司主导开发的，虽然现在开源了，但是标准并不是谁都能定的。这就 造就了C++是百花齐放，博大精深，很少有人敢说自己C++ 很厉害。

java却是另外的一种感觉，一切都规定好了，你只需要按照规定去做，符合标准才可以的。所以C++是那种既可以做的堂堂正正，博大精深(比如标准 库)，又可以实现的匪夷所思，天马行空(写 Boost库的人太牛了)。java不行，java要求如此只能如此，不能越雷池一步。

 

J2EE是一套全然不同于传统应用开发的技术架构，包含许多组件，主要可简化且规范应用系统的开发与部署，进而提高可移植性、安全与再用价值。本文介绍了J2EE中的13中核心技术，一起来了解一下吧！

AD：51CTO云计算架构师峰会 抢票进行中！

为了联系实际，GOULD基于WEBLOGIC应用服务器（来自BEA SYSTEMS公司的一种广为应用的产品）环境来介绍J2EE的这些技术。JAVA最初是在浏览器和客户端机器中粉墨登场的。当时，很多人质疑它是否适合做服务器端的开发。现在，随着对JAVA2平台企业版（J2EE）第三方支持的增多，JAVA被广泛接纳为开发企业级服务器端解决方案的首选平台之一。

J2EE平台由一整套服务（SERVICES）、应用程序接口（APIS）和协议构成，它对开发基于WEB的多层应用提供了功能支持。在本文中我将 解释支撑J2EE的13种核心技术：JDBC, JNDI, EJBS, RMI, JSP, JAVA SERVLETS, XML, JMS, JAVA IDL, JTS, JTA, JAVA MAIL 和 JAF，同时还将描述在何时、何处需要使用这些技术。当然，我还要介绍这些不同的技术之间是如何交互的。此外，为了让您更好地感受J2EE的真实应用，我 将在WEBLOGIC应用服务器（来自BEA SYSTEMS公司的一种广为应用的产品）环境下来介绍这些技术。不论对于WEBLOGIC应用服务器和J2EE的新手，还是那些想了解J2EE能带来什 么好处的项目管理者和系统分析员，相信本文一定很有参考价值。

J2EE事务并发控制策略总结_开发

一、宏观印象: 分布式结构和J2EE 　　

过去，二层化应用--通常被称为CLIENT/SERVER应用--是大家谈论的最多的。在很多情况下，服务器提供的唯一服务就是数据库服务。在这 种解决方案中，客户端程序负责数据访问、实现业务逻辑、用合适的样式显示结果、弹出预设的用户界面、接受用户输入等。CLIENT/SERVER结构通常 在第一次部署的时候比较容易，但难于升级或改进，而且经常基于某种专有的协议（通常是某种数据库协议）。它使得重用业务逻辑和界面逻辑非常困难。更重要的 是，在WEB时代，二层化应用通常不能体现出很好的伸缩性，因而很难适应INTERNET的要求。

SUN设计J2EE的部分起因就是想解决二层化结构的缺陷。于是J2EE定义了一套标准来简化N层企业级应用的开发。它定义了一套标准化的组件，并 为这些组件提供了完整的服务。J2EE还自动为应用程序处理了很多实现细节，如安全、多线程等。用J2EE开发N层应用包括将二层化结构中的不同层面切分 成许多层。一个N层化应用A能够为以下的每种服务提供一个分开的层：显示：在一个典型的WEB应用中，客户端机器上运行的浏览器负责实现用户界面。

动态生成显示: 尽管浏览器可以完成某些动态内容显示，但为了兼容不同的浏览器，这些动态生成工作应该放在WEB服务器端进行，使用JSP、SERVLETS，或者XML（可扩展标记语言）和XSL（可扩展样式表语言）。

业务逻辑：业务逻辑适合用SESSION EJB（后面将介绍）来实现。

数据访问：数据访问适合用ENTITY EJB（后面将介绍）和JDBC来实现。

后台系统集成: 后台系统的集成可能需要用到许多不同的技术，至于何种最佳需要根据后台系统的特征而定。

您可能开始诧异：为什么有这么多的层？事实上，多层方式可以使企业级应用具有很强的伸缩性，它允许每层专注于特定的角色。例如，让WEB服务器负责提供页面，应用服务器处理应用逻辑，而数据库服务器提供数据库服务。

由于J2EE建立在JAVA2平台标准版（J2SE）的基础上，所以具备了J2SE的所有优点和功能。包括“编写一次，到处可用”的可移植性、通过 JDBC访问数据库、同原有企业资源进行交互的CORBA技术以及一个经过验证的安全模型。在这些基础上，J2EE又增加了对EJB（企业级JAVA组 件）、JAVA SERVLETS、JAVA服务器页面（JSPS）和XML技术的支持。

二、分布式结构与WEBLOGIC应用服务器 　　

J2EE提供了一个框架--一套标准API--用于开发分布式结构的应用，这个框架的实际实现留给了第三方厂商。部分厂商只是专注于整个J2EE架 构中的的特定组件，例如APACHE的TOMCAT提供了对JSP和SERVLETS的支持，BEA系统公司则通过其WEBLOGIC应用服务器产品为整 个 J2EE规范提供了一个较为完整的实现。

WEBLOGIC服务器已使建立和部署伸缩性较好的分布式应用的过程大为简化。WEBLOGIC和J2EE代你处理了大量常规的编程任务，包括提供 事务服务、安全领域、可靠的消息、名字和目录服务、数据库访问和连接池、线程池、负载平衡和容错处理等。通过以一种标准、易用的方式提供这些公共服务，象 WEBLOGIC服务器这样的产品造就了具有更好伸缩性和可维护性的应用系统，使其为大量的用户提供了增长的可用性。

J2EE技术在接下来的部分里，我们将描述构成J2EE的各种技术，并且了解WEBLOGIC服务器是如何在一个分布式应用中对它们进行支持的。最常用的J2EE技术应该是JDBC、JNDI、EJB、JSP和SERVLETS，对这些我们将作更仔细的考察。

三、JAVA DATABASE CONNECTIVITY (JDBC)

JDBC API以一种统一的方式来对各种各样的数据库进行存取。和ODBC一样，JDBC为开发人员隐藏了不同数据库的不同特性。另外，由于JDBC建立在JAVA的基础上,因此还提供了数据库存取的平台独立性。

JDBC定义了4种不同的驱动程序，现分述如下：

类型 1: JDBC-ODBC BRIDGE

在JDBC出现的初期，JDBC-ODBC桥显然是非常有实用意义的，通过JDBC-ODBC桥，开发人员可以使用JDBC来存取ODBC数据源。 不足的是，他需要在客户端安装ODBC驱动程序，换句话说，必须安装MICROSOFT WINDOWS的某个版本。使用这一类型你需要牺牲JDBC的平台独立性。另外，ODBC驱动程序还需要具有客户端的控制权限。

类型 2: JDBC-NATIVE DRIVER BRIDGE 　　

JDBC本地驱动程序桥提供了一种JDBC接口，它建立在本地数据库驱动程序的顶层，而不需要使用ODBC。

JDBC驱动程序将对数据库的API从标准的JDBC调用转换为本地调用。使用此类型需要牺牲JDBC的平台独立性，还要求在客户端安装一些本地代码。

类型 3: JDBC-NETWORK BRIDGE 　　

JDBC网络桥驱动程序不再需要客户端数据库驱动程序。它使用网络上的中间服务器来存取数据库。这种应用使得以下技术的实现有了可能，这些技术包括 负载 均衡、连接缓冲池和数据缓存等。由于第3种类型往往只需要相对更少的下载时间，具有平台独立性，而且不需要在客户端安装并取得控制权，所以很适合于 INTERNET上的应用。

类型 4: PURE JAVA DRIVER 　　

第4种类型通过使用一个纯JAVA数据库驱动程序来执行数据库的直接访问。此类型实际上在客户端实现了2层结构。要在N-层结构中应用，一个更好的做法是编写一个EJB，让它包含存取代码并提供一个对客户端具有数据库独立性的服务。 　

WEBLOGIC服务器为一些通常的数据库提供了JDBC驱动程序，包括ORACLE, SYBASE, MICROSOFT SQL SERVER以及INFORMIX。它也带有一种JDBC驱动程序用于CLOUDSCAPE，这是一种纯JAVA的DBMS，WEBLOGIC服务器中带 有该数据库的评估版本。

以下让我们看一个实例。

JDBC实例在这个例子中我们假定你已经在CLOUDSCAPE中建立了一个PHONEBOOK数据库，并且包含一个表，名为 CONTACT_TABLE ，它带有2个字段：NAME 和 PHONE。开始的时候先装载CLOUDSCAPE JDBC DRIVER，并请求DRIVER MANAGER得到一个对PHONEBOOK CLOUDSCAPE数据库的连接。通过这一连接，我们可以构造一个STATEMENT 对象并用它来执行一个简单的SQL查询。最后，用循环来遍历结果集的所有数据，并用标准输出将NAME和PHONE字段的内容进行输出。

  1. IMPORT JAVA.SQL.*;   
  2. PUBLIC CLASS JDBCEXAMPLE{   
  3. PUBLIC STATIC VOID MAIN( STRING ARGS[] ){   
  4. TRY{   
  5. CLASS.FORNAME("COM.CLOUDSCAPE.CORE.JDBCDRIVER"); 
  6. CONNECTION CONN = DRIVERMANAGER.GETCONNECTION("JDBC:CLOUDSCAPE:PHONEBOOK");   
  7. STATEMENT STMT = CONN.CREATESTATEMENT();   
  8. STRING SQL = "SELECT NAME, PHONE FROM CONTACT_TABLE ORDER BY NAME";   
  9. RESULTSET RESULTSET = STMT.EXECUTEQUERY( SQL ); STRING NAME;   
  10. STRING PHONE;   
  11. WHILE ( RESULTSET.NEXT() ){   
  12. NAME = RESULTSET.GETSTRING(1).TRIM();   
  13. PHONE = RESULTSET.GETSTRING(2).TRIM(); 　  
  14. SYSTEM.OUT.PRINTLN( NAME + ", " + PHONE );   
  15. }   
  16. }CATCH ( EXCEPTION E ){   
  17. // HANDLE EXCEPTION HERE   
  18. E.PRINTSTACKTRACE();   
  19. }   
  20. }   
  21. }  

OK。接着我们来看一看JDBC是如何在企业应用中的进行使用。JDBC在企业级应用中的应用以上实例其实是很基本的，可能有些微不足道。它假定了 一个2层结构。在一个多层的企业级应用中，更大的可能是在客户端和一个EJB进行通信，该EJB将建立数据库连接。为了实现和改进可伸缩性和系统性 能，WEBLOGIC服务器提供了对连接缓冲池CONNECTION POOL的支持。

CONNECTION POOL减少了建立和释放数据库连接的消耗。在系统启动以后即可建立这样的缓冲池，此后如故再有对数据库的请求，WEBLOGIC服务器可以很简单地从缓 冲池中取出数据。数据缓冲池可以在WEBLOGIC服务器的WEBLOGIC.PROPERTIES 文件中进行定义。(可参考 WEBLOGIC.PROPERTIES 文件中的例子，WEBLOGIC服务器的文档中还有更详细的参考信息)在企业级应用的另一 个常见的数据库特性是事务处理。事务是一组申明STATEMENT，它们必须做为同一个STATEMENT来处理以保证数据完整性。缺省情况下JDBC使 用 AUTO-COMMIT 事务模式。这可以通过使用CONNECTION类的 SETAUTOCOMMIT() 方法来实现。

现在我们已经对JDBC有了一些认识，下面该转向JNDI了。

四、JAVA NAMING AND DIRECTORY INTERFACE (JNDI) 　　

JNDI API被用于执行名字和目录服务。它提供了一致的模型来存取和操作企业级的资源如DNS和LDAP，本地文件系统，后者在应用服务器中的对象。

在JNDI中，在目录结构中的每一个结点称为CONTEXT。每一个JNDI名字都是相对于CONTEXT的。这里没有绝对名字的概念存在。对一个应用来说，它可以通过使用 INITIALCONTEXT 类来得到其第一个CONTEXT:

  1. CONTEXT CTX = NEW INITIALCONTEXT();  

应用可以通过这个初始化的CONTEXT经有这个目录树来定位它所需要的资源或对象。例如，假设你在WEBLOGIC服务器中展开了一个EJB并将 HOME接口绑定到名字 MYAPP.MYEJB ，那么该EJB的某个客户在取得一个初始化

CONTEXT以后，可以通过以下语句定位HOME接口：

  1. MYEJBHOME HOME = CTX.LOOKUP( "MYAPP.MYEJB" ); 　 

在这个例子中，一旦你有了对被请求对象的参考，EJB的HOME接口就可以在它上面调用方法。我们将在下面的"ENTERPRISE JAVA BEANS"章节中做更多的介绍。

以上关于JNDI的讨论只是冰山之一角而已。如果要更进一步地在CONTEXT中查找对象，JNDI也提供了一些方法来进行以下操作：

将一个对象插入或绑定到CONTEXT。这在你展开一个EJB的时候是很有效的。

从CONTEXT中移去对象。

列出CONTEXT中的所有对象。

创建或删除子一级的CONTEXT。

接下来，我们要开始关注EJB了。

五、ENTERPRISE JAVA BEANS (EJB) 　　

J2EE技术之所以赢得某体广泛重视的原因之一就是EJB。它们提供了一个框架来开发和实施分布式商务逻辑，由此很显著地简化了具有可伸缩性和高度 复杂的企业级应用的开发。EJB规范定义了EJB组件在何时以及如何与它们的容器进行交互作用。容器负责提供公用的服务，例如目录服务、事务管理、安全 性、资源缓冲池以及容错性。

EJB规范定义了3中基本的BEAN类型:

STATELESS SESSION BEANS: 提供某种单一的服务，不维持任何状态，在服务器故障发生时无法继续存在，生命期相对较短。例如，一个STATELESS SESSION BEAN可能被用于执行温度转换计算。

STATEFUL SESSION BEAN: 提供了与客户端的会话交互，可以存储状态从而代表一个客户。典型例子是购物车。STATEFUL SESSION BEAN在服务器故障时无法继续生存，生命期相对较短。每一个实例只用于一个单个的线程

ENTITY BEANS: 提供了一致性数据的表示-- 通常存放在数据库中 -- 在服务器故障发生后能继续存在。多用户情况下可以使用EJB来表示相同的数据。ENTITY EJB的一个典型例子是客户的帐号信息。

尽管有以上的区别，所有的EJB还是有许多的共同之处：

它们都处理HOME INTERFACE。它定义了一个客户端是如何创建与消亡EJB的。

可以在BEAN中对定义了客户端方法的远程接口进行调用；

BEAN类则执行了主要的商务逻辑描述

EJB的开发已经超出了本文的范围。但是，如果一个EJB已经被开发了或者从第三方进行了购买，它就必须在应用服务器中进行发布。WEBLOGIC SERVER 5.1带有一个EJB DEPLOYER TOOL来协助处理EJB的发布。当你使用EJB DEPLOYER TOOL的时候，你要定义客户端所用的JNDI名字来定位EJB。DEPLOYER TOOL将生成WRAPPER类来处理和容器的通信以及在一个JAR文件中把被请求的JAVA类绑定在一起。一旦EJB被发布，客户端就可以使用它的 JNDI名字来定位EJB。

首先，它必须得到一个到HOME接口的REFERENCE。

然后，客户端可以使用该接口，调用一个 CREATE() 方法来得到服务器上运行的某个BEAN实例的句柄；

最后，客户端可以使用该句柄在BEAN中调用方法。

了解 EJB后，让我们再来看JSP。

六、JAVA SERVER PAGES (JSPS) 　　

我们中间可能已经有许多人已经熟悉MICROSOFT的ACTIVE SERVER PAGES (ASP)技术了。JSP和ASP相对应的，但更具有平台对立性。他们被设计用以帮助WEB内容开发人员创建动态网页，并且只需要相对较少的代码。即使 WEB设计师不懂得如何编程也可以使用JSP，因为JSP应用是很方便的。JSP页面由HTML代码和嵌入其中的JAVA代码所组成。服务器在页面被客户 端所请求以后对这些JAVA代码进行处理，然后将生成的HTML页面返回给客户端的浏览器。

下面我们来看一个JSP的简单实例。它只显示了服务器的当前日期和时间。虽然，对语法的具体解释已经超出了本文的范围，但我们还是可以很直观地看到，JAVA代码被放在<%和%>的中间，而JAVA的表达式则放在<%=和%>之间。

  1. <html> 　  
  2. <head>   
  3. <title>Sample JSP Page</title>   
  4. </head>   
  5. <body>   
  6. <h1>Date JSP sample</h1>   
  7. <% response.setHeader("Refresh", 5); %>   
  8. The current date is <%= new Date() %>.   
  9. </body>   
  10. </html>  

您可能有时候听说过JHTML。这是JSP以前的一种较老的标准。WEBLOGIC服务器既可支持JSP，又可支持JHTML。

请注意，在缺省状况下，JSP在WEBLOGIC服务器中并没有处于有效状态。要使之有效，你可以编辑WEBLOGIC.PROPERTIES文件。如果WEB服务器还没有处于有效状态，则要先使之有效。SERVLET的情况和JSP是一样的。 　

七、JAVA SERVLETS 　　

SERVLET提供的功能大多与JSP类似，不过实现的方式不同。JSP通常是大多数HTML代码中嵌入少量的JAVA代码，而SERVLETS全部由JAVA写成并且生成HTML。

SERVLET是一种小型的JAVA程序，它扩展了WEB服务器的功能。作为一种服务器端的应用，当被请求时开始执行，这和CGI PERL脚本很相似。SERVLETS和CGI脚本的一个很大的区别是：每一个CGI在开始的时候都要求开始一个新的进程 -- 而SERVLETS是在SERVLET引擎中以分离的线程来运行的。因此SERVLETS在可伸缩性上提供了很好的改进。在开发SERVLETS的时候， 您常常需要扩展JAVA X.SERVLET.HTTP.HTTPSERVLET 类，并且OVERRIDE一些它的方法，其中包括：

SERVICE(): 作为DISPATCHER来实现命令-定义方法

DOGET(): 处理客户端的HTTP GET请求。

DOPOST(): 进行HTTP POST操作

其它的方法还包括处理不同类型的HTTP请求 -- 可以参考HTTPSERVLET API文档。

以上描述的是标准J2EE SERVLET API的各种方法。WEBLOGIC服务器提供了一个该API完整的实现途径。一旦你开发了一个SERVLET，你就可以在 WEBLOGIC.PROPERTIES 中加以注册并由此可以在WEBLOGIC服务器中对它进行配置。通过JAVA SERVLETS,我们已经到达了J2EE主要技术的末尾了。但J2EE所提供的并不止于这些。

下面的段落中我们将简要地看一下现存的一些技术，包括RMI, JAVA IDL和CORBA, JTA, 以及XML，等等。

八、REMOTE METHOD INVOCATION (RMI)

正如其名字所表示的那样，RMI协议是在远程对象上调用一些方法。它使用了连续序列方式在客户端和服务器端传递数据。RMI是一种被EJB使用的更下层的协议。

九、JAVA IDL/CORBA 　　

在JAVA IDL的支持下，开发人员可以将JAVA和CORBA集成在一起。 他们可以创建JAVA对象并使之可在CORBA ORB中展开, 或者他们还可以创建JAVA类并作为和其它ORB一起展开的CORBA对象的客户。后一种方法提供了另外一种途径，通过它JAVA可以被用于将你的新的应 用和LEGACY系统相集成。

十、JAVA TRANSACTION ARCHITECTURE (JTA)/JAVA TRANSACTION SERVICE (JTS)

JTA定义了一种标准的API，应用系统由此可以存取各种事务监控。

JTS是CORBA OTS事务监控的基本实现。JTS规定了事务管理器的实现方式。该事务管理器是在高层支持JAVA TRANSACTION API (JTA)规范，并且在较底层实现OMG OTS SPECIFICATION的JAVA映像。JTS事务管理器为应用服务器、资源管理器、独立的应用以及通信资源管理器提供了事务服务。

十一、JAVA MAIL AND JAVA BEANS ACTIVATION FRAMEWORK 　　

JAVA MAIL是用于存取邮件服务器的API，它提供了一套邮件服务器的抽象类。不仅支持SMTP服务器，也支持IMAP服务器JAVA MAIL利用JAVA BEANS ACTIVATION FRAMEWORK (JAF)来处理MIME-编码的邮件附件。MIME的字节流可以被转换成JAVA对象，或者转换自JAVA对象。由此大多数应用都可以不需要直接使用 JAF。

十二、JAVA MESSAGING SERVICE (JMS)

JMS是用于和面向消息的中间件相互通信的应用程序接口(API)。它既支持点对点的域，又支持发布/订阅(PUBLISH/SUBSCRIBE) 类型的域，并且提供对下列类型的支持：经认可的消息传递、事务型消息的传递、一致性消息和具有持久性的订阅者支持。JMS还提供了另一种方式来对您的应用 与LEGACY BACKEND系统相集成。

十三、EXTENSIBLE MARKUP LANGUAGE (XML)

XML是一种可以用来定义其它标记语言的语言。它被用来在不同的商务过程中共享数据。XML的发展和JAVA是相互独立的，但是，它和JAVA具有 的相同目标正是平台独立性。通过将JAVA和XML的组合，您可以得到一个完美的具有平台独立性的解决方案。目前正有许多不同的公司在为JAVA和XML 的组合而努力。如果要了解更多的这方面的信息，可以访问SUN的JAVA-XML页面，或者IBM DEVELOPERWORKS的XML ZONE。

J2EE 带动了Java在企业级的发展，但随着一些轻量级组件的出现，J2EE的臃肿和开发难度高的缺点越来越引起了许多人的注意，EJB2.0也被许多人称为累 赘。随着Spring,Hibernate的不断完善和发展,EJB3.0出现了，成为了未来Java 企业级开发的新的方向。

【编辑推荐】