j2ee

J2EEJ2EE（Java 2 Platform, Enterprise Edition）是一个为大企业主机级的计算类型而设计的Java平台。Sun微系统（与其工业伙伴一起，例如IBM）设计了J2EE，以此来简化在受客户级环境下的应用开发。由于创造了标准的可重用模块组件以及由于构建出能自动处理编程中多方面问题的等级结构，J2EE简化了应用程序的开发，也降低了对编程和对受训的程序员的要求。^[2]

J2EE本身是一个标准，而不是一个现成的产品（虽然现在有很多符合J2EE标准的产品），它由以下几个部分组成：

（1）J2EE规范。该规范定义了J2EE平台的体系结构、平台角色及J2EE中每种服务和核心API的实现要求。它是J2EE应用服务器开发商的大纲。

（2）J2EE兼容性测试站点。Sun公司提供的一个测试J2EE应用服务器是否符合J2EE规范的站点，对通过该站点测试的产品，Sun公司将发放兼容性证书。

（3）J2EE参考实现。即J2EESDK，它既是Sun公司自己对J2EE规范的一个非商业性实现，又是为开发基于J2EE企业级应用系统原型提供的一个免费的底层开发环境。

（4）J2EE实施指南。即BluePrints文档，该文档通过实例来指导开发人员如何去开发一个基于J2EE的多层企业应用系统。^[3]

Java于1995年由Sun公司推出，当时它的主要用途是制作产生动态网页的Applet。后来，人们发现Java的“一次开发，多次运行”，纯面向对象的特性，垃圾回收机制和内置安全特别适合于开发企业应用系统。于是，企业应用开发商纷纷在Java标准版的基础上各自扩展出许多企业应用API，其结果导致基于Java的企业应用呈爆炸式增长。但是各企业系统API之间又不能相互兼容，破坏了Java的平台独立性。鉴于此，Sun公司联合IBM、Oracle、BEA等大型企业应用系统开发商于1999年共同制订了一个基于Java组件技术的企业应用系统开发规范，该规范定义了一个多层企业信息系统的标准平台，旨在简化和规范企业应用系统的开发和部署。这一规范和其定义的平台就构成了J2EE。它定义了基于组件的方式设计、开发、组装和部署企业应用系统的各个组成部分。同时，J2EE规范定义了分布式多层应用系统模型、组件重用策略、一体化的安全模型以及灵活的事务控制策略等，使得独立软件提供商（ISV）能够以比以前更快的速度向市场推出适应用户的解决方案。

J2EE是一套针对企业级分布式应用的计算环境。它定义了动态Web页面功能（Servlet和Jsp）、商业组件（EJB）、异步消息传输机制（JMS）、名称和目录定位服务（JNDI）、数据库访问（JDBC）、与子系统的连接器（JCA）和安全服务等。^[3]

1997年Servlet技术的产生以及紧接着JSP的产生，为Java对抗PHP、ASP等服务器端语言带来了筹码。1998年，Sun发布了EJBI.0标准，至此J2EE平台的三个核心技术都已经出现。于是，1999年，Sun正式发布了J2EE的第一个版本，并于1999年底发布了J2EE1.2，在2001年发布了J2EEl.3，在2003年年底发布了J2EE1.4。

（1）J2EE1.3

J2EE1.3的架构，其中主要包含了Applet 容器、Application Client容器、Web容器和EJB容器，并且包含了Web Component，EJB Component，Application Client Component，以JMS，JAAS，JAXP，JDBC，JAF，JavaMail，JTA等技术做为基础。

J2EE1.3中引入了几个值得注意的功能：Java消息服务（定义了JMS的一组APl），J2EE连接器技术（定义了扩展J2EE服务到非J2EE应用程序的标准），XML解析器的一组Java APl，Servlet2.3，JSPl.2也都进行了性能扩展与优化，全新的CMP组件模型和MDB（消息Bean）。

（2）J2EE1.4

J2EE1.4大体上的框架和J2EE1.3是一致的，J2EE1.4增加了对Web服务的支持，主要是Web Service，JAX-RPC，SAAJ，JAXR，还对EJB的消息传递机制进行了完善（EJB2.1），部署与管理工具的增强（JMX），以及新版本的Servlet2.4和JSP2.0使得Web应用更加容易。^[4]

发展背景

1、 企业级应用框架的需求在许多企业级应用中，例如数据库连接、邮件服务、事务处理等都是一些通用企业需求模块，这些模块如果每次在开发中都由开发人员来完成的话，将会造成开发周期长和代码可靠性差等问题。于是许多大公司开发了自己的通用模块服务。这些服务性的软件系列统称为中间件。

2、 为了通用必须要提出规范，不然无法达到通用

在上面的需求基础之上，许多公司都开发了自己的中间件，但其与用户的沟通都各有不同，从而导致用户无法将各个公司不同的中间件组装在一块为自己服务。从而产生瓶颈。于是提出标准的概念。其实J2EE就是基于JAVA技术的一系列标准。

注：中间件处在操作系统和更高一级应用程序之间。它充当的功能是：将应用程序运行环境与操作系统隔离，从而实现应用程序开发者不必为更多系统问题忧虑，而直接关注该应用程序在解决问题上的能力。容器的概念就是中间件的一种。

Sun公司在1998年发表JDK1.2版本的时候， 使用了新名称Java 2 Platform，即“Java2平台”，修改后的JDK称为Java 2 Platform Software Develping Kit，即J2SDK。并分为标准版(Standard Edition，J2SE), 企业版(Enterprise Edition，J2EE)，微型版(MicroEdition，J2ME)。J2EE便由此诞生。

2005年6月，JavaOne大会召开，SUN公司公开Java SE 6。此时，Java的各种版本已经更名以取消其中的数字“2”：J2EE更名为Java EE, J2SE更名为Java SE，J2ME更名为Java ME。

Java2平台包括标准版（J2SE）、企业版（J2EE）和微缩版（J2ME）三个版本。

目前，Java 2平台有3个版本，它们是适用于小型设备和智能卡的Java 2平台Micro版（Java 2 Platform Micro Edition，J2ME）、适用于桌面系统的Java 2平台标准版（Java 2 Platform Standard Edition，J2SE）、适用于创建服务器应用程序和服务的Java 2平台企业版（Java 2 Platform Enterprise Edition，J2EE）。J2EE是一种利用Java 2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE技术的基础就是核心Java平台或Java 2平台的标准版，J2EE不仅巩固了标准版中的许多优点，例如"编写一次、随处运行"的特性、方便存取数据库的JDBC API、CORBA技术以及能够在Internet应用中保护数据的安全模式等等，同时还提供了对 EJB（Enterprise JavaBeans）、Java Servlets API、JSP（Java Server Pages）以及XML（标准通用标记语言的子集）技术的全面支持。其最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。

J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台，J2EE降低了开发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，完全支持Enterprise Java Beans，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。

J2EE是由SUN公司开发的一套企业级应用规范。2009年04月20日，甲骨文74亿美元收购Sun。取得java的版权。2011年7月，甲骨文公司发布java7的正式版。支持J2EE的应用服务器有IBM Web Sphere Application Server,Oracle Weblogic SERVER,Jboss,SUN GlassFish，东方通Tong Web等。

在旧金山举行的2011年Java One大会上，甲骨文公司展示了其推动Java 平台企业版（Java EE）发展的最新成果。

Java EE 继续大受欢迎，并有越来越多的开发人员采用，包括Oracle GlassFish Server在内的Java EE组件获得了4000万次下载。

自2009年12月推出以来，6个主要IT厂商已经推出了经过认证、开源和商业实施的Java EE 6，使其成为迄今为止最迅速获得采用的平台产品。

作为下一代Java EE, Java EE 7进展顺利，其中，有超过20个的不同参与企业和数百名工程师通过Java 社区（JCP）对10个活跃的Java规范要求(JSRs)进行了开发处理。

Java EE 7 JSRs 包括：Java EE 7 平台, Java Persistence API 2.1,JAX-RS2.0: 用于RESTful网络服务的 Java API, Servlet 3.1, 表达语言 3.0, Java 信息服务 2.0, JavaServer Faces 2.2, Enterprise JavaBeans 3.2, 面向Java EE 1.1的Contexts and Dependency Injection , Bean Validation 1.1.等。

Java EE 7专家组也在寻求把其他JSRs加入到Java EE 7的可能性，这些JSRs包括JCache 1.0 – Java Temporary Caching API, Concurrency Utilities 1.0, Java 状态管理 1.0 和Java Identity API 1.0。

Java EE 7旨在进一步增强Java EE平台的云环境。因此，基于Java EE-7的应用和产品将能够在私有云和公有云中更方便地操作，并通过支持多用户租用和弹性使用（如平行扩展）等功能来实现功能即服务。

作为Java EE的参考实施，GlassFish服务器不仅仅是全面的Java EE 6实施，（开源版是GlassFish 服务器开源版，商业版是Oracle Glass Fish服务器），还为即将推出的Java EE 7提供了坚实的基础。

Oracle Glass Fish服务器完善了Oracle Web Logic 服务器 11g，后者是一款专门为运行Oracle 融合中间件11g的广泛产品组合以及可内部部署和云部署的大规模企业应用而设计的服务器。

甲骨文在2011 年JavaOne大会的136个联合研讨会、BOF和动手实验室，以及Java One展览馆中对Java EE及相关技术进行了展示。

j2ee

J2EE为搭建具有可伸缩性、灵活性、易维护性的企业系统提供了良好的机制。

1.支持异构环境

J2EE能够开发部署在异构环境中的可移植程序。不管是大型机、UNIX平台还是Windows操作系统，基于J2EE开发的应用程序不依赖任何特定操作系统、中间件、硬件。因此，设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。这在典型的异构企业计算环境中是十分关键的。J2EE标准也允许客户订购与J2EE兼容的第三方的现成的组件，把他们部署到异构环境中，从项目开发整体来看，既加快了开发速度，又节省了完成整体方案所需的费用。

2.可伸缩性

企业必须要选择一种服务器端平台，这种平台应能提供极佳的可伸缩性，满足那些在他们系统上进行商业运作的大批客户。基于J2EE平台的应用程序可被部署到各种操作系统上。例如可被部署到高端UNIX与大型机系统，这种系统单机可支持64~256个处理器。J2EE领域的供应商提供了更为广泛的负载平衡策略，能消除系统中的瓶颈，允许多台服务器集成部署。这种部署可达数千个处理器，实现可高度伸缩的系统，满足未来商业应用的需要。

3.稳定的可用性

一个服务器端平台必须能全天候运转以满足公司客户、合作伙伴的需要。因为Internet是全球化的、无处不在的，即使在夜间停机维护也可能造成严重损失。若是意外停机，更会造成灾难性后果。J2EE可以部署到可靠的操作环境中，因此支持长期的可用性。一些J2EE部署在Windows环境中，客户也可选择健壮性能更好的操作系统，如Sun Solaris、IBMOS/390等。最健壮的操作系统可达到99.999%的可用性或每年只需5分钟停机时间，这是实时性要求很高的企业系统的理想选择。

4.保留现存的IT资产

由于企业必须适应新的商业需求，利用已有的企业信息系统投资，而不是重新制定全盘方案就变得很重要。也就是说，企业需要的是一个以渐进的（而不是激进的，全盘否定的）方式进行、可构建在已有系统之上的服务器端平台机制。J2EE架构可以充分利用用户原有的投资，如一些公司使用的BEA Tuxedo、IBM CICS、IBM Encina、Inprise VisiBroker和Netscape Application Server等。这之所以成为可能，是因为J2EE 拥有广泛的业界支持和一些重要的企业计算领域供应商的参与。

每一个供应商都对现有的客户提供了不用废弃已有投资，进入可移植的J2EE领域的升级途径。由于基于J2EE平台的产品几乎能够在任何操作系统和硬件配置上运行，现有的操作系统和硬件也能继续发挥作用。

5.高效的开发

J2EE允许公司把一些通用的、烦琐的服务器端任务交给中间件供应商去完成。这样开发人员可以集中精力在如何创建商业逻辑上，相应地缩短了开发时间。高级中间件供应商可以提供以下这些复杂的中间件服务：

（1）状态管理服务。让开发人员写更少的代码，不用关心如何管理状态，这样能够更快地完成程序开发。

（2）持续性服务。让开发人员不用对数据访问逻辑进行编码就能编写应用程序，能生成更轻巧、与数据库无关的应用程序，这种应用程序更易于开发与维护。

（3）分布式共享数据对象CACHE服务。让开发人员编制高性能的系统，极大提高整体部署的伸缩性。

这种基于组件，具有平台无关性的J2EE 结构使得J2EE 程序的编写十分简单，因为业务逻辑被封装成可复用的组件，并且J2EE服务器以容器的形式为所有的组件类型提供后台服务。因为你不用自己开发这种服务，所以你可以集中精力解决手头的业务问题。

容器和服务容器设置定制了J2EE服务器所提供的内在支持，包括安全，事务管理，JNDI(Java Naming and Directory Interface）寻址，远程连接等服务，以下列出最重要的几种服务：

J2EE安全（Security）模型可以让你配置 web 组件或enterprise bean，这样只有被授权的用户才能访问系统资源. 每一客户属于一个特别的角色，而每个角色只允许激活特定的方法。你应在enterprise bean的布置描述中声明角色和可被激活的方法。由于这种声明性的方法，你不必编写加强安全性的规则。

J2EE事务管理（Transaction Management）模型让你指定组成一个事务中所有方法间的关系，这样一个事务中的所有方法被当成一个单一的单元. 当客户端激活一个enterprise bean中的方法，容器介入一管理事务。因有容器管理事务，在enterprise bean中不必对事务的边界进行编码。要求控制分布式事务的代码会非常复杂。你只需在布置描述文件中声明enterprise bean的事务属性，而不用编写并调试复杂的代码。容器将读此文件并为你处理此enterprise bean的事务。JNDI寻址（JNDI Lookup）服务向企业内的多重名字和目录服务提供了一个统一的接口，这样应用程序组件可以访问名字和目录服务。

J2EE远程连接（Remote Client Connectivity）模型管理客户端和enterprise bean间的低层交互。当一个enterprise bean创建后，一个客户端可以调用它的方法就象它和客户端位于同一虚拟机上一样。

生存周期管理（Life Cycle Management）模型管理enterprise bean的创建和移除，一个enterprise bean在其生存周期中将会历经几种状态。容器创建enterprise bean，并在可用实例池与活动状态中移动他，而最终将其从容器中移除。即使可以调用enterprise bean的create及remove方法，容器也将会在后台执行这些任务。

数据库连接池（Database Connection Pooling）模型是一个有价值的资源。获取数据库连接是一项耗时的工作，而且连接数非常有限。容器通过管理连接池来缓和这些问题。enterprise bean可从池中迅速获取连接。在bean释放连接之后可为其他bean使用。

J2EE的体系结构可以分为四层。

·客户端层：负责与用户直接交互，J2EE支持多种客户端，所以客户端既可以是WEB浏览器，也可以是专用的Java客户端。

·服务器端组件层：本层是为了基于WEB的应用服务的，利用J2EE中的JSP与Java Servlet技术，可以响应客户端的请求，并向后访问封装有商业逻辑的组件。

·EJB层：本层主要封装了商务逻辑，完全企业计算机，提供了事务处理，负载均衡、安全、资源连接等各种基本服务，程序在编写EJB时可以不关心这些基本的服务，集中注意力于商务逻辑的实现。

·企业信息系统层：企业信息系统层包括了企业的现有系统（包括数据库系统、文件系统），J2EE提供了多种技术以访问这些系统，如JDBC访问DBMS。

在J2EE规范中，J2EE平台包括有一整套的服务、应用编程接口和协议，可用于开发一般的多层应用和基于WEB的多层应用，是J2EE的核心和基础。它还提供了EJB、Java Servlets API、JSP和XML技术的全面支持等。^[5]

J2EE应用组件可以安装部署到以下几种容器中去：

EJB 容器管理所有J2EE 应用程序中企业级bean 的执行。enterprise bean 和它们的容器运行在J2EE服务器上。

Web 容器管理所有J2EE 应用程序中JSP页面和Servlet组件的执行。 Web 组件和它们的容器运行在J2EE 服务器上。应用程序客户端容器管理所有J2EE应用程序中应用程序客户端组件的执行。应用程序客户端和它们的容器运行在J2EE 服务器上。Applet 容器是运行在客户端机器上的web浏览器和 Java插件的结合。

J2EE是Java 2 enterprise edition是Java的一种企业版用于企业级的应用服务开发

J2SE是Java 2 standard edition是Java的标准版，用于标准的应用开发

J2ME是Java 2 Micro Edition是Java的微型版，常用于手机上的开发

J2EE，J2SE，J2ME是java针对不同的的使用来提供不同的服务，也就是提供不同类型的类库。

J2EE使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用组件根据他们所在的层分布在不同的机器上。事实上，sun设计J2EE的初衷正是为了解决两层模式（client/server）的弊端，在传统模式中，客户端担当了过多的角色而显得臃肿，在这种模式中，第一次部署的时候比较容易，但难于升级或改进，可伸展性也不理想，而且经常基于某种专有的协议，通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。现在J2EE 的多层企业级应用模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层，以下是 J2EE 典型的四层结构：

运行在客户端机器上的客户层组件

运行在J2EE服务器上的Web层组件

运行在J2EE服务器上的业务逻辑层组件

运行在EIS服务器上的企业信息系统（Enterprise information system）层软件

J2EE应用程序是由组件构成的。J2EE组件是具有独立功能的软件单元，它们通过相关的类和文件组装成J2EE应用程序，并与其他组件交互。J2EE规范中定义了下列J2EE组件：

（1）客户层组件，包括客户端应用程序和Applets；

（2）Web层组件，包括Java Servlet和Java Server Pages（JSP）；

（3）业务层组件，即Enterprise JavaBeans（EJB）。

J2EE应用程序可以是基于web方式的，也可以是基于传统方式的.

J2EE web层组件可以是JSP 页面或Servlets.按照J2EE规范，静态的HTML（标准通用标记语言下的一个应用）页面和Applets不算是web层组件。

正如下图所示的客户层那样，web层可能包含某些 JavaBean 对象来处理用户输入，并把输入发送给运行在业务层上的enterprise bean 来进行处理。

业务层代码的逻辑用来满足银行，零售，金融等特殊商务领域的需要，由运行在业务层上的enterprise bean 进行处理. 下图表明了一个enterprise bean 是如何从客户端程序接收数据，进行处理（如果必要的话），并发送到EIS 层储存的，这个过程也可以逆向进行。

有三种企业级的bean: 会话（session) beans，实体（entity) beans，和消息驱动（message-driven) beans. 会话bean 表示与客户端程序的临时交互. 当客户端程序执行完后，会话bean 和相关数据就会消失. 相反，实体bean 表示数据库的表中一行永久的记录. 当客户端程序中止或服务器关闭时，就会有潜在的服务保证实体bean 的数据得以保存.消息驱动 bean 结合了会话bean 和 JMS的消息监听器的特性，允许一个业务层组件异步接收JMS 消息。^[4]

企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资源计划(ERP），大型机事务处理，数据库系统，和其它的遗留信息系统. 例如，J2EE 应用组件可能为了数据库连接需要访问企业信息系统。

容器：充当中间件的角色。

WEB容器：给处于其中的应用程序组件（JSP，SERVLET）提供一个环境，使JSP,SERVLET直接与容器中的环境变量接口交互，不必关注其它系统问题。主要由WEB服务器来实现。例如：TOMCAT,WEBLOGIC,WEBSPHERE等。该容器提供的接口严格遵守J2EE规范中的WEB APPLICATION 标准。我们把遵守以上标准的WEB服务器就叫做J2EE中的WEB容器。

EJB容器：Enterprise java bean 容器。更具有行业领域特色。他提供给运行在其中的组件EJB各种管理功能。只要满足J2EE规范的EJB放入该容器，马上就会被容器进行高效率的管理。并且可以通过现成的接口来获得系统级别的服务。例如邮件服务、事务管理。

WEB容器和EJB容器在原理上是大体相同的，更多的区别是被隔离的外界环境。WEB容器更多的是跟基于HTTP的请求打交道。而EJB容器不是。它是更多的跟数据库、其它服务打交道。但他们都是把与外界的交互实现从而减轻应用程序的负担。例如SERVLET不用关心HTTP的细节，直接引用环境变量session,request,response就行、EJB不用关心数据库连接速度、各种事务控制，直接由容器来完成。

RMI/IIOP：远程方法调用internet对象请求中介协议，他们主要用于通过远程调用服务。例如，远程有一台计算机上运行一个程序，它提供股票分析服务，我们可以在本地计算机上实现对其直接调用。当然这是要通过一定的规范才能在异构的系统之间进行通信。RMI是JAVA特有的。

JNDI:JAVA命名目录服务。主要提供的功能是：提供一个目录系统，让其它各地的应用程序在其上面留下自己的索引，从而满足快速查找和定位分布式应用程序的功能。

JMS:JAVA消息服务。主要实现各个应用程序之间的通讯。包括点对点和广播。

JAVAMAIL:JAVA邮件服务。提供邮件的存储、传输功能。他是编程中实现邮件功能的核心。相当MS中的EXCHANGE开发包。

JTA：JAVA事务服务。提供各种分布式事务服务。应用程序只需调用其提供的接口即可。

JAAS:JAVA安全认证框架。提供一些安全控制方面的框架。让开发者通过各种部署和自定义实现自己的个性安全控制策略。

EAI:企业应用集成。是一种概念，从而牵涉到好多技术。J2EE技术是一种很好的集成实现。

j2ee为了联系实际，GOULD基于WEBLOGIC应用服务器（来自BEASYSTEMS公司的一种广为应用的产品）环境来介绍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

过去，二层化应用--通常被称为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-ODBCBRIDGE

在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,MICROSOFTSQLSERVER以及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字段的内容进行输出。

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:

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: 提供了与客户端的会话交互，可以存储状态从而代表一个客户。典型例子是购物车。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的表达式则放在<%=和%>；之间。

您可能有时候听说过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的时候，您常常需要扩展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系统相集成。

XML（标准通用标记语言的子集）

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

总结

在本文中，我们介绍了建立在J2EE上的分布式应用结构，并且描述了WEBLOGIC服务器对J2EE的各种支持。然而，我们所揭示的仅仅是冰山之一角而已，要以一篇数千字的文章来展示J2EE潜在的对您的企业级应用的影响可是很不公平的。

我们已经关注了在您开始用J2EE进行工作时最有可能遇到的各类技术：JDBC,JNDI,EJB,JSP和SERVLET。我们也为您提供了一些尚未常见的J2EE技术的背景知识。不管您是一名开发人员，商务应用分析师，或者项目经理，都应该对J2EE和WEBLOGIC服务器所能提供给我们，给我们的企业以及我们的企业级应用所带来的意义有一个更好的认识。

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

使用元数据，注释代替传统的配置文件成为了新的热点。JPA更是代替了传统的CMP作为了更加便捷的持久化的方案。

组件标准

J2EE平台由一整套服务（services）、应用程序接口（APIs）和协议构成，它对开发基于Web的多层应用提供了功能支持，下面对J2EE中的主要技术规范进行简单的描述。

1.JDBC（Java Database Connectivity）

JDBCAPI为访问不同的数据库提供了一种统一的途径，像ODBC一样，JDBC对开发者屏蔽了一些细节问题。另外，JDBC对数据库的访问也具有平台无关性。

2.JNDI（Java Name and Directory Interface）

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

3.EJB（Enterprise JavaBean）

EJB技术是在Java Bean本地组件技术基础上开发的面向服务器端分布应用的组件技术。EJB是Sun推出的J2EE规范的一部分，自从J2EE推出之后，得到了广泛的发展，已经成为应用服务器端的标准技术。JB提供了一个开发和实施分布式商务逻辑的框架，大大地简化了具有可伸缩性和高度复杂的企业级应用的开发。EJB规范定义了EJB组件如何与EJB容器（container）进行交互。容器负责提供公用服务，如目录服务、事务管理、安全性、资源缓冲池以及容错性等。但EJB并不是实现J2EE的唯一途径。正是由于J2EE的开放性，使得有的厂商能够以一种和EJB平行的方式来达到同样的目的。

EJB基于Java语言，提供了基于Java二进制字节代码的重用方式。EJB技术的推出，使得用Java基于组件技术开发服务器端分布式应用成为可能。从企业应用多层结构的角度来看，EJB是业务逻辑层的中间件技术。与JavaBeans的关键不同是它提供了事务处理的能力。

4.JSP（Java Server Pages）

JSP页面由HTML代码和嵌入其中的Java代码所组成。服务器在页面被客户端所请求后对页面中的Java代码进行处理，然后将生成的HTML页面返回给客户端的浏览器。

5.Java Servlet Servlet是一种小型的Java程序，它扩展了Web服务器的功能。

作为一种服务器端的应用，和CGI脚本类似，当被请求时开始执行。Servlet提供的功能与JSP类似，但实现方式不同。JSP通常在大量的HTML代码中嵌入少量的Java代码，而servlets全部由Java写成并且生成HTML。

6.RMI/IIOP

RMI（Remote Method Invocation，远程方法调用）是Java的分布式对象标准，允许位于不同主机上的Java类之间进行通信。Java RMI是个应用程序编程接口（API），还是个分布对象模型；使用RMI，Java程序员可以像调用本地操作一样进行网络调用，从而很容易地构造分布式系统。IIOP协议本来是CORBA的一种传输协议，和RMI结合在一起，使得整合非Java对象变得更加简单。

7.Java IDL/CORBA

在Java IDL的支持下，开发人员可以将Java和CORBA集成在一起。他们可以创建Java对象并在CORBAORB中部署，或者创建 Java类作为和其他ORB一起部署的CORBA对象的客户。后者可用于遗留系统的集成。

8.XML（Extensible Markup Language）

XML是一种可以用来定义其他标记语言的语言。它被用来在不同的商务过程中共享数据。XML的发展和Java是相互独立的，但是，它和Java具有的相同目标正是平台独立性。Java和XML的组合构成一个完美的具有平台独立性的解决方案。

9.JavaMail

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

10.JAF（JavaBeans Activation Framework，JavaBeans 激活框架）

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

11.JMS（Java Message Service）

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

12.JTA（Java Transaction Architecture，Java事务构架）

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

13.JTS（Java Transaction Service，Java事务服务）

JTS是CORBAOTS事务监控的基本实现。JTS规定了事务管理器的实现方式。该事务管理器是在高层支持 Java Transaction API（JTA）规范，在系统底层实现OMGOTS规范的Java映像。JTS事务管理器为应用服务器、资源管理器、独立的应用以及通信资源管理器等提供事务服务。

J2EE事务并发访问主要可以分为两类，分别是同一个系统事务和跨事务访问的并发访问控制，其中同一个系统事务可以采取乐观锁以及悲观锁策略，而跨多个系统事务时则需要乐观离线锁和悲观离线锁。

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

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

一般可以采用以下三种方法：

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

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

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

在JDBC和Hibernate中使用乐观锁：

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

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

Select a.version....from Account as a where (where condition..)

Update Account set version = version+1.....(another field) where version =?...(another contidition)

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

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

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

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

提交事务时，hibernate内部会生成相应的SQL语句将版本字段加1，并且进行相应的版本检测，如果检测到并发乐观锁定异常，那么就抛出Stale Object State Exception.

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

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

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

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

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中支持悲观锁的两种模式Lock Mode.UPGRADE以LockMode.UPGRADE_NO_WAIT.(PS：在JPA中，对应的锁模式是Lock Mode Type.Read，这与Hibernate是不一样的呵呵）

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

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

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

从整体上讲，J2EE是使用Java技术开发企业级应用的一种事实上的工业标准(Sun公司出于其自身利益的考虑，至今没有将Java及其相关技术纳入标准化组织的体系)，^[6]它是Java技术不断适应和促进企业级应用过程中的产物。目前，Java平台有三个版本：适用于小型设备和智能卡的J2ME(Java 2 Platform Micro Edition)、适用于桌面系统的J2SE和适用于企业级应用的J2EE。Sun推出J2EE的目的是为了克服传统Client/Server模式的弊病，迎合Browser/Server架构的潮流，为应用Java技术开发服务器端应用提供一个平台独立的、可移植的、多用户的、安全的和基于标准的企业级平台，从而简化企业应用的开发、管理和部署。J2EE是一个标准，而不是一个现成的产品。各个平台开发商按照J2EE规范分别开发了不同的J2EE应用服务器，J2EE应用服务器是J2EE企业级应用的部署平台。由于它们都遵循了J2EE规范，因此，使用J2EE技术开发的企业级应用可以部署在各种J2EE应用服务器上。