J2EE的13项核心技术

Java最初是在浏览器和客户端机器中粉墨登场的. 当时, 很多人质疑它是否适合做服务器端的开发. 现在, 随着对Java2平台企业版(J2EE)第三方支持的增多, Java被广泛接纳为开发企业级服务器端解决方案的首选平台之一.

　　J2EE平台由一整套服务(Services), 应用程序接口(API)和协议构成, 它对开发基于Web的多层应用提供了功能支持.

　　在本文中将解释支撑J2EE的13种核心技术: JDBC, JNDI, EJBs, RMI, JSP, Java Servlets, XML, JMS, Java IDL, JTS, JTA,

JavaMail 和 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(可扩展标记语言)和(可扩展样式表语言).

　　业务逻辑: 业务逻辑适合用Session EJBs 来实现.

　　数据访问: 数据访问适合用Entity EJBs 和 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, 对这些将作更仔细的考察.

<1> Java Database Connectivity (JDBC)
-------------------------------------------------

　　JDBC API 以一种统一的方式来对各种各样的数据库进行存取. 和ODBC一样, JDBC为开发人员隐藏了不同数据库的不同特性. 另外由于JDBC建立在Java的基础上, 因此还提供了数据库存取的平台独立性.

　　JDBC定义了4种不同的驱动程序, 现分述如下:

　　类型 1: JDBC-ODBC Bridge

　　在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, Microsoft SQL
Server以及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字段的内容进行输出.

import java.sql.*;

public class JDBCExample
{
　　public static void main(String args[])
　　{
　　 try{

　　 Class.forName("COM.cloudscape.core.JDBCDriver");
　　 Connection conn = DriverManager.getConnection("jdbc:cloudscape:PhoneBook");

　　 Statement stmt = conn.createStatement();
　　 String sql = "SELECT name, phone FROM CONTACT_TABLE ORDER BY name";
　　 ResultSet resultSet = stmt.executeQuery( sql );
　　 String name;
　　 String phone;

　　 while (resultSet.next())
{
　　 name = resultSet.getString(1).trim();
　　 phone = resultSet.getString(2).trim();
　　 System.out.println( name + ", " + phone );
　　 }

　　 }catch (Exception e) { e.printStackTrace(); //Handle exception here }
　　}
}

　　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.

<2> Java Naming & 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.

<3> Enterprise Java Beans (EJB)
-------------------------------------------------

　　J2EE技术之所以赢得广泛重视的原因之一就是EJB. 它们提供了一个框架来开发和实施分布式商务逻辑, 由此很显著地简化了具有可伸缩性和高度复杂的企业级应用的开发. EJB规范定义了EJB组件在何时如何与它们的容器进行交互作用. 容器负责提供公用的服务,

例如: 目录服务, 事务管理, 安全性, 资源缓冲池以及容错性.

　　EJB规范定义了3中基本的Bean类型:

　　1. Stateless session beans: 提供某种单一的服务, 不维持任何状态, 在服务器故障发生时无法继续存在, 生命期相对较短.

例如: 一个stateless session bean可能被用于执行温度转换计算.

　　2. Stateful session bean: T供了与客户端的会话交互, 可以存储状态从而代表一个客户. 典型例子是购物车.

Stateful session bean在服务器故障时无法继续生存, 生命期相对较短. 每一个实例只用于一个单个的线程.

　　3. 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.

<4> Java Server 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

<5> 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, 等等.

<6> Remote Method Interface (RMI)
-------------------------------------------------

　　正如其名字所表示的那样, RMI协议是在远程对象上调用一些方法. 它使用了连续序列方式在客户端和服务器端传递数据. RMI是一种被EJB使用的更下层的协议.

<7> Java IDL/CORBA
-------------------------------------------------

　　在Java IDL的支持下, 开发人员可以将Java和CORBA集成在一起. 他们可以创建Java对象并使之可在CORBA
ORB中展开, 或者它们还可以创建Java类并作为和其它ORB一起展开的CORBA对象的客户. 后一种方法提供了另外一种途径,
通过它Java可以被用于将新的应用和legacy系统相集成.

<8>Java Transaction Architecture (JTA)
-------------------------------------------------

　　JTA定义了一种标准的API, 应用系统由此可以存取各种事务监控.

<9> Java Transaction Service (JTS)
-------------------------------------------------

　　JTS是CORBA OTS事务监控的基本的实现. JTS规定了事务管理器的实现方式. 该事务管理器是在高层支持Java
Transaction API(JTA)规范, 并且在较底层实现OMG OTS specification的Java映像.
JTS事务管理器为应用服务器, 资源管理器, 独立的应用以及通信资源管理器提供了事务服务.

<10> JavaMail
-------------------------------------------------

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

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

<11> JavaBeans Activation Framework (JAF)
-------------------------------------------------

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

<12> Java Messaging Service (JMS)
-------------------------------------------------

　　JMS是用于和面向消息的中间件相互通信的应用程序接口(API). 它既支持点对点的域,
有支持发布/订阅(publish/subscribe)类型的域, 并且提供对下列类型的支持: 经认可的消息传递, 事务型消息的传递,
一致性消息和具有持久性的订阅者支持. JMS还提供了另一种方式来对应用与legacy backend系统相集成.

<13> EXtensible Markup Language (XML)
-------------------------------------------------

　　XML是一种可以用来定义其它标记语言的语言. 它被用来在不同的商务过程中共享数据. XML的发展和Java是相互独立的. 但是,
它和Java具有的相同目标正是平台独立性. 通过将Java和XML的组合, 可以得到一个完美的具有平台独立性的解决方案.
目前正有许多不同的公司在为Java和XML的组合而努力.

如果要了解更多的这方面的信息, 可以访问Sun的Java-XML页面, 或者 IBM developerWorks 的 XML Zone.