http://dev2dev.bea.com.cn/bbs/jishudata/ArticleShow.jsp?Id=15
作者：zhoubikui(dev2dev ID)
摘要：
希望本文能引起各位J2EE开发同行的激烈争论。EJB是J2EE的全部吗？被偷走的EJB该如何回来？本文结合自己最近在WEBLOGIC的开发的J2EE项目的得与失和最新的J2EE发展技术尝试一种新的J2EE解决方案。最后用DEMO小试牛刀，希望能得到答案和启迪。
目录：
一、背景：
二、开发环境
三、系统开发框架
3.1该开发模型的特点
3.2 层与层之间数据交互XML Data Bus
3.3 数据持久层设计
四、反思
4.1该模式的优点
4.2借鉴
4.3反思
五、较理想的J2EE解决方案
5.1 J2EE分层
5.2设计目标
5.3 J2EE数据持久层开发
5.4业务逻辑层的设计
5.5 业务层和数据持久层数据总线
六、实践
6.1开发思路
6.2系统设计
6.2.1总体设计
6.2.2 数据持久层设计
6.2.3 业务逻辑层设计
6.2.4 WEB层设计
6.2.5 总 结
6.3源码下载
七、BEA能为我们做更多
八、总结
相关资源下载
参考资料
一、背景：(目录)
J2EE是开发企业很好的平台。它内涵非常丰富，使用人群也非常庞大，有很多最佳实践经验和优秀工具。事实证明,J2EE确实可以为复杂的企业应用提供强大的技术保障。但由于它过于复杂，开发人员缺乏足够技巧和开发经验，往往也是导致J2EE项目落马的原因。
这个题目可能会让您觉得有些哗众起宠的味道，但这个在J2EE潜水的小虾米如果能让您对目前的开发哪怕有一点小的触动就很满足了。我写这篇文章时已经穿好了防弹衣，期待着您的西红柿和鲜花!
看了一些论坛里的帖子，让我很疑惑的是为什么EJB看来是如此的成功?但我却发现在 本公司和其它竞争对手以及我兄弟们中的牛公司中使用EJB的是少之又少。
疑惑!谁动了我的EJB？
Bea的 WebLogic是如此的出色，以至于WebLogic 8出来后 我们这些日日夜夜的不停推磨的驴子简直都可以洗洗睡了。
但具有讽刺意味的是倘若你问我们为什么要买WebLogic，因为sun的 iplanet不停的挂掉，我们终于受不了，也不敢再相信sun one server。选择WebLogic因为我们需要一个可靠的web server支持jsp罢了。
首先说明我不是EJB的反对者，我依然希望EJB能在数据持久层开发中发挥重要作用。我将在正文中讲我的想法，我想BEA的WebLogic可以带给我们更多好的东西。
二、开发环境 (目录)
> 操作系统：WINDOWS 2000
> J2EE应用程序服务器：BEA WEBLOGIC SERVER 6.1
> 开发工具：EOS studio33 （其实就是对WEBLOGIC studio的改造加入了一些财政开发常用的库让业务流程能象工作流的开发），DEMO例子都是在eclipse下开发的与这开发工具无关。
> 数据库：ORACLE 9I
三、系统开发框架(目录)
下面是我们公司和XXX一块合作开发的一套国库县乡系统，为了提高开发效率我们对WebLogic 6 的STUDIO开发工具作了一些改造，加入了我们的构件库。使业务能图形化开发的尝试，有点类似现在WebLogic 8的工作流的开发。这是一次不太成功的试验，但确实能带给我们一些新的东西。由于大多数用户没有相同的开发环境，我不打算对技术细节做太多描述，只写对现在J2EE开发框架有冲击的东东。
我们将企业系统可以划分为页面层、业务流程层、服务层、对象层和数据层五个层次。从实现各层的技术标准看，页面层技术有JSP及portal等，业务流程技术有WfMC及BPML等，服务层技术有EJB及Web Services、对象技术有JDBC、XML，数据技术有各类数据库产品，如：DB2、Oracle、SQL Server，以及SQL92等相关标准。
图一
该系统就是在这些技术标准基础上，对各技术层次上的业务内容实现了面向构件的封装。构件的最终实现技术仍为各层次的标准技术。将页面层业务内容封装为页面构件及页面模版构件，将流程业务内容封装为工作流程图和页面流程构件，将服务业务内容封装为业务逻辑构件；将对象封装为运算逻辑等基础构件，将数据封装为数据构件。
3.1该开发模型的特点(目录)
（1） 从系统框架层次看，它是一个标准的MVC系统框架，是当前主流的、公认的系统框架。
（2） 在应用系统中，业务构件在运行时的表现为标准的EJB。在运行系统中，构件接口形式、互操作形式完全使用EJB标准。
（3） 基础构件都是完全符合J2EE技术标准的，包括JDBC、JMS、JSP、JNDI技术等。这些技术标准的采用使开发的应用系统成为完全符合J2EE标准的应用系统。
（4） 在系统配置、数据接口、内存数据管理各方面采用了XML技术标准。由于XML具有良好的自描述性和顺序无关性，利用XML标准进行数据交换、内存数据管理使系统具有更加良好的可扩展性和伸缩性。基于该开发的应用系统是一个符合XML标准的应用系统。
在面向构件和可视化的构件组装过程中，同样采用了XML的定义格式，使构件的组装基于XML而非代码层定义，并在应用装载时由运行支撑环境解释为标准的J2EE。这即保证了此应用系统自身的简洁性，又保持了应用系统的标准性。
3.2 层与层之间数据交互XML Data Bus(目录)
层间上下可互访，但不能越过相邻层通讯。层间数据交互用XML作为交互载体。见下图。
图二
3.3 数据持久层设计(目录)
普通的J2EE平台都不提供相关的建模与数据管理工具，而采用专用工具（如：PowerDesigner 或 Rational Rose等），这增加了多个工具间的切换和使用复杂度；另外，由于数据模型工具对是多个、异构数据库系统支持的简单性，使程序员常常需要在这些工具之外进行许多的代码编写工作。
它提供了专用数据模型工具（Database Designer Tools）对应用模型设计、模型管理、数据结构生成进行一体化的处理。同时，由于其工具内部内置了数据映射功能，使数据结构面对多样、异构的数据库（如:Oracle、DB2、MSSQL等）时，可以以统一的调用和对前台无影响的系统数据移植方式为前台应用提供服务。
图三
四、反思(目录)
看了这么多花花绿绿的图片和理论，可能把您的头都搞大了。下面汇总一下前面的内容。
4.1该模式的优点(目录)
> 严格分层，为了实现层的修改不会影响相关层的。系统采用了显示层，展现层、业务流程层、服务层、对象层和数据层六层结构。
> 层与层之间数据交互采用XML Data Bus，这样基本上实现层中修改不会影响上下两层，最多是利用映射，服务器重起一下。
> 这种模块化有利于分层开发相对的控件和图形化开发工具。
> 最令人心动的是专用数据模型工具（Database Designer Tools），只需配一下数据库连接就可以实现得到表的增删改查。
> 最让人感动的是处处用到EJB技术，可使用者从来没感觉到使用了某种特定技术，只是简单调用数据持久层的增删改查方法就OK了！
4.2借鉴(目录)
多么美的事情，我当初看到真是一夜未眠，最终也为后来项目不太成功打下伏笔。现在分析起来主要是：
XML Data Bus设计有问题，由于XML在HTTP中传数据有自身的弱点，如XML会把XML空格结点去掉，结果页面有个TEXT显示数据库某个字段aa的值test,我想把它赋空，在页面到展现层时XML自动忽略这个结点，最后数据库更新可想而知，我依然是我。
开发工具不稳定，某些技术不太成熟，也没有较好的编辑工具，修改一个小东西，简直有点大海捞针的味道非常考验人的耐性，开发前期很顺，到了后期，服务器无名火到处发，现象重现率也不高，系统正常都不知怎么正常的，维护简直是噩梦。
简单是我们程序开发中一个很重要的原则，简单会减少我们出错的概率，而且即使出现错误也能很快纠正。
4.3反思(目录)
虽然有这样或那样的失败原因，但凭心而论，这套J2EE解决方案确实还是有其独特的魅力。
我的体会主要有这样的几点：
> J2EE开发肯定需要分层，但不宜分层太多。MVC的方式比较好。从开发和维护角度考虑，分四层结构比较合适。
图四
> 数据持久层好写但不容易写好，这是系统最基础也是最核心的部件，一个程序的好坏很大关系是它决定的。EJB想说爱你真的不容易，O/R面向对象的数据库编程对一些简单的业务操作能提升很大的开发效率，可惜我们的数据库很复杂，简单说说我们的权限判断，严肃到数据库表的哪个字段用户当前职责是可读还是可写，而且这些关系大量SQL执行找到最接近的数据访问权限，我想目前除了IBATIS勉强满足外，Hibernate敢都不敢想。非常希望BEA的WEBLOGIC能开发类似EOS的专用数据模型工具（Database Designer Tools），不要让我知道我在用什么技术调用数据库，我只用告诉它需要对数据库做什么操作就行，最好能像MS的工具箱一样，给个控件告诉它对应什么表，该做什么操作，以及该操作需要什么前提条件。条件只是按它映射命名的对象就可以自动组合合适的SQL或采用相应的EJB操作。我们真得不想关心，你是用JDBC还是EJB实现的，我们只需要最佳的效果，这个WEBLGIC完全可能根据当前SERVER容器的支持环境做出。
> 层与层间数据传递用VO对象，也可用串行化实现。
> MVC中M的开发业务层和数据层组织形式采用DAO模式比较好。事务放在业务层，采用J2EE容器的事务声明方式。
可能这些想法并没太多新鲜的成分，但我需要强调的是数据持久层的设计应该有构件化的产品，开发人员不需要了解如何得到是通过EJB或是JDBC从数据库中得到数据，WEB SERVER容器中提供什么服务，它可以自动选择方式，当然也可手工设置。
这个问题是可以得到很好解决的，注意我DAO的设计思想，数据持久层不需要考虑事务等一些复杂的问题，它只需简单对表做增删改查的工作。
开发人员需要做的是二件事
> 开发人员配置数据库连接，工具能自动建立表与数据持久层对象的映射
> 开发人员利用构件化的工具包（属性包含数据持久层对象名和调用条件（VO对象），方法有增删改查）简单配置，然后装配到业务层就能实现业务逻辑的演练。
这个开发需要注意它是个独立的层，不会依赖某一数据库或WEB SERVER容器，是个通用的数据持久层的解决方案。我相信BEA公司会把这种设想做得更好！
开发人员需要数据持久层开发效率和性能，我们再使用EJB，但不需要过多陷于EJB中。
五、较理想的J2EE解决方案(目录)
5.1 J2EE分层(目录)
涉及到的java类可以分为这么几种：
> VO/command类。
用于各层之间传输数据用。只有set,get方法。值对象尽量要通用性强。属性方法多。
> controller类
用于处理用户提交请求。建议将多个有紧密关系的功能点放在一个类里。如对计划的浏览，提交，修改，就可以放在一个类里。Controller类负责前台的，不重要的数据校验。并调用façade类完成业务。
> façade类
管理类或者门面类。一个模块只能有一个这样的类，所有的controller类都调用该类，而不直接调用DAO类。该类里面起事务处理，本身没有功能，调用DAO类完成功能。
> DAO类
负责具体的数据库存取操作。原则上一个表对应一个DAO类，也可以按对象来建立类。
这个MVC开发方式本身可能没有太多新鲜的地方，其相同点在这里就不说了，本文具体就怎样构件M？也就是业务逻辑层和数据持久层的架构。
5.2设计目标(目录)
充分利用OOP设计的优势
避免了不必要的复杂
具有可维护性、可扩展性
避免任何特定平台或非标准化
不重新开发已有的东西目前Spring的Ioc模式实现的BeanFactory和AOP，编制程序时，只要写被调用者的接口代码，具体子类实例可通过配置实现，它不依赖特定平台，你可一全部用它的框架，也可以只用其中一部分。
这种新的架构出现，使我觉得以下情况实现成为可能！
数据持久层设计图形化构件化开发能成为可能，它只管和数据库数据交互更新，不要担当太多的责任。而业务逻辑层自我定制构件将会变得非常简单，而且借鉴J2EE的EJB事务容器申明也得到解决。业务逻辑层实现有点象小时侯搭积木一样轻松的把数据持久层构件组合就能实现。下面将就数据持久层构件化和业务逻辑层分别论述。
5.3 J2EE数据持久层开发(目录)
数据持久层设计构件化开发可能？
数据持久层设计目标：
操作简单，我们希望只需将数据连接配置好，然后我们将构件与数据库具体表对应上，接下来告示它操作类型，传入条件参数（VO类）后，余下的任务全有他完成。数据持久层只管和数据库数据交互更新，本身只对表的增删改查的动作，非常简洁，硬编码也不会太复杂。
调用只需要利用Spring的BeanFactory简单配置，就可在业务处理层直接调用。这个过程只是简单改写一下配置文件，其图形化，非常容易实现。
测试，我们在数据持久层用的是接口编程模式，利用JUIT或Spring本身资源读取API很容易写测试方法。
维护和修改很方便。由于是具体子类实例可通过配置实现，非常方便修改和扩展。
目前有一些类似产品，可惜都是依赖某一特定平台或技术，你要么全部按他的规范做，要么全部放弃。它使你在某一方面方便的却在另外方面限制你，让你没法施展拳脚。
当前比较恰当的组合Spring的BeanFactory+IBATIS，能较好满足轻量级系统的开发。我希望BEA公司的WEBLOCIC能在这方面为我们提供精彩的解决方案。
借鉴Spring的BeanFactory和AOP技术和BEA在EJB的造诣，BEA完全可能把它做得更好！而且基于以上分析，技术难度上不会太大。我们有理由期待数据持久层设计构件化图形化的到来。我觉得它的出现应该除了前面的特点，还应有下面的特点：
开发者，不需要知道数据持久层是用EJB或是JDBC实现的具体细节。该构件能自动根据服务容器的支持，选择是EJB或是JDBC实现。
EJB本身没有错，错在它能力太多，让使用者无法驾御。我们开发人员关注的是数据持久层的本身功用和性能，我们不管你是用EJB或是JDBC实现的。我们需要简单持久性能优良的解决方案。请不要让EJB做太多的实质是数据持久层不要做太多。
5.4业务逻辑层的设计(目录)
面向接口的开发，它具有很强的灵活度和扩展性。
业务逻辑层调用也用Spring的BeanFactory组合，这样在数据持久层设计构件化的同时，我们业务逻辑层自我定制构件将会变得非常简单。
我们将数据持久层中的事务处理提到业务逻辑层的理由是不用多说的。我们只需简单对SPRING的bean管理的配置文件增加拦截代理对象，为了给业务逻辑对象增加事务处理。其简单声明如下：
<!-- Transaction manager for a single JDBC DataSource -->
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource"><ref local="dataSource"/></property>
</bean>
<bean id="systemManager" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager"><ref local="transactionManager"/></property>
<property name="target"><ref bean="业务逻辑"/></property>
<property name="transactionAttributes">
<props>
<prop key="query*">PROPAGATION_SUPPORTS,readOnly</prop>
<prop key="*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
transactionAttributes属性可以设置事务处理的方式，事务隔离级别，是否只读三个属性，用逗号隔开。事务隔离级别各数据库系统不完全支持，一般不设置，用默认的即可。
事务处理选项有如下几个：（前面2个常用）
PROPAGATION_REQUIRED － 需要事务处理。如果当前不存在事务环境，则创建一个；
PROPAGATION_SUPPORTS － 如果当前存在事务环境，则作为其中的一部分。如果不存在，则按非事务方式执行；
PROPAGATION_REQUIRES_NEW － 需要事务处理。并总是开启一个新事务。如果已经存在事务环境，则挂起之；
PROPAGATION_MANDATORY － 执行到指定方法时，必须已经存在事务环境，否则出错；
PROPAGATION_NEVER － 不支持事务操作，如果存在事务环境会出错；
PROPAGATION_NOT_SUPPORTED － 不支持事务操作。如果存在事务，则挂起。 如果要追求好的性能，我们可以在此定义事务精确到到某一方法的某一异常起事务回滚。
WEBLOGIC SERVER可以协调涉及多个资源的事务时，JTA的许多高级事务协调特性才能发挥。对一个跨数据库资源的事务，将采用两个阶段提交（Two-Phase Common,2PC）技术处理。实际上对用户而言2PC技术是透明的。在应用JTA驱动程序时，需要连接多个资源，指定针对这些资源的操作等。只要XA兼容，WEBLOGIC就会把这些资源集成到一个事务中，使所有的资源相互协调一致工作，或者都成功或者都失败。TXDATASOURCE建立与多个XA兼容资源之间的桥实现。JAT负责处理JTA事务与底层资源的相互协调。
要实现这种功能只需将<bean id= transactionManager >换成如下写法就可：
<bean id=” transactionManager”class=”org.springframework.transaction.jta.JtaTransactionManager”/>
5.5 业务层和数据持久层数据总线(目录)
业务层和数据持久层交互为何采用VO对象而不是XML或SQL字符串作为传递参数？
①前者分层明晰，后者把SQL生成放在业务层，在业务类中硬编码SQL，导致代码难于维护和扩展SQL代码到处出现在你的类代码中。这样的好处是写代码效率很高，对于小型应用程序或者原型，这样是可行的。缺点是直接耦合了你的业务类与关系数据库结构。业务层不应该做数据层的工作。而且业务层或数据库字段变动，会引起两层修改。维护不方便，也不利于数据持久层的接口抽象。
②前者更加符合面向对象的开发思想。面向对象应用程序可以使用关系数据库作为持久机制而不需要在程序中使用嵌入SQL。后者没有仔细考虑对持久机制维护和管理的应用程序带来的继承脆弱性。
③前者增加VO对象时，业务和数据持久层代码几乎不需任何修改。可理解性和兼容性都比后者好。
六、实践(目录)
前面说了不少理论的东东，大家可能都有点厌倦了，下面通过一个实例解释一下。限于篇幅，我将项目中常用的分页实现作为例子给大家说说。由于目前数据持久层还没有比较好的构件化开发工具，现用IBATIS代替。大部分内容都不会讲太细的细节，因为我假定读者有SPRING和IBATIS的基础知识。限于篇幅，我们重点放在业务逻辑和数据持久层的实现上，详细内容见源码，有比较详细的解释。
6.1开发思路(目录)
分页逻辑：页面需要保存以下参数：
总行数：根据sql语句得到总行数 每页显示行数：设定值pageSize 当前页数：请求参数page
页面根据当前页数和每页行数计算出当前页第一行行数，定位结果集到此行，对结果集取出每页显示行数的行即可。
在SESSION存放数据列表是这么考虑的：对于大量数据，比如10000条，肯定不能一次全取出来。通常是每次取一页的数据，如20条，其实效率也不高。 最好是每次取出来(比如)10页的数据，放在session里。这样，翻10页才会查一次数据库。
图五
6.2系统设计(目录)
6.2.1总体设计(目录)
后台数据持久层，采用DAO模式；中间逻辑层，采用Facade模式；前端Web层，采用MVC结构，使用JSP作为视图。其组装详见下图：
图六
利用Spring的Ioc模式实现的BeanFactory非常方便将以上组装实现。
6.2.2 数据持久层设计(目录)
数据持久层与数据库联系非常简单，在SPRING的配置文件中配置如下两步就可。
第一步：设置iBATIS
<bean id="sqlMapClient" class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">
<property name="configLocation">
<value>WEB-INF/sqlMap-config.xml<!-- iBATIS配置文件--></value>
</property>
</bean>
第二步：数据访问层(DAO)对象与数据库配置和iBATIS配置联系
<bean id="userDao" class="cn.com.mofit.demo.system.dao.SqlMapUserDAO">
<property name="dataSource">
<ref local="dataSource"/>
</property>
<property name="sqlMapClient">
<ref local="sqlMapClient"/>
</property>
</bean>
接下来业务逻辑就可使用这些数据持久层的方法了。
你看不是很方便，开发者在代码编写中从来没感觉到用到Spring什么东东，而且简化IBATIS操作数据库的步骤。
数据持久层的开发任务是将业务层传过来VO值对象转化为数据库中对满足条件的特定操作。
IBATIS引入了动态映射机制，根据配置文件中设定的SQL动态生成规则，创建相应的SQL语句。通过
等一些IBATIS的SQL动态生成规则组合很方便的实现VO值对象到数据库操作映射。
6.2.3 业务逻辑层设计(目录)
该类是系统管理模块的facede类。所有对系统管理模块的业务操作都应当通过该类完成。
该类会通过配置文件为所有方法增加事务处理。
建议类里面的方法都加上如下前缀，以方便用指定的命名规则设置事务处理级别：
queryXXX() － 不需要，或者只读事务
addXXX() － 需要事务处理
removeXXX() － 需要事务处理
updateXXX() － 需要事务处理
XXXX() － 其他方法，需要事务处理
这样，我在TransactionProxyFactoryBean的配置里就可以这样设置：
<property name="transactionAttributes">
<props>
<prop key="query">PROPAGATION_SUPPORTS</prop>
<prop key="">PROPAGATION_REQUIRED</prop>
</props>
</property>
由于该类的特殊性和事务处理，建议类里面不要有无谓的辅助方法。
我们在CONTROL层引用的业务层实质是业务逻辑层加上事务后的业务逻辑接口。
6.2.4 WEB层设计(目录)
Controller类负责前台的，不重要的数据校验。并调用façade类完成业务。非常干净利落。
图七
对应的SPRING配置文件
<!-- 用户登录处理类 -->
<bean id="do_login" class="cn.com.mofit.demo.system.web.UserLogAction">
<property name="formView"><value>login</value></property>
<property name="successView"><value>main</value></property>
<property name="systemManager"><ref bean="systemManager"/></property>
</bean>
<!-- 用户列表浏览类 -->
<bean id="do_browse" class="cn.com.mofit.demo.system.web.browseUserAction">
<property name="systemManager"><ref bean="systemManager"/></property>
</bean>
非常轻松的将加上事务后的业务逻辑接口引到控制层，页面流配置也类似STRUTS。
UserLogAction继承SimpleFormController，该子类非常适合处理表单提交事件。 它的处理流程是这样的：
get请求来到时，这样处理：
1) 请求传递给一个controller对象
2) 调用formBackingObject()方法，创建一个command对象的实例。
3) 调用initBinder()，注册需要的类型转换器
4) 调用showForm()方法，返回准备呈现给用户的视图
5) 调用referenceData()方法，准备给用户显示相关的数据。如用户登录需要选择的年度信息
6) 返回formView指定的视图
post请求来到时，这样处理：
1) 调用formBackingObject()方法，创建一个command对象的实例。
2) 将请求传来的参数写入command对象
3) 如果设置为要求验证，则调用validator类进行数据验证
4) 调用onBindAndValidate()方法，该方法允许自定义数据绑定和校验处理
5) 调用onSubmit()方法，进行业务逻辑处理
结合我们的设计我们可以用command对象，直接将页面数据通过控制对象传给业务逻辑处理，当中都不需要类型转换，非常方便。是不是很合开发者的胃口。
6.2.5 总 结 (目录)
这个事例非常简单，但还是能说明Spring的Ioc模式实现的BeanFactory和AOP确实能给我们开发带来极大方便。我想如果我们有工具将BeanFactory的配置文件生成图形化的话，将会极大提高我们的开发效率。
以前构建一个持久层是惊人的困难，现在我们想一下结合iBATIS数据持久层的开发，我们将数据持久层构件化是否是个非常简单的事，现在需要做的仅仅是IBATIS的sqlMap文件生成的图形化工具，然后是几个摸版化增删改查的方法。业务逻辑层对它们的装配利用Spring的BeanFactory也能轻松实现。
这是个轻量级的J2EE开发的图形化构件化的解决方案，那么我们EJB老大哥呢？
我想如果单一抛开EJB那么多功能不说，我想就EJB专注做好数据持久层设计构件化这个工作，它有许多优势的。现在已经有人在这方面做了比较大的突破。
请不要让我们一起重复数据持久层开发的辛劳，我们不管你用什么技术，我们只是需要较佳从数据库中交互数据的构件，让我们在这方面学学MS，而且我们能比它做得更好！
我们需要数据持久层构件化，结合Spring的Ioc模式实现的BeanFactory原理，简单的让业务逻辑组装，要是这两者都有方便的可视化工具。我想下次开发我们仅仅需要动一下鼠标，拖拉几个控件，一切搞定。而这离我们到底有多远，我觉得就差最后的一步！
6.3源码下载(目录)
本程序在JDK4.1,TOMCAT 5.0或WebLogic 8.1上测试通过。代码有详细注释，大家看过就能上手。
点击这里下载demo!
七、BEA能为我们做更多(目录)
Bea的 WebLogic出色表现有目共睹，尤其是现在WebLogic 8。现在应用服务越来越复杂，我这个用WebLogic6的人突然看到WebLogic 8会欣喜又不知所措，我们还希望Bea能给我们较简单的解决方案。
突破口在哪呢？就是数据持久层的开发，数据持久层的不依赖某一特定服务器的构件化图形化开发做好，一切将变得EASY！前面有Spring的Ioc模式实现的BeanFactory和AOP和轻量级数据库解决方案IBATIS(Hibernate)做急先锋，我们觉得数据持久层构件化时代已经到来！这样WebLogic运行见下图：
图八
BEA能为我们做得更多？！
BEA下个春季，值得我们期待！
八、总结(目录)
这篇文章对我来说是个挑战，但一直以来J2EE开发的快乐与痛苦刺激着我前行。我觉得我们应该为这作些什么。
题目选得有点大，我有几次想放弃，但我老婆APPLE一直鼓励着我，让我在痛苦中成长。
我希望将来的J2EE开发不再会有EJB该如何使用的疑问。因为开发者本身都不会感觉EJB的存在。限于本人水平和理解层次，可能会有许多误解，期待着与您交流和争论！
相关资源下载(目录)
JDK 1.4.2可以从http://java.sun.com下载。
Spring framework 1.1可以从http://www.springframework.org
iBatis 2.0可以从http://www.ibatis.com下载。
Tomcat 5.0、Ant 1.6可以从http://www.apache.org下载。
WebLogic Server / Workshop 8.1可以从http://commerce.bea.com下载。
oracle9I的JDBC驱动，commons-dbcp下载
参考资料(目录)
Wrox - Professional J2EE with BEA WebLogic Server
J2EE Applications and BEAWebLogic Server
Expert One-on-One J2EE Development without EJB
Expert One-on-One J2EE Design and Development by Rod Johnson
部分图片来自公司培训幻灯片
关于作者(目录)
关于作者：
周必奎（dev2dev ID:zhoubikui），软件工程师，从事J2EE开发
电子邮件：zhoubikui@eyou.com
地址：财政部信息网络中心北京兴财信息有限公司