J2EE学习者越来越多，J2EE本身技术不断在发展，涌现出各种概念，本文章试图从一种容易理解的角度对这些概念向初学者进行解释，以便掌握学习J2EE学习方向。

　　首先我们需要知道Java和J2EE是两个不同概念，Java不只是指一种语言，已经代表与微软不同的另外一个巨大阵营，所以Java有时是指一种软件系统的流派，当然目前主要是.NET和Java两大主流体系。

　　J2EE可以说指Java在数据库信息系统上实现，数据库信息系统从早期的dBase、到Delphi/VB等C/S结构，发展到B/S（Browser浏览器/Server服务器）结构，而J2EE主要是指B/S结构的实现。

　　J2EE又是一种框架和标准，框架类似API、库的概念，但是要超出它们。如果需要详细了解框架，可先从设计模式开始学习。

　　J2EE是一个虚的大的概念，J2EE标准主要有三种子技术标准：WEB技术、EJB技术和JMS，谈到J2EE应该说最终要落实到这三个子概念上。

　　这三种技术的每个技术在应用时都涉及两个部分：容器部分和应用部分，Web容器也是指Jsp/Servlet容器，你如果要开发一个Web应用，无论是编译或运行，都必须要有Jsp/Servlet库或API支持（除了JDK/J2SE以外）。

　　Web技术中除了Jsp/Servlet技术外，还需要JavaBeans或Java Class实现一些功能或者包装携带数据，所以Web技术最初裸体简称为Jsp/Servlet+JavaBeans系统。

　　谈到JavaBeans技术，就涉及到组件构件技术（component），这是Java的核心基础部分，很多软件设计概念（设计模式）都是通过JavaBeans实现的。

　　JavaBeans不属于J2EE概念范畴中，如果一个JavaBeans对象被Web技术（也就是Jsp/Servlet）调用，那么JavaBeans就运行在J2EE的Web容器中；如果它被EJB调用，它就运行在EJB容器中。

　　EJB（企业JavaBeans）是普通JavaBeans的一种提升和规范，因为企业信息系统开发中需要一个可伸缩的性能和事务、安全机制，这样能保证企业系统平滑发展，而不是发展到一种规模重新更换一套软件系统。

　　至此，JavaBeans组件发展到EJB后，并不是说以前的那种JavaBeans形式就消失了，这就自然形成了两种JavaBeans技术：EJB 和POJO，POJO完全不同于EJB概念，指的是普通JavaBeans，而且这个JavaBeans不依附某种框架，或者干脆可以说：这个 JavaBeans是你为这个应用程序单独开发创建的。

　　J2EE应用系统开发工具有很多：如JBuilder、 Eclipse等，这些IDE首先是Java开发工具，也就是说，它们首要基本功能是可以开发出JavaBeans或Java class，但是如果要开发出J2EE系统，就要落实到要么是Web技术或EJB技术，那么就有可能要一些专门模块功能(如eclipse需要 lomboz插件)，最重要的是，因为J2EE系统区分为容器和应用两个部分，所以，在任何开发工具中开发J2EE都需要指定J2EE容器。

　　J2EE容器分为WEB容器和EJB容器，Tomcat/Resin是Web容器；JBoss是EJB容器+Web容器等，其中Web容器直接使用 Tomcat实现的。所以你开发的Web应用程序可以在上面两种容器运行，而你开发的Web+EJB应用则只可以在JBoss服务器上运行，商业产品 Websphere/Weblogic等和JBoss属于同一种性质。

　　J2EE容器也称为J2EE服务器，大部分时它们概念是一致的。

　　如果你的J2EE应用系统的数据库连接是通过JNDI获得，也就是说是从容器中获得，那么你的J2EE应用系统基本与数据库无关，如果你在你的J2EE 应用系统耦合了数据库JDBC驱动的配置，那么你的J2EE应用系统就有数据库概念色彩，作为一个成熟需要推广的J2EE应用系统，不推荐和具体数据库耦合，当然这其中如何保证J2EE应用系统运行性能又是体现你的设计水平了。

　　衡量J2EE应用系统设计开发水平高低的标准就是：解耦性；你的应用系统各个功能是否能够彻底脱离？是否不相互依赖，也只有这样，才能体现可维护性、可拓展性的软件设计目标。

　　为了达到这个目的，诞生各种框架概念，J2EE框架标准将一个系统划分为WEB和EJB主要部分，当然我们有时不是以这个具体技术区分，而是从设计上抽象为表现层、服务层和持久层，这三个层次从一个高度将J2EE分离开来，实现解耦目的。

　　因此，我们实际编程中，也要将自己的功能向这三个层次上靠，做到大方向清楚，泾渭分明，但是没有技术上约束限制要做到这点是很不容易的，因此我们还是必须借助J2EE具体技术来实现，这时，你可以使用EJB规范实现服务层和持久层，Web技术实现表现层；

　　EJB为什么能将服务层从Jsp/Servlet手中分离出来，因为它对JavaBeans编码有强制的约束，现在有一种对JavaBeans弱约束，使用Ioc模式实现的（当然EJB 3.0也采取这种方式），在Ioc模式诞生前，一般都是通过工厂模式来对JavaBeans约束，形成一个服务层，这也是是Jive这样开源论坛设计原理之一。

　　由此，将服务层从表现层中分离出来目前有两种可选架构选择：管理普通JavaBeans（POJO）框架(如 Spring、JdonFramework)以及管理EJB的EJB框架，因为EJB不只是框架，还是标准，而标准可以扩展发展，所以，这两种区别将来是可能模糊，被纳入同一个标准了。　但是，个人认为：标准制定是为某个目的服务的，总要牺牲一些换取另外一些，所以，这两种架构会长时间并存。

　　这两种架构分歧也曾经诞生一个新名词：完全POJO的系统也称为轻量级系统(lightweight)，其实这个名词本身就没有一个严格定义，更多是一个吸引人的招牌，轻量是指容易学习容易使用吗？按照这个定义，其实轻量Spring等系统并不容易学习；而且EJB 3.0（依然叫EJB）以后的系统是否可称为轻量级了呢？

　　前面谈了服务层框架，使用服务层框架可以将 JavaBeans从Jsp/Servlet中分离出来，而使用表现层框架则可以将Jsp中剩余的JavaBeans完全分离，这部分JavaBeans 主要负责显示相关，一般是通过标签库（taglib）实现，不同框架有不同自己的标签库，Struts是应用比较广泛的一种表现层框架。

　　这样，表现层和服务层的分离是通过两种框架达到目的，剩余的就是持久层框架了，通过持久层的框架将数据库存储从服务层中分离出来是其目的，持久层框架有两种方向：直接自己编写JDBC等SQL语句（如iBatis）；使用O/R Mapping技术实现的Hibernate和JDO技术；当然还有EJB中的实体Bean技术。

　　持久层框架目前呈现百花齐放，各有优缺点的现状，所以正如表现层框架一样，目前没有一个框架被指定为标准框架，当然，表现层框架现在又出来了一个JSF，它代表的页面组件概念是一个新的发展方向，但是复杂的实现让人有些忘而却步。

　　在所有这些J2EE技术中，虽然SUN公司发挥了很大的作用，不过总体来说：网络上有这样一个评价：SUN的理论天下无敌；SUN的产品用起来撞墙；对于初学者，特别是那些试图通过或已经通过SUN认证的初学者，赶快摆脱SUN的阴影，立即开溜，使用开源领域的产品来实现自己的应用系统。

　　最后，你的J2EE应用系统如果采取上面提到的表现层、服务层和持久层的框架实现，基本你也可以在无需深刻掌握设计模式的情况下开发出一个高质量的应用系统了。

　　还要注意的是: 开发出一个高质量的J2EE系统还需要正确的业务需求理解，那么域建模提供了一种比较切实可行的正确理解业务需求的方法，相关详细知识可从UML角度结合理解。

　　当然，如果你想设计自己的行业框架，那么第一步从设计模式开始吧，因为设计模式提供你一个实现JavaBeans或类之间解耦参考实现方法，当你学会了系统基本单元JavaBean或类之间解耦时，那么系统模块之间的解耦你就可能掌握，进而你就可以实现行业框架的提炼了，这又是另外一个发展方向了。

　　以上理念可以总结为一句话：Java学习开发三件宝: Domain Model（域建模）、Patterns（模式）和Framework（框架）。集三宝理念于一身，小中型J2EE项目快速开发工具：Jdon Framework
----------------------------------------------------------------------------------------------------

JoannaYe ask:
你好 Banq先生 关注你的文章很长一段时间了, 对你在Java领域的技术水平,以及在很多问题上的看法, 也非常佩服. 国内目前达到你的水平的人真是很少(当然高人也许都隐居起来了). 但是, 有几个问题想与你讨论:
首先,软件是一个绝对的应用技术,任何技术离开了具体的应用, 坦率地说是毫无价值的.我看,Jdon也有在这方面的尝试,如网站,网上商店生成系统等.但这与真正的企业应用还有非常大的距离. 我不了解,你在这一领域里为什么没有涉足,是因为你认为很困难,基本上是以我们国内目前的技术水平无法到达呢, 还是因为你不屑于这方面的深入, 认为你所追求的是纯粹超然的技术概念呢.
我的其他问题有赖于了解你关于这个问题的回答,让我们继续关注和讨论.

banq answer:
 
>但这与真正的企业应用还有非常大的距离. 我不了解,你在这一领域里为什么没有涉足,是因为你认为很困难,基本上是以我们国内目前的技术

多谢探讨，这个问题很复杂，大概有下列几点：
1. 现在软件技术不再象以前的技术，以前的技术可以说只有做个这个行业大型软件系统的经验的人才可以说对这些软件技术有掌握，而现在的技术则不必了，J2EE 讲究架构，J2EE它是一套应用软件的规范，也就是说，J2EE是很多做过大型软件的人进行汇总后的经验精华，一个大型系统需要哪些技术部分、什么时候适合什么技术，在J2EE标准中基本都有涉及，例如EJB技术、JMS等。

这样，如果你能完全掌握和驾驭这些J2EE架构技术，你有时确实不必一定要做个大型软件经验才型，这称为站在巨人的肩膀上。

但是反过来，如果你没有丰富的软件系统实战经验，你去理解EJB/JMS等就很困难，所以这两个技术对初学者比较难的原因之一。

2. UML结合J2EE这样OO一套实施过程从方法论以及模式角度固化了软件数据库系统的分析设计开发，这也是因为有MDA（将这些过程用软件自动生成代码）诞生的原因。虽然这些简化了我们开发系统的过程，但是这只是解决了应用系统的一部分问题，工作流等尚未成熟，使用这样方式开发系统，依据我的经验，最后会将烦琐和细致的工作压在Jsp页面上，目前开发一个系统，结合标签库和用户界面需求这个工作反而花费我更多时间，希望JSF在这方面能有效率提升，等这些技术细节都能解决，基本J2EE非常成熟了。

3.目前我通过咨询角色和一些软件公司一起承接一些企业应用项目，例如去年承接一个大型外资人事系统，他们要求管理GE 等几家外资企业的人事福利（这些企业外包人事给他们），如果专为一家公司开发人事很简单，但是要求这个人事适合多家，那么重用性要求很高，设计抽象面很高，他们在新加坡有类似系统，但技术很老，我听过新加坡的系统，他们也有一些经验总结，大部分和我的J2EE设计相吻合，我和新加坡的人交流过想法，他们很惊奇，不太相信，加上费用问题，只进行了初步架构设计就搁浅了。

4.不要小看网站系统，以前网站系统都是用PHP Perl做，功能很弱，无法和企业系统相比，但是随着Inernet普及，更多人要求联网，例如如果一家公司的ERP通过互联网实现，那么老总出差就很方便，但是现在为一家公司开发一个基于internet的ERP很贵，比传统的贵，这不合理，这也是SOA提出的目的之一，以后ERP实现网上租用，就象你申请一个Blog或论坛或Email，你可以为你的企业申请一个ERP系统，这样只要企业付租费就可以了，这可理想目前已经接近，前段时间美国一家提供这种服务的企业来上海做宣传，他们的业绩增长速度极其快 500%.

通过网站提供ERP等企业服务对于软件设计的重用性要求很高，就一套邮箱系统可以服务很多用户一样，你必须设计出一套重要性、灵活性很高的ERP系统适合不同的用户，可见网站软件的水平是极其高的。前面我做的网站自动生成系统到现在我都认为完成不够好，现在很多网站都提供这种服务，这象Blog，但是Blog等只限制你网站模板，而不是自由定制页面，所以 Blog这些都是小孩玩家家，根本无发走向商业，著名的那个方兴东鼓吹Blog，其实没有技术革新，靠你媒体吹呼就是革命了。
 
JoannaYe ask:

谢谢 Banq 先生在6月23日非常认真的回复(抱歉由于忙,没能马上回复). 总结起来, 如果我的理解不错的话, 你的结论是 1)你认为网站系统并不可小觑(同意,一个高访问量,同时能够实现网上交易的网站的确如此).2)EJB/JMS技术对于初学者来说是不容易,但是对你来说,你是可以Handdle的. 3)你也有承接企业系统的实际经验,象你说的那个HR系统. 但不知您以咨询身份参加的这个HR系统到底都解决的是实际管理中的什么样的问题?在性能方面都达到了什么样的水平? 具体来说,采用了哪些技术(诸如您帖中提到的一些技术)应对了实际中具体的什么样的问题. 此外以你在这个HR系统的经验来看, 是一个多少人的Team,采取什么样的开发方式和开发进度(人员和时间的分配比例)开发的.你认为在这样的一个项目的开发过程中最关键的是什么?最影响 Prductivity的又是什么?

对这样一些问题看上去似乎很空泛,但是实际上能够真正反映出我一开始提出的 issue,"软件是一个绝对的应用技术,任何技术离开了具体的应用, 坦率地说是毫无价值的".举个例子来说,书本上,名家们会告诉你, Value List Handler 这个设计模式是解决这样的问题:"You have a remote client that wants to iterate over a large results list." 一般来说,如果是一个大量地查找某一些"topic/dimension"下的数据,这样的问题,我们也毫无疑问地确定要用到这个模式.但是,如果对一条具体的数据,如某一个销售员,要和他的客户讨论(在线谈判)他们之间的一个具体合同,这时候会不会也需要用到这个模式.如果要用这个模式,到底是用 Stateful Session Bean 还是用 Stateless Session Bean 实现呢,他们各自在实现方法上对性能的影响是什么, 当你决定采用了某种实现方法,你到底是怎样Tradeoff的呢; 最后对这个设计模式来说,在最终的设计方案中如何把它抽象到对一个通用的,普遍的业务问题,而不是仅仅对"某一个销售员,要和他的客户讨论他们之间的一个具体合同"这样的一个特例问题,作出一个通用的解决方案,适应任意规模,任意业务的企业,真正达到软件工程的目标:高度的Reusing 和 Scalablity. 实际的企业应用系统就是充满着类似这样的问题,很有挑战.但有些技术人员就仅仅满足于自己可以用某项技术做出一些小的Demo了,就不愿意,或根本不屑于深入下去面对一个实际的应用问题.

因此, 我相信您应该能够非常理解,我为什么感兴趣了解您对我上面提出问题答案.

您的很多看法都很不错, 我非常同意, 希望我们能在今后进一步深入地探讨. 谢谢!

banq answer:

>你认为在这样的一个项目的开发过程中最关键的是什么?最影响 Prductivity的又是什么?

当这样的项目使用框架组件组合后，由于系统重要重用的功能已经封装在框架软件中，所以，只要能够组装出应用系统，一般第一次测试就会立即通过，我已经不止一次体会这种快感，我现在基本告别以前那种花费大量时间在Java调试上时代，我相信很多初学者还在这个泥潭里挣扎，这就成为影响一个产品的主要原因，现在使用jdon框架开发，几乎消灭这个因素。

那么,现在最影响 Prductivity的是什么？就是技术外的因素：项目管理。

关于你提的性能方面设计达到什么水平等，这些我已经整合进入Jdon框架，使用Jdon框架开发，几乎无需考虑性能设计，一开始就具有优越的性能，这些都是有测试数据，Java产品的好处就是一切可以自己动手，不必听从第三方评价，因为那些都有失公正，服务器配置上Jprofile/Optimizeit，客户端配置Jmeter，启动几个线程一跑，Jdon框架和应用程序的性能真相就出来了，所以，在Java领域，开源和商业产品是在同一起跑线，面对不同的用户：前者是更有头脑，自己动手；后者是对自己缺乏自信的人；服务是两者的重点。

>在最终的设计方案中如何把它抽象到对一个通用的,普遍的业务问题,而不>是仅仅对"某一个销售员,要和他的客户讨论他们之间的一个具体合同"这>样的一个特例问题

其实你说的行业框架提炼的问题，这和业务相关，Jdon框架等都是基础框架，没有这些组件框架的优雅解决方式，就没有行业框架的好的开始，我想你不希望在行业框架提炼之后，发现无法加入一些纵向功能，就象数据库设计好之后，几年以后却成为你发展的障碍。

行业框架需要资深的行业背景，这也不是一般人做的，但是工作流/Portal等都是行业框架的提炼，这些也是我们以后发展的方向。

就我个人来说，我愿意解决重要问题，然后我告诉更多人解决方向，如果他们相信，大家一起努力来解决所有问题，而不是靠我一个人解决所有问题。

JoannaYe ask:

谢谢Banq先生的回复, 你的很多观点都很好,我非常同意.象你所说最影响Prductivity的是技术外的因素：项目管理. 但我不知你能不能有一些具体的看法.因为任何行业,最终的问题, 竞争力的问题都是如何通过管理来提高Prductivity. 不知你对软件这一行业有没有特别的见解.

开源项目的确有它的优势,特别是作这些开源项目的人,往往是一些技术的精英.但是, 我还是以为应该以成熟的Commercial产品作为自己开发的基础,即所谓"巨人的肩膀". 这是因为, 成功的Commercial产品往往更注重最终用户, 这是这些产品能够给它的公司带来巨大的商业利润的源泉.纯技术的专家往往会忽视这一点.

要成就一件事(一个大型企业管理应用的项目), 是需要很多人踏踏实实,坚持不懈(这也非常重要)的努力.这和去上上课,或者在场外指导一下,有很大的区别.

我希望通过你这个论坛, 结识一些志同道合的朋友, 能够作成这样一件事.再次谢谢你的回复, 我因为很多时候很忙,有一些Deadline非常紧的事情,有时没能马上给您回复, 请你见谅.

banq answer:

非常感谢JoannaYe 讨论，从言论中感觉你是一个职业的项目经理。非常专业。

项目经理和设计师良好沟通和理解交流，是一个项目成功的关键。

关于开源和Commercial区别，我个人觉得它们之间真的没有严格的区别，只不过是两种思路的表现：开源通过免费产品卖服务；Commercial是既想卖产品又卖服务，不能因为它的产品卖钱，就是技术好，一般是市场品牌好。

就拿EJB实现来说，在所有J2EE服务器中只有开源JBoss 4.0使用AOP实现，坚持AOP的一些纯设计派认为EJB过时了，那么Weblogic /Websphere等这些以支持EJB自诩的服务器产品反而不如开源产品呢。这些人认为：EJB
但是正如你说：为什么客户还是购买Websphere等服务器，因为它们注重最终用户。

我认为一直试图在这两者之间寻找平衡是挑战的事情。

-------------------------------------------------------------------------------------------------------------------
 
shuiwx ask:
 
banq老师好，最近大致抽象总结出了一个比较浅显的规律，既是您平均一两个月能够发一篇比较的适合初学者的帖子，但每一篇都可以对偶的有关知识的梳理和导向能够起到很重要的作用，不敢说终生受用但也似乎会持久难忘了，在此还是要道一声感谢。

既然题目是初学者...高质量的J2EE系统，那么就题目本身这个用例来说，参与者该是“novice”了，领域模型应该是"高质量的"+"J2EE系统 ",那么能否请您再深一步的举个样例来说明何为"high quality j2ee system"呢？估计您不会选petshop,但有可能会将jive和jdon算进来，但偶真正想看到的是一个就您个人来讲曾经有过 consultant经验的项目作为例子来简要阐述下高质量+j2ee系统的概貌，或者象您前面某篇论oo和数据库的矛盾的文章一样，能否前瞻性的给出一个在您心目中最理想的高质量j2ee系统的轮廓呢？比如jsf(new version>1.1)+ejb3.0+j2ee设计模式?偶觉得struts+spring+hibernate并不敢称为高质量的或是 j2ee系统，所以总觉得从现在开始既该有意识的用一下jsf+ejb3来设计了，但由于不知道有没有人在这方面开始吃螃蟹了，所以只好去随大流的关心些什么ajax,xp之类的流行名词了。但从内心来讲，无论是javascript还是组件式编程，无论是spring+hibernate还是ejb3, 无论是xp还是fdd,无非是想尽量按照客户的要求迅速提交一个界面新颖，结构稳定的一个能够跨平台的良好的系统吧。假如能预知何为一个好的系统的话，似乎事情会变的简单些，也就不必为那些喋喋不休的争论着技术名词的人们所困扰了。

但由于目前偶的能力所限和所处的时期的特殊性，似乎想马上就拿jsf+ejb3来首选做企业级开发还有点不现实，那么作为一个apprentice来说，能够做的似乎只有学习模式了，偶不知道关于模式该学到多深才合适，只相信尽量选择从建模的时候就配合着设计模式来考虑可能会有助于系统的稳定和重用，谈到这里有引申出关于题目的另外一个话题，就是 “初学者”，偶觉得如果想作为计算机编程人员的话，面对着不停的新技术名词和版本更迭，似乎偶总要做一名初学着来的说，于是最近有意识的在看一些数据结构方面的课程，希望能够从一些理论基础中来寻找那些所谓的新技术背后所蕴涵的知识，但还是那句话，由于能力有限，所得甚浅，所以希望您如果能站在一个咨询家的角度来看，能否指点一下，就您认为的如果想设计一个好的软件系统来说，或许不仅限于j2ee,该多看看哪些computer science中的理论知识呢？偶不知道这个问题提的对不对，但总觉得设计模式对于系统的意义，是类似于数据结构和算法之相对于程序的意义的，所以假如您在类似的方面能有些心得的话，希望能够得到一点指点。

（偶的废话似乎不少，希望banq老师能忍受）
 
banq answer:

很抱歉现在才回复你的问题：
>如果想设计一个好的软件系统来说，或许不仅限于j2ee,该多看看哪些>computer science中的理论知识

设计一个好的软件系统我文章里其实写了，掌握分层解耦宗旨，学习使用一些现成的框架就可以了，如果你不原意囫囵吞枣，那么研究一下这些框架设计原理和模式，这些会花费你很长探索，数据结构、编译原理这些已经成为底层机制，就象汇编是底层一样，现在的大学计算机教学完全是错误的，学习的都是正确的废话。所以没有必要在那些大学课程上浪费时间。

增强项目经验，研读源码，自己动手编写项目是提升水平的唯一道路。
以上只是我个人意见。