从网络的方面来说，如果服务器的功能较弱而工作站的功能较强，则称胖客户瘦服务，反之亦然。

Fat client:
In a client/server architecture, a client that performs t
he bulk of the data processing operations. The data itself is stored on the server. See thin client for contrast. 
Although the term usually refers to software, it can also apply to a network computer that has relatively strong processing abilities

Thin client:
(thin klī´&nt) In client/server applications, a client designed to be especially small so that the bulk of the data processing occurs on the server. 
Although the term thin client usually refers to software, it is increasingly used for computers, such as network computers and Net PCs, that are designed to serve as the clients for client/server architectures. A thin client is a network computer without a hard disk drive, whereas a fat client includes a disk drive

　　现在Java领域各种技术百花齐放，名目繁多，如何根据自己的需求选择这些框架呢？特别对于初学者，在学习选择方向上也非常迷茫，如何有针对性的根据自己项目特点进行学习就变的更加重要。

　　下面我们从一个发展角度来对J2EE/Java EE的这些框架诞生进行一番考量，可能对我们的选择有很大帮助。

　　首先我们需要明白一个高质量的J2EE系统是什么样子？高质量的J2EE/Java EE系统标准实际就是OO设计的标准，松耦合是OO设计的主要追求目标之一，那么无疑解耦性成为衡量J2EE/JEE质量的首要标准。实际选择中，还需要兼顾可伸缩性/性能/开发效率等方面综合考虑。

　　J2EE/Java EE号称多层结构，为什么多层比两层好？因为多层结构解耦性好，带来维护拓展方便灵活。

　　典型的J2EE/Java EE至少划分三个层次：表现层/业务逻辑组件层/持久层。

　　如图，表现层英文是Presentation Layer，是实现显示功能的，这部分一般使用B/S结构来完成，当然你也可以使用专门远程客户端来实现;

　　业务逻辑层因为是由大量组件(Components)组成的，也可称为组件层，组件从不同角度又可分为各种类型，然后又有不同的流派，目前占主要位置的是Model+Service，模型加服务，所以这一层又称为业务服务层Business Service；也有称为Model业务层；

　　持久层是负责对象持久化也就是数据库操作的层次,英文Persistence Layer。

　　SUN伙伴们推出J2EE标准时，分别对这三个层次规定了标准实现，表现层使用Jsp/Servlet技术；业务组件层使用EJB的会话Bean；持久层使用实体Bean。同时，标准将业务层和持久层在物理上组成一个新的容器EJB容器，与表现层技术完全一样的容器，这样，J2EE技术被细化为Web和EJB，物理上有Web容器和Web应用程序；以及EJB容器和EJB应用程序。

　　当然，J2EE/JEE的发展不止这些，这三个层次技术分别独立发展，高歌猛进，下面分别单独陈述，当你了解某种框架技术为什么诞生时，你可能就知道你该在什么情况下选择它们了，工具总是因目的而生！

表现层框架

　　J2EE/Java EE虽是多层结构，但它不是一种强制性多层结构，也就是说，你也可能做成传统两层结构，有的初学者直接使用Jsp嵌入Java代码调用数据库这样结构实际不是多层结构，还是以前的两层结构。

　　在Jsp中嵌入大量代码，一旦报空指针错误就很难找出问题，很多初学者下载JiveJdon 2.5后就经常碰到这个问题，因此大量有关空指针错误问题出现论坛里，为什么他们不能自己解决呢？ 那是因为无法定位错误在Jsp中的位置，Tomcat等服务器只告诉我们错误在index_jsp.java(Jsp的java文件)位置，搞得一些人经常会跑到Tomcat服务器内部翻找Jsp的Java文件，这一过程无比痛苦（为了减少初学者这种痛苦，本站暂停了JiveJdon2.5的下载）。

　　J2EE/Java EE的发展就是降低这种痛苦，首先想到的方式是：在Jsp调试上下苦功，要求Tomcat等服务器提供详细的错误定位；可惜到Tomcat 5.5我们也没看到这种功能；实际上，根本解决之道就是将Jsp的调试变成java组件的调试。

　　首先通过MVC模式规定Jsp只能等同于Html，不能包含Java代码，将Jsp和Java代码分离，可是这样分离之后，它们结合起来又麻烦了，所以，虽然你使用MVC模式，但是还是直接基于Jsp技术，带来的是开发效率的降低。

　　Struts框架解决了这个问题，通过ActionForm可以将Jsp和JavaBeans方便快速地结合起来，但是有人又抱怨Struts的ActionForm限制太死，与Jsp虽能对应，只能一个ActionForm一个表单对应，而不能任意组件JavaBeans都可以和Jsp任意字段对应，这时就出来了组件型框架JSF/Tapestry。

　　表现层框架Struts/Tapestry/JSF架构比较

业务逻辑层框架

可伸缩性

　　因为EJB标准的推出，业务组件层以前基本是EJB的天下，但是EJB功能实在太强大，它考虑了世界顶级大型系统需求，因此免不了显得很复杂，当初，基本上所有的大型企业高端都是选用J2EE，选用J2EE实际是选用EJB。EJB强调的高可伸缩性为大型企业日益发展提供最大的发展空间，不再因为企业快速发展导致整个企业系统结构都要发生根本变化,这是使用EJB的现实优势。

　　这种企业系统的可伸缩性不是因为EJB存在才显得重要，而是我们企业架构选择需要考量的基本因素。换句话说，无论我们使用EJB与否，这个问题都需要考虑:一台服务器不够用怎么办？如果这台服务器死机会对企业运营带来什么影响？如果每个星期这台服务器停机维护升级会不会对企业带来打击？我的企业系统是不是需要可靠的、几乎不当机的7x24运行？当企业系统面对大量外部访问用户时，一台服务器是否够用？多台服务器联动的需求是否涉及软件技术更换？

　　在这个现实因素考量后，如果觉得不是很重要，或者说将来一段时间内这些因素无所谓，那么可以不选用EJB了。

　　为什么有不选用EJB的理由？因为它复杂，学习起来比较困难，EJB帮助我们考虑企业中可能碰到的大部分问题，实际上，有的我们不需要，这也就是为什么说EJB是一个重量级解决方案所在。

　　与重量级相比的是轻量，业务组件层轻量级解决方案有Spring/HiveMidn/Jdon Framework等，轻量一词曾经因为EJB的出现而变得时髦，给人造成的感觉是：EJB花了老鼻子力气完成的那些功能，使用我轻量级解决方案可以轻而易举也能解决，举重若轻啊，其实这是一种误解。

　　当曾经以轻量自居的Spring将事务机制纳入自己怀抱中时，它也开始低调轻量了，实际是不轻不重了；当然如果它把分布式计算和事务再次加入时，天平砝码也会沉下去的。

　　初学者总是愿意使用简单的解决方案，学习使用方便，因此比较喜欢轻量级框架技术，这是正常的，但是在使用轻量级别框架之前必须明白：你的系统将来真的只需要一台服务器即可？你的项目完成期真的非常紧急？

　　如果只需要一台巨强服务器，就不必选择EJB，EJB是因分布式多服务器而生，对于单台服务器，缺乏本地透明性，也就是说：你无法透过EJB直接和本地JVM或文件系统等打交道，透明性也是衡量一个框架的重要指标。

　　当然，重量和轻量并不完全对立，EJB3就是为了简化J2EE的使用，使得EJB不只是擅长处理大型企业系统，中小型系统也使用很方便，这实际上也是EJB轻量化的一种努力。什么是Java EE 5？

　　所以，对于架构选择来说，根本前提是需要明白你的系统现在或将来一段时间（注意需要考虑将来一段时间，不能只看眼前）是中小型系统还是大型系统？

灵活性/定制性/透明性

　　当然这个答案有时我们自己也可能很难给出，那么我们还需要从其他角度来考量EJB和非EJB之选，例如笔者曾经经历一个大型实时娱乐平台社区系统，从规模上说肯定是大型系统，设计目标10万人在线，从这个角度非选用EJB不可！

　　但是，EJB因为还有事务机制，虽然应用程序可以选择失效EJB事务，但是EJB容器设计因为考虑了事务，所以在其内核上总是会显得臃肿，是一种累赘，这也是一种重量表示，不需要的东西存在肯定会影响效率，那么难道我不能根据我的需求，对EJB整体包括EJB容器进行可配置式的切割？也就是说，我上面这个案例只需要EJB的分布式计算功能，其他的功能我都拆除，只剩余我需要的功能能运行就可以了，轻装上阵。

　　可惜，这种任意切割，应需而定的目标在EJB3标准还没有被重视，所幸的是，Ioc/AOP技术为这种目标实现提供了实现可能，但是，只有Ioc/AOP还是不够，特别是看Ioc的范围，如果你只把应用系统组件纳入Ioc管理时，自由解耦只属于应用系统，我上面案例的目标还是无法达到，当你把框架本身组件也纳入Ioc管理时，任意切割，应需而定的目标才真正实现。

　　Spring和EJB3属于“只把应用系统组件纳入Ioc管理”，这从JBoss 4.0版本可以看出；那什么框架会把框架本身组件也纳入Ioc管理呢？Apache的Hivemind和笔者开发的Jdon框架。

　　什么样的组件可以被纳入Ioc管理呢？POJO组件，POJO这个概念其实当初是针对EJB缺点而推出，EJB要求应用系统的组件必须继承或依赖EJB容器，这样使得调试变的不方便，但是后来，POJO的概念已经不只最初这些概念，POJO代表那种与周围完全脱离关系、自由自在的Object了，如果应用系统的Model或者Service都是POJO，意味着你的应用系统不依赖任何其他系统，解耦性灵活性高。

　　POJO是因为EJB而提出的，当EJB自己倾向POJO时，大家都在宣称自己是POJO时，POJO概念就没有立足点了，这也是Java领域哭笑不得的现象，但是我个人更倾向把非EJB的JavaBeans组件通称为POJO。

　　Hivemind的Ioc依赖注射部分功能和Jdon框架非常类似，当上百个POJO组件配置时，完全不必指定它们之间的依赖关系；你可以将自己应用程序的组件注册到Registry中，这样Hivemind将帮助你启动这些组件，正如你在Jdon框架中将你的组件写入mycontainer.xml中，Jdon框架也将自动启动你这些组件，并解决它们之间的互相调用，包括和框架本身组件互动。

　　HiveMind和Jdon框架定义的POJO Service有如下特点：

　　不象EJB那样缺乏本地透明化(location transparency)概念，这些POJO Service总是能定位到同样一个JVM；也不象基于XML的Web服务web services那样没有语言透明(language transparency)概念，这些POJO Service总是可以被一组Java接口来概括替代(通过调用Java interface来替代调用这些具体Service)；当然，更不会类似JMX或Jini，不能进行service的热装载（ hot-loading）。

　　注意：当Ioc/AOP提供高度灵活的同时，已经有初学者开始抱怨Spring的过分灵活，那么比Spring在组件上更灵活的Jdon框架只能算是一种追求极端，它不一定构成你进行架构选择的主要依据！

　　上面这些讨论只是表明在灵活性（解耦性/透明性）这条需求道路上深究下去的选择，你自己的应用系统需求会产生各种不同的要求，有些要求甚至是极致的，这种偏向程度就成为你架构选择的目标，如果你的这种极致要求在目前Java世界里还没有可选框架时，那么你就要动手自己做了，这也说明什么时候你开始自己做框架（如Jdon框架），虽然在大多数情况下我们是不必要自己发明轮子的。

快速构建性

　　前面是从灵活性和定制性这个角度讨论架构选择目标，但是在一般情况下，我们还是从上手难易、开发效率这个角度来进行架构选择，从这个角度来说，就是需要我们将选用的框架尽可能的多帮助我们实现一些功能，但这又是和使用难易是矛盾的，因此有个取舍问题，取舍有个准则：这个框架尽量能提供越多功能；尽量需要我们少写代码，甚至不写代码（使用XML配置），少动脑筋。

　　关于XML配置这里也涉及难易问题，XML配置语法不能太复杂，有太多小开关Switch也增加学习成本。

　　从这个角度看，EJB无论是EJB2或EJB3提供的功能是最齐全的，但是XML配置开关太多 ，Spring属于中等，组件XML配置不算简单，但是因为有不少Struts+Spring+Hibernate之类现成开源代码可供参考，因此学习起来难度也不大，Spring越来越象一个J2EE API（注意，JDK是J2SE API） ，Spring除不能提供分布式计算外，也因为过分灵活降低了一些开发效率，例如它的组件依赖关系一般需要逐步指定，auotwiring功能还没有深入骨髓成为核心功能。Ioc容器的革命性优点。

　　Spring除了提供组件层功能以外，还有表现层支持Spring MVC；也有持久层实现的JDBC模板，这样，整个J2EE/Java EE系统各个层次Spring都提供了缺省实现，在这方面无疑提高了开发效率，但是Spring提供丰富API目的好像不是为了快速开发，而是为了建立一个完整的功能齐全的API功能库。正如它网页上开头文字所述：As the leading full-stack Java/J2EE application framework，注意full-stack（完整齐全）是它突出的名词。

　　那么，还有另外一个空白，就是以开发效率为主要考虑，这类框架除了必须考虑足够灵活性和丰富功能以外，宗旨是为了在一般缺省情况下快速完成一个J2EE/Java EE系统，这非常类似MDA工具了，但是一个完全丧失灵活性和定制性的MDA工具也不是我们欢迎的。

　　Jdon框架的发展目标是为了填补这个空白，相信也会越来越多框架向这个目标迈进，当然不可否认，Spring也可能调转枪头走入这个领域，EJB2/EJB3正依靠JBuilder等这样商业化开发工具向这个领域靠拢，这个发展方向实际是4GL RAD Tools。

　　很多人在快速构建方面也很早进行了探索，涌现出各种工具：如何构建一个快速业务构件平台？ 但是如何把快速构建和构件（组件）灵活性有机结合在一起？它是考验一个业务构件（业务组件）平台好坏的准则。有些构件平台虽然开发迅速，但是对于特殊情况，可供程序员定制透明操作部分不多，很死，典型的是两层结构以前的Delphi，开发很快速，但是无法象J2EE这样深入到系统各个层次进行定制/维护/拓展！

业务组件框架对比

持久层框架

　　持久层框架目前有EJB2/EJB3的实体Bean、Hibernate和各种JDO产品，当然还有直接写SQL语句的JDBC，如iBatis等。

　　持久层框架质量好与坏区分就是是否是O/R Mapping，也就是对象和关系数据库映射，关系数据库需要实现定义好Schema结构；对象因为字段而变的也有一个自己的结构，如何将对象数据自动持久化到数据库中，首先我们得定义两者结构的对应，这实际是数据的元数据定义。

　　因为Hiberante/Toplink/JDO这样O/R Mapping工具帮助你实现对象和数据库转换，克服了对象和数据库阻抗现象，O/R Mapping总结 ，所以才使得我们更多的可以对象方式（从模型Model对象）来考虑Java EE/J2EE系统，可以完全放弃以前那种以数据库为中心的思维方式：数据库时代的终结。

　　所以，是否选用好的持久层框架，取决于你整个团队思维是否彻底OO了，是否需要真正OO，当然，对于一些小型项目，有时我们觉得直接使用JDBC模板反而更加轻松快捷一点，这也是Spring的JDBC模板/iBatis/Jdon的Jdbc模板存在的理由了。

例如新增一个数据表，在Jdon框架只需要下面几行代码即可：

　　这种方式和O/R Mapping兴师动众的多个XML配置和关系映射思考相比，对于习惯SQL语句的程序员反而更加迅速。

　　从以上可以看出，灵活性/快速性/简单性/可伸缩性是我们进行架构选择的主要几个依据，架构选择实际就是在这几个策略之间做一个平衡。当然，还有一个非常重要的因素，因为它不属于某个层次的技术，性能/缓存是必须和上面因素综合考虑的因素。

　　因为性能最初是我们使用计算机的基本原因，别忘记这个根本。

相关文章

面向对象与领域建模

J2EE中几种业务代理模式的实现和比较

JBoss 5迎来Java的彻底的可配置时代

Ioc模式(又称DI：Dependency Injection)

IOC模式的思考和疑问

关于SPING与EJB的胡言乱语--重和轻永恒的话题

Simplify the Best：详论轻量框架

欢迎讨论

What is Multitiered Application?
出自sun对宠物商店例子的综述文档?

Partitioning a design into tiers allows designers to choose
the appropriate technology for a given situation. The Java
Pet Store demo, illustrates how its design is divided into
multiple tiers.
使用分层的方式来进行设计，可以使设计者针对具体的情况使用合适
的技术。这个Java 宠物商店的例子展示了如何把一个设计分成多层结构。

The Client tier is often the only part of the application the
user sees. The Java Pet Store demo Client tier consists of a
browser displaying web pages generated from JSP pages in the
Web tier. An administrator interface uses a spreadsheet client,
such as StarOffice software, to communicate with the Web Tier
XML messages. The Client tier communicates with other tiers
through defined interfaces.
客户层通常是用户唯一可以看到的应用程序的部分。这个宠物商店例子
的客户层是一个浏览器，它负责显示Web层中JSP页产生的web页面。一个
管理员接口可以使用一个spreadsheet客户端（例如StarOffice软件）来
和Web层交换XML消息。客户层通过定义好的接口和其他层交互。

The Web tier performs web-related processing, such as serving
HTML, instantiating web page templates, and formatting JSP pages
for display. Some objects within the Web tier act as proxies to
components in the Enterprise JavaBeans components tier.
Web层负责Web相关的处理，比如提供HTML服务，产生web页面的模板的实作，
格式化JSP页面来显示。Web层中有一些物件可以作为EJB组件层中组件的
代理。

The Enterprise JavaBeans components tier is responsible for any
processing involving Enterprise JavaBeans components. Enterprise
JavaBeans components contain the business logic of the Java Pet
Store demo, such as processing orders. EJB components also
represent the model objects of the Java Pet Store demo, including
Account and placed Orders.
EJB组件层负责任何与EJB组件相关的处理。EJB组件中包含这个Java宠物商店
的商业逻辑，比如处理订单。EJB组件也含有这个Java宠物商店的物件模型，
包括账目和处理过的订单。

Stand-alone clients and web applications in the Web tier can use
Enterprise JavaBeans components hosted by the Enterprise JavaBeans
components tier. The Java Pet Store demo demonstrates the proper
use of Enterprise JavaBeans components.
单机版客户端和网络层中的web应用都可以使用EJB组件层中的EJB组件。这个
Java宠物商店的例子展示了如何恰当地使用EJB组件。

The Enterprise Information System (EIS) tier provides a layer of
software that maps existing data and application resources into
the design of a J2EE application in an implementation-neutral way.
The EIS tier can also access applications of other organizations
or businesses, providing seamless business-to-business integration.
企业信息系统（EIS）层提供了一层软件，以一种与实现无关的方式把已存在
的数据和应用资源一起映射到一个J2EE应用程序的设计之中。EIS层通过B2B的
无缝集成使得其它的组织或商业机构也可以对其进行使用。

大概从2003年下半年开始，Spring＋Hibernate就开始甚嚣尘上，似乎那时候的Spring和Hibernate尚且不足以动摇J2EE规范以EJB为核心的领袖地位。但是2004年5月份，吸收了Spring/Hibernate框架优点的EJB3 JCP委员会的成立，事实上宣判了Spring对EJB2的终结，EJB3则更像是Vendor们的一种自救行为。

2004年到2006这三年时间以来，Spring取得了相当辉煌的成就，不但将EJB2赶进历史，而且牢牢确立了Spring作为Java企业应用开发的主流地位。而今，甚至对技术比较保守的金融电信行业，也开始言必称Spring，Spring已经成为Java框架的事实标准。

在2004年5月份之后，Hibernate Team开始和Spring公然决裂，这个事情放在两年多以后的今天来看，原因是昭然若揭的，背靠JBoss的Hibernate Team已经成为EJB3规范的一部分，而JBoss希望力推的以EJB3为核心的Java架构来成为未来的企业应用主流标准，这种情况演变至今，变成了Springframework和JBoss Seam的两种不同技术架构的竞争关系。

2004年5月份，EJB3规范的起步，对Spring未来其实有很大的威胁，但是EJB3规范历经两年时间的难产，终于在2006年5月正式发布之时，已经为时过晚了，抬眼望去，已尽是spring的天下。

有意思的是，大致展望一下未来，Java的企业应用开发还能遵循Sun和JCP制订的Java EE规范的道路走下去吗？如果不是这样，那么未来道路是什么呢？

观察一下Java社区几股大的势力，会发现一些有意思的现象：

IBM和BEA是Java社区的领导者，从2004年开始，IBM和BEA开始大肆宣传SOA，将他们的目光从应用服务器领域挪到了松藕合企业服务领域，开展SOA商业战略。与此同时，EJB3专家委员会的领导者也悄然变成了JBoss和Oracle，是IBM和BEA无力争取吗？当然不是。IBM和BEA已经看到了应用服务器市场和底层框架平台即将被开源占领，商业价值萎缩，因而审时度势进行战略转型。一方面押宝SOA战略，大肆炒热和培育SOA市场，另一方面也积极占领开源市场，IBM放出来WebSphere社区版本－Apache Geronimo，BEA干脆和Spring的咨询公司interface21合作，提供spring框架在WebLogic上的商业技术支持，如今EJB3对于他们来说已经形同鸡肋，就抛给别人嚼吧。

将EJB3当块宝的自然是应用服务器市场的跟随者JBoss和Oracle，一方面凭借ORM的先天优势，另一方面有出头机会也不能放过，EJB3委员会几乎成了JBoss和Oracle的天下。特别是JBoss，更加积极推出JBoss Seam框架，希望确立以JSF＋EJB3的架构树立Java开发的标准，用以取代Struts/Spring/Hibernate的流行组合，因而开启了EJB3和Spring 正面交锋的战争。

Java Vendor中另外一股势力Sun公司这两年则一直自顾不暇，在应用服务器领域几乎退出市场，直到最近才搞出来一个Glassfish，在开发框架领域也一直毫无建树，推出的JSF至今还很不成熟，难担大任，也许Sun都去忙着开源Solaris和JVM源代码了。

几个大的Vendor或战略转型，或自顾不暇，或忙于收购(Oracle)，Java开发领域的主战场被打扫一空，对决的双方换成了Spring和JBoss。对决的武器则是spring vs Seam。

Spring代表了不遵循通用标准，自己制订游戏规则，不依赖容器的一方；JBoss代表了遵循通用标准，但是锁定容器的一方。这场对决从2004年5月就开始上演，未来很长时间也会继续下去。不过Spring已经站在优势很大的地位上了。

大致对比一下两者：Spring vs EJB3，就会发现Spring从功能上面已经胜出很多了：

1、IoC容器spring胜出

Spring的IoC容器很强大，其bean管理功能超过了目前EJB3容器，配置方面Spring稍微复杂一些。不过对于全局性配置来说，XML要优于EJB3的annotation。

2、AOP能力Spring胜出

EJB3目前提供的AOP功能非常简单，本来已经无法和Spring相比，至于集成AspectJ的Spring2.0，就更加望尘莫及了。

3、事务管理方面EJB3稍微领先

Spring提供了很棒的本地事务模型，也可以集成JTA，但是不支持分布式事务，当然这种场景也非常罕见。

4、Web框架spring胜出

EJB3标准集成JSF，但是JSF并不成熟，和AJAX配合度也不好。Spring可以灵活集成各种Web框架和模板语言，自身也提供了相当强大的MVC框架，要是这还觉得不够，那么spring webflow，portlet support都拿出来。

5、远程访问支持，大致持平

EJB3继承了传统的EJB远程访问能力，Web Services支持也不错；不过Spring提供了更多更灵活的选择，Java RPC，HTTP Invoker，Hessian/Burlap，WebServices。

6、框架集成能力，spring胜出

这是spring的传统优势项目，只要看看spring modules项目，看看n多第三方spring支持，就会发现spring现在的群众基础多么好，集成工作流，spring modules已经提供了方便的模板类，集成规则引擎，Cache，CMS，脚本语言，异步任务，安全验证框架。。。。。。EJB3有点望尘莫及的味道

7、JMS，JMX，JCA等，EJB3领先一步

这些传统EJB优势项目往往应用的不太多，EJB3仍然是领先的。不过令人侧目的是，Spring最近几个版本在连续追赶EJB这些传统优势领域，到Spring2.0为止，其JMS，JMX，JCA支持已经相当不错了，可以说传统EJB能够做的，现在Spring也可以做得到。

这几年除了Spring框架自身不断完善和延伸到传统应用领域，围绕在Spring周围的第三方框架也是越来越丰富，EJB3在annotation方面有些独到的优势，在一些传统领域，还领先spring，但是总体来说，EJB3为核心的J2EE5.0规范很难和Spring现在的2.0相匹敌，更何况Java的主力Vendor早已醉翁之意不在这里了，单凭JBoss的Seam，难以战胜spring。

目前JBoss已经开始在国内进行商业上的推广，也希望以其EJB3技术来和Springframework相抗衡，JBoss目前用来说服客户使用EJB3的理由主要有两点：

1、EJB3是一个标准，由多个厂商提供实现
2、JBoss的EJB3由Red Hat公司及其合作伙伴提供技术支持，而springfrmework在国内还没有商业技术支持

1.Write your business class : DTO,FormBean,Action,Service Interface,Service Implementation.

2.Write JSP pages.

3.struts-config.xml Configuration : FormBean,Action,Forward pages.

4.applicationContext-service.xml Configuration: add your Service Interface and Service Implementation.

5.Add your service factory Get method to ServiceFactory.java

6.Build project and Generate the Description file(*.hbm.xml) of DTO.

7.applicationContext.xml Configuration: add *.hbm.xml file to applicationContext for O/R mapping. 

Java Naming and Directory Interface (JNDI)

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

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




Context ctx = new InitialContext();




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


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: T提供了与客户端的会话交互，可以存储状态从而代表一个客户。典型例子是购物车。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。

JavaServer Pages (JSPs)

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

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

Date JSP sample

The current date is .

您可能有时候听说过JHTML。这是JSP以前的一种较老的标准。WebLogic服务器既可支持JSP，又可支持JHTML。请注意，在缺省状况下，JSP在WebLogic服务器中并没有处于有效状态。要使之有效，你可以编辑weblogic.properties文件。如果Web服务器还没有处于有效状态，则要先使之有效。Servlet的情况和JSP是一样的。

下面是: Java servlets

Java servlets

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

servlet是一种小型的Java程序，它扩展了Web服务器的功能。作为一种服务器端的应用，当被请求时开始执行，这和CGI Perl脚本很相似。Servlets和CGI脚本的一个很大的区别是：每一个CGI在开始的时候都要求开始一个新的进程 -- 而servlets是在servlet引擎中以分离的线程来运行的。因此servlets在可伸缩性上提供了很好的改进。

在开发servlets的时候，您常常需要扩展javax.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事务管理器为应用服务器、资源管理器、独立的应用以及通信资源管理器提供了事务服务。

JavaMail and JavaBeans Activation Framework

JavaMail是用于存取邮件服务器的API，它提供了一套邮件服务器的抽象类。不仅支持SMTP服务器，也支持IMAP服务器。

JavaMail利用JavaBeans Activation Framework (JAF)来处理MIME-编码的邮件附件。MIME的字节流可以被转换成Java对象，或者转换自Java对象。由此大多数应用都可以不需要直接使用JAF。

Java Messaging Service (JMS)

JMS是用于和面向消息的中间件相互通信的应用程序接口(Java Naming and Directory Interface (JNDI)

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

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




Context ctx = new InitialContext();




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


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: T提供了与客户端的会话交互，可以存储状态从而代表一个客户。典型例子是购物车。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。

JavaServer Pages (JSPs)

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

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

Date JSP sample

The current date is .

您可能有时候听说过JHTML。这是JSP以前的一种较老的标准。WebLogic服务器既可支持JSP，又可支持JHTML。请注意，在缺省状况下，JSP在WebLogic服务器中并没有处于有效状态。要使之有效，你可以编辑weblogic.properties文件。如果Web服务器还没有处于有效状态，则要先使之有效。Servlet的情况和JSP是一样的。

下面是: Java servlets

Java servlets

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

servlet是一种小型的Java程序，它扩展了Web服务器的功能。作为一种服务器端的应用，当被请求时开始执行，这和CGI Perl脚本很相似。Servlets和CGI脚本的一个很大的区别是：每一个CGI在开始的时候都要求开始一个新的进程 -- 而servlets是在servlet引擎中以分离的线程来运行的。因此servlets在可伸缩性上提供了很好的改进。

在开发servlets的时候，您常常需要扩展javax.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事务管理器为应用服务器、资源管理器、独立的应用以及通信资源管理器提供了事务服务。

JavaMail and JavaBeans Activation Framework

JavaMail是用于存取邮件服务器的API，它提供了一套邮件服务器的抽象类。不仅支持SMTP服务器，也支持IMAP服务器。

JavaMail利用JavaBeans 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。
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。