Java EE/J2EE基本概念

技术背景

Java EE/J2EE基本概念

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的一种提升和规范，因为企业信息系统开发中需要一个可伸缩的性能和事务、安全机制，这样能保证企业系统平滑发展，而不是发展到一种规模重新更换一套软件系统。

J2EE集群原理: http://www.jdon.com/22282

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

J2EE应用系统开发工具有很多：如JBuilder、Eclipse等，这些IDE首先是Java开发工具，也就是说，它们首要基本功能是可以开发出JavaBeans或Java class，但是如果要开发出J2EE系统，就要落实到要么是Web技术或EJB技术，那么就有可能要一些专门模块功能，最重要的是，因为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应用系统运行性能又是体现你的设计水平了。

高质量的Java企业系统

衡量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不只是框架，还是标准，而标准可以扩展发展，所以，这两种区别将来是可能模糊，被纳入同一个标准了。

但是，通常标准制定是为某个目的服务的，总要牺牲一些换取另外一些，所以，这两种架构会长时间并存。

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

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

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

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

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

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

以上理念可以总结为一句话：

J2EE开发三件宝: Domain Model（域建模）、patterns（模式）和framework（框架）。

 

 

组件框架比较

 

EJB2/EJB3 Spring Framework Jdon Framework 灵活性 (松耦合) EJB3比EJB2更具灵活性，EJB3支持应用系统POJO 支持应用系统POJO，框架基础功能不能替换 支持应用系统POJO，框架本身可分离配置，定制性更强 功能完整性 全面，支持异步JMS 分布式事务 较为全面。有自己的表现层和持久层模板,可支持异步 基本完整，表现层借助Struts实现。有自己简单的持久层模板 单台性能 一般，批量查询等大数据量业务处理须小心，存在本地不透明缺陷。 一般，框架本身组件无性能提升极致，应用程序可配置cache/Pool 好，框架本身组件使用缓存提升性能，应用程序可配置cache/Pool，批量查询专门优化，适合实时性并发性要求较高应用 可伸缩性 可支持多台服务器分布式计算。 不支持，可依靠EJB实现 不支持，可依靠EJB实现 开发效率 学习曲线长,导致熟练掌握难。借助商业开发工具可加快熟练者的开发速度。 较为复杂，可挑选只适合自己的功能实现。当组件很多时，需要照顾这些组件之间调用关系。 简单快速，表现层编码很少。当组件个数很多时，无需照顾它们之间的调用关系 系统规模 EJB2适合大型系统;EJB3适合中大型系统 适合中小型系统 适合小中型系统，和EJB无缝结合，可借助EJB支持中大型系统 重量级别 重量，正在减肥 轻量偏重，有可能继续增肥 最轻量，恪守简单快速原则

详细文章见：http://www.jdon.com/artichect/java_ee_architecture.htm

 

Ioc框架

代码案例

假设有调用者B和被调用者A代码如下：

调用者B类

 package test;

 public class B{   

          AInfterface a;

public B(AInfterface a){ 

this.a = a

     }

          public void invoke(){

                a.myMethod();

          }

 }

被调用者A类：

package test;

 public class A  implements AInfterface {

          public void myMethod(){

               System.out.println("hello");

          }

 }

生成B类实例代码如下：

B b = new B(new A());

创建B的实例要逐个照顾到B类中涉及到所有其他类（如A类）的实例化，给编程者带来代码编写的琐碎工作，无法提高效率。

使用Jdon框架的Ioc模式后，B类生成实例代码如下：

B b =  (B)  WebAppUtil.getService(“b”);

b. invoke();

无需首先照顾其他类如A类的实例生成。B的实例生成再也与其他类如A类没有任何关系了，实现松耦合。如果B类中涉及不只是A类，还有C、D、E、F等类，那么生成B类实例时，我们就无需关心这些类的创建了。

实现上述调用效果，需另外进行一下jdonframework.xml配置如下：

<app>

   <services>

                    <pojoService name="b"  class="test.B"/>

                     <pojoService name="a"  class="test.A"/>

       </services>

   ……

</app>

革命性优点

两个革命性优点：

1. 颠覆对象使用之前必须创建的基本定律，正象无需关心对象销毁一样，您可以无需关心对象创建。

Java编程中类创建成实例的过程简化：（Class -> Instance）

使用Jdon等Ioc框架前：
编程者需要自己逐个解决这个Class相关涉及的其他Class的实例化。

使用Jdon等Ioc框架后：

无需编程者自己实现这种级联式、琐碎的实例化过程。

2. 松耦合；更换各种子类方便。面向对象编程之父Grady Booch 说：对象最伟大之处在于其可被替代。而Jdon框架伟大之处是帮助你替代这些对象，甚至包括Jdon框架本身。

上例中，如果Ainterface有另外一个实现子类AA类，只要将jdonframework.xml中：

<pojoService name="a"  class="test.A"/>

更换为：

<pojoService name="a"  class="test.AA"/>