<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>
部署EJB组件的艺术
（仙人掌工作室 ）
width=360 height=300 noresize scrolling=No frameborder="0" marginheight=0 marginwidth=0 src="http://www.cnnet.com.cn/servlets/ad?Pool=tech_pip" align="right"> Sun用“Write once，run anywhere”这一口号来推崇Java的跨平台移植能力。然而，对于大多数Java开发者来说，这个口号与其说反映了真实的Java应用部署，还不如说它代表着一个美好的、在一定程度上可以说远大的目标。例如，如果要让Java Applet在Netscape和IE浏览器中运行得完全一样，你得好好试验几次。类似地，在不同的Java兼容平台上，要让Java应用以完全同样的方式运行，你得耐心地进行一番辛苦的、彻底的测试。
但请不要误解我们的意思。Java是一种优秀的技术，特别是用来作为服务器端解决方案时，这一点尤其突出。我们认为，Java 2平台企业版（J2EE）是首选的Web服务开发环境。然而，对于Enterprise JavaBean（EJB），在不同的平台上部署同一EJB组件时也会出现一些与平台有关的问题。虽然我们完全有可能编写出部署方法统一的EJB代码，这些代码和应用服务器必须遵从同一版本的EJB规范。在很多情况下，要正确地安装和部署EJB，EJB的部署者必须针对不同的应用服务器进行不同的处理。
用初学者的眼光来看，本文介绍的是：在不同的应用服务器上部署同一EJB组件时，其部署过程的一些细微差别。这些应用服务器包括BEA的WebLogic、IBM的WebSphere和源代码开放组织的JBoss应用服务器。
一、EJB部署过程
在不同的应用服务器之间，EJB组件部署过程的不同由多种原因造成。首先，在描述如何部署EJB组件方面，EJB规范只提供了最小限度的指导。因此，供应商从不同的方向解释J2EE/EJB规范的这一部分，在为自己的平台定义组件部署步骤时，作出了各自的判断。
第二，组件部署是一个应用服务器供应商可以为其产品增值和增加独特功能的领域，供应商们把该过程标准化的热情不高。另外，这种部署标准的缺乏为应用服务器和Java IDE供应商带来了机会，使得它们能够集成自己的工具集，以便有效地方便EJB开发和部署——只有当你选择的IDE支持你的目标应用服务器时，这个过程才能得以简化。因此，对于一个给定的EJB，它的部署步骤必须根据具体情况进行分析，而且通常对于每一个应用服务器来说，部署步骤往往有所不同。
为了阐明这个问题，我们试验了两种EJB实现，一个LDAP（Lightweight Directory Access Protocol，轻量级目录访问协议）无状态会话Bean和一个简单的容器管理的实体（container-managed persistence，CMP）Bean。在这篇文章中，我们将了解把同一EJB部署到WebLogic、WebSphere和JBoss应用服务器时的主要不同之处。必须说明的是，虽然我们承认，如果利用与特定应用服务器密切关联的部署工具（例如，对于WebSphere服务器，使用VisualAge for Java），EJB部署过程将更加流畅；但是，这里我们将尽可能地用手工方式进行处理（利用vi/Emacs和JDK的jar工具编写代码、编写部署描述器文件、创建jar文件）。
为方便起见，文章最后提供了一个可下载的ZIP文件，它包含了本文用到的两个EJB示例，即HelloWorldLdap和ProfileTest。
二、HelloWorldLdap: LDAP无状态会话Bean
我们的第一个例子是一个无状态会话Bean，它从一个LDAP目录提取信息。用户（在这里是客户）可以在命令行指定一个LDAP服务器、email地址和DN（Distinguished Name）名称，EJB将从指定的目录提取该DN的所有属性。
类的路径问题可能干扰EJB和客户程序的编译。举例来说，我们选择把Netscape LDAP目录加入到第一个例子。一般而言，编译EJB代码的时候应该在类路径中指定J2EE JDK附带的j2ee.jar库，或者与它相当的库（对于JBoss，使用jboss.jar；对于WebLogic，使用weblogic.jar）。然而，编译客户程序的时候，类路径中还必须包含供应商的客户库，因为客户程序必须用到一个与特定供应商以及编译后的EJB组件有关的初始环境。另外，WebSphere客户程序还要求被部署的EJB jar文件也在classpath中。
成功地编译EJB之后就可以开始准备部署EJB。为部署Bean，META-INF目录下必须包含至少一个部署描述器（Deployment Descriptor）。本例的部署描述器ejb-jar.xml就位于该例子的META-INF目录下，在部署之前，我们把它和EJB类文件一起用jar打包。我们的第一个例子HelloWorldLdap有两个目录，即HelloWorldLdap和META-INF，这两个目录都属于同一目录层次。怀着以统一的方式部署Bean的希望，我们让EJB jar包包含以下内容：
在Unix Shell下，我们用以下命令打包EJB：
接下来，我们把HelloWorldLdap.jar部署到前面提到的三个应用服务器上。以下内容介绍我们在部署过程中的发现。
WebLogic有一个EJB部署准备工具，称为ejbc（即java weblogic.ejbc）。它有两个输入参数：包含类和部署描述器的jar文件的名字（例如，HelloWorldLdap.jar），以及我们为ejbc编译后的jar文件指定的名字（即HelloWeblogic.jar）。当jar文件编译不出现错误时，ejbc工具确实很不错；但如果EJB的构造存在问题，ejbc会变得相当恼人。尽管如此，ejbc仍旧是一个优秀的检验工具，它能够帮助我们在EJB部署之前找出错误。如果用ejbc编译jar文件，我们可以确信EJB能够在Weblogic上部署成功。
我们还试验了不用ejbc部署同一jar文件。对于简单的EJB，有可能获得成功；但是，不使用ejbc时，“热部署” EJB（在不关闭或者重新启动应用服务器的情况下，或者在不先行删除原有Bean实例的情况下，更新一个EJB）不能进行，而且此时我们不能再用ejbc进行确保部署成功的检验。
对于WebLogic，部署EJB时既可以简单地把jar文件复制到WL_HOME/config/your_domain/applications目录，或者也可以通过Web风格的管理控制台进行。在通过服务器日志报告部署中出现的问题时，WebLogic做得很出色。要检验部署是否成功，最简单的方法是利用管理控制台查看JNDI（Java Naming and Directory Interface）树。对于WebLogic，JNDI名字在另一个名为weblogic-ejb-jar.xml的部署描述器文件中指定。事实上，为了让示例EJB能够在WebLogic上部署成功，META-INF目录下必须存在这个部署描述器文件。
图一：利用Web界面的管理控制台把EJB部署到WebLogic。
总地看来，虽然我们无需修改原始的EJB代码，但必须把weblogic-ejb-jar.xml文件加入到META-INF目录。第二，我们发现，在准备部署EJB以及预先查找Bean存在的问题时，利用ejbc工具具有许多明显的优点。我们惊喜地发现，Netscape LDAP库已经捆绑到了weblogic.jar库，这使得我们的类路径更容易管理。最后，热部署WebLogic EJB可以说是轻而易举！我们只是把修改后的jar文件复制到应用的目录，对Bean的修改就立即生效。
在WebSphere上部署EJB时，我们了解到3.5版本不遵从EJB 2.0规范（根据报告，4.0版本遵从EJB 2.0规范）。WebSphere部署描述器是一个串行化对象，而不是一个XML文件。为便于创建串行化部署描述器，你必须使用IBM的Java图形用户界面（GUI）工具，即jetace，把EJB jar文件转换成串行化的格式。显然，如果EJB至少遵从EJB 1.1规范，jetace工具将解析Bean内的ejb-jar.xml部署描述器，获得有关部署操作的一些细节说明；否则，jetace工具直接从类文件获得必须的部署信息。如果不使用jetace部署工具，我们无法在WebSphere 3.5上部署EJB。
使用jetace工具时，jar文件从File菜单装入。顺便说明，当EJB的部署描述器带有DOCTYPE头时，jetace将拒绝装入EJB。装入jar文件之后，我们实际上是创建了一个新的串行化文件，通过一系列的对话设置合适的部署参数，然而保存它。只有完成这个过程之后，我们才可以利用WebSphere管理控制台安装EJB。在WebSphere上部署EJB时还有一个值得注意的问题，即在重新部署一个EJB之前，我们必须先从管理控制台关闭并删除EJB。如果在不关闭并删除以前安装的Bean的情形下就重新部署它，我们可能在无意之中损坏Bean，导致它不时地返回奇怪的结果。最后，由于在重新部署之前，我们必须从管理控制台关闭并删除EJB，所以WebSphere不支持热部署。
图二：在WebSphere上部署EJB时必须结合管理控制台运用jetace工具
总地看来，对于第一个EJB包，我们只需修改部署描述器（ejb-jar.xml），使它不包含DOCTYPE标记。另外，我们还要熟悉jetace工具以及有关它的特殊的部署步骤。
JBoss很容易安装和运行，而且它是免费的——它以Lesser GNU Public License（LGPL）的方式发行。在JBoss上部署EJB几乎就象安装和运行应用服务器本身一样简单。尽管如此，在JBoss上部署Bean时，我们仍旧发现了一些细微的差别。
首先，在ejb-jar.xml部署描述器的编写格式方面，我们遇到了一个问题。JBoss希望元素的开始标记和结束标记位于同一行上，而不是把它们分开到多个行。例如，下面的ejb-jar.xml部署描述器虽然顺利通过了WebLogic和WebSphere XML解析器的检查，但在JBoss上会出现部署错误：
纠正格式错误之后得到的ejb-jar.xml部署描述器如下所示：
另外，我们还必须增加一个名为jboss.xml的部署描述器，把它加入到META-INF目录。jboss描述器与WebLogic的weblogic-ejb-jar.xml部署描述器相似，它的作用是把EJB名称绑定到一个JNDI树上的名称。
部署JBoss EJB简单到只需把jar文件复制到部署目录，该目录就在JBoss安装的根目录之下。JBoss支持EJB热部署，有关Bean部署的信息直接在命令行上输出，从而方便了观察（在Unix上，它就在启动JBoss的那个shell窗口）。然而，在JBoss上部署EJB也有一个小小的不便之处，这就是我们不能浏览JNDI树验证Bean已经成功注册，不能在JNDI树中看到Bean的注册名字。如果我们未能在jboss.xml部署描述器中指定Bean的JNDI名称，默认情况下，JBoss将使用ejb-jar.xml中<ejb-name>标记提供的值注册它。如果加入了jboss.xml，我们可以利用<jndi-name>标记指定Bean在JBoss JNDI树上的注册名字。
总地看来，JBoss作为一个轻量级的应用服务器，它在注册EJB的时候只需要很简单的部署操作。我们只需把jar文件复制到部署目录，然后观察控制台上的输出结果。JBoss支持我们所谓的Bean热部署。如果我们在构造ejb-jar.xml文件时足够小心，按照要求正确格式化了ejb-jar.xml文件，原先的EJB可以不经过任何修改直接在JBoss服务器上部署。然而，JBoss也要用到附加的部署描述器，例如jboss.xml和jaws.xml，这使得部署复杂Bean的过程更令人感兴趣。
即使象LDAP EJB这样一个简单的例子，它也很快证明了，我们必须根据具体的部署环境考虑部署过程。第二个例子将进一步示范在不同的应用服务器上部署同一EJB组件时的一些不同之处。但首先，表一总结了本例我们在部署EJB时发现的问题。
三、ProfileTest: CMP实体Bean
下一个例子是一个简单的实体Bean，它允许客户程序访问一个Oracle 8i数据源，提取数据或者加入数据。我们让这个例子尽量地符合EJB 2.0规范。就象本文前面的LDAP会话Bean一样，我们要把这个实体Bean部署到WebLogic、WebSphere和JBoss这三种应用服务器上。
然而，在部署这类EJB之前，我们必须先在应用服务器上创建一个Oracle数据源和一个JDBC连接池，以便EJB组件使用。每一种产品都有不同的数据源和连接池创建方法，因此，在部署这个EJB之前，你可能要参考具体产品的说明文档。
对于WebLogic，除了前面已经介绍过的weblogic-ejb-jar.xml部署描述器之外，它还需要一个帮助WebLogic把Bean的域映射到Oracle表列的部署描述器。这个部署描述器称为weblogic-cmp-rdbms-jar.xml，而且它必须和ejb-jar.xml、weblogic-ejb-jar.xml一起保存在META-INF目录之下。你可以配置某些应用服务器，让它们根据部署描述器中定义的域映射关系自动创建数据库表。但遗憾的是，WebLogic不能帮你做到这一点。我们必须手工创建数据库表，或者编写自己的工具创建表。下面是一个简单的SQL命令脚本，它在Oracle中创建实体EJB需要的表。
总而言之，CMP实体Bean本身的部署不要求附加什么东西，但WebLogic要求我们增加一个额外的部署描述器weblogic-cmp-rdbms-jar.xml。
正如前文所指出的，WebSphere不遵从EJB 2.0规范。为此，我们必须修改原先的EJB代码（参见下载包中的源代码）。修改代码实际上就是让EJB遵从1.1规范。完成后，我们重新编译EJB，并用jar打包。然后，我们用jetace工具创建一个适合在WebSphere上部署的jar文件，用WebSphere管理控制台部署该Bean。WebSphere能够根据ejb-jar.xml部署描述器中定义的信息创建Oracle数据库表。例如，下面几行内容属于ejb-jar.xml文件，它们描述了EJB中需要由容器管理的域：
图三显示了WebSphere管理控制台，在这里我们指定是否要在部署CMP实体Bean的时候自动地创建表。
然而，在WebSphere下运用Oracle 8i时，在把Oracle作为数据源之前，我们首先必须进行一些准备工作，比如修改允许打开的游标数量，创建EJSADMIN和/或EJB Oracle帐户。当WebSphere在Oracle中创建表时，它使用的表名根据EJB的名字确定。例如本例中，WebSphere默认创建的表名字为PROFILEBEANTB。
遗憾的是，每次试图在客户程序中访问ProfileTest Bean时，我们总是得到一个“java.sql.SQLException: ORA-01002: fetch out of sequence”错误信息。由于IBM没有为试用版WebSphere提供客户EJB支持，所以我们无法借助IBM客户支持来解决这个问题。不过，我们成功地在Bean上调用了create()方法，向数据库表插入了记录。顺便说一句，当我们使用默认的数据源DB2（而不是Oracle）时，这个实体Bean运行得很流畅。
总而言之，WebSphere能够自动地为CMP实体Bean创建数据库表；然而，在把Oracle 8i作为WebSphere的数据源之前，我们必须先进行一些准备工作。幸运的是，WebSphere不需要任何额外的部署描述器文件，只需一个ejb-jar.xml文件。我们必须用jetace部署工具创建适合WebSphere的jar文件。
和WebSphere不一样，JBoss不要求预先对数据库服务器进行任何调整。按照JBoss文档的说明，JBoss利用一个对象-关系数据映射工具Jaws管理CMP实体Bean。只要创建一个名为jaws.xml的部署描述器，然后把它放入META-INF目录，我们就可以利用这个文件告诉Jaws创建和删除数据库中的表。另外，我们还可以指定从Bean到数据库表中列名字之间的映射。jaws.xml描述器类似于WebLogic的weblogic-cmp-rdbms-jar.xml部署描述器；然而，jaws.xml是可选的。如果我们没有用jaws.xml显式地指定需要创建的数据库模式和名字，Jaws将创建一个默认的表，这个表的名字是包的名字加上一个下划线，再加上Bean的名字。例如在本例中，Jaws创建的默认表名为PROFILETEST_PROFILEBEAN。
对于在JBoss上部署CMP实体Bean来说，jaws.xml是可选的，但jboss.xml是必需的。正如前面的例子所提到的，jboss.xml和WebLogic的weblogic-ejb-jar.xml部署描述器大略相似。
虽然JBoss在很大程度上遵从EJB 2.0规范，但对于CMP实体Bean来说，JBoss并不完全遵从EJB 2.0规范。作为结果，我们原先遵从2.0规范的代码不能在JBoss下运行。但是，我们部署到WebSphere上的代码却可以成功地部署到JBoss上（假定已经在META-INF下提供jboss.xml）。
（注意：利用MVCSoft公司提供的一个插件，你可以让JBoss遵从EJB 2.0规范草案。MVCSoft销售其持久化管理器的价格为$28.60。）
总而言之，部署到JBoss应用服务器的CMP实体Bean要求增加特别为JBoss提供的部署描述器，即jboss.xml。另外，我们还可以在META-INF目录中提供一个可选的jaws.xml，jaws利用jaws.xml实现Bean域到数据库表列的映射以及表的管理。JBoss 2.2.1还没有按照EJB 2.0规范草案要求的那样支持CMP实体关系。但是，我们可以利用MVCSoft公司的插件克服这个局限。最后，和WebSphere类似，JBoss提供了一个Jaws工具。Jaws能够按照jasw.xml部署描述器中<create-table>标记的说明，自动为CMP实体Bean创建数据库表。
表二总结了在三种应用服务器上部署CMP实体Bean时我们发现的问题。
■ 结束语
EJB规范提出了EJB部署员这样一个职务，其实这毫不奇怪。部署EJB的工作很容易成为一种专门的职务，特别是当EJB部署者每次都必须面对来自不同供应商的多个应用服务器时。遗憾的是，开发这类应用的人、应用的部署者、实际管理应用服务器的人之间界限有些模糊。为此，每一组人都必须了解一些有关EJB部署的知识，了解部署过程中可能遇到的问题。
在部署EJB的时候，部署者必须学习和了解面向特定应用服务器的部署描述器，了解应用本身的部署方式（即，从命令行，还是从管理控制台）以及代码应该安装到什么目录，了解可以用哪些应用服务器提供的工具为部署做准备或进行部署，等等。部署过程可能比较复杂，而且对于不同的应用服务器，部署方法也会有所不同。也许为统一EJB部署方式而制作规划称不上真正的艺术，但它富有挑战性，会消耗大量的时间和资源。我们希望，本文帮助你避免了重复地研究和学习，从而得以把更多的时间投入开发工作。
■ 参考资源
（仙人掌工作室 ）
width=360 height=300 noresize scrolling=No frameborder="0" marginheight=0 marginwidth=0 src="http://www.cnnet.com.cn/servlets/ad?Pool=tech_pip" align="right"> Sun用“Write once，run anywhere”这一口号来推崇Java的跨平台移植能力。然而，对于大多数Java开发者来说，这个口号与其说反映了真实的Java应用部署，还不如说它代表着一个美好的、在一定程度上可以说远大的目标。例如，如果要让Java Applet在Netscape和IE浏览器中运行得完全一样，你得好好试验几次。类似地，在不同的Java兼容平台上，要让Java应用以完全同样的方式运行，你得耐心地进行一番辛苦的、彻底的测试。
但请不要误解我们的意思。Java是一种优秀的技术，特别是用来作为服务器端解决方案时，这一点尤其突出。我们认为，Java 2平台企业版（J2EE）是首选的Web服务开发环境。然而，对于Enterprise JavaBean（EJB），在不同的平台上部署同一EJB组件时也会出现一些与平台有关的问题。虽然我们完全有可能编写出部署方法统一的EJB代码，这些代码和应用服务器必须遵从同一版本的EJB规范。在很多情况下，要正确地安装和部署EJB，EJB的部署者必须针对不同的应用服务器进行不同的处理。
用初学者的眼光来看，本文介绍的是：在不同的应用服务器上部署同一EJB组件时，其部署过程的一些细微差别。这些应用服务器包括BEA的WebLogic、IBM的WebSphere和源代码开放组织的JBoss应用服务器。
一、EJB部署过程
在不同的应用服务器之间，EJB组件部署过程的不同由多种原因造成。首先，在描述如何部署EJB组件方面，EJB规范只提供了最小限度的指导。因此，供应商从不同的方向解释J2EE/EJB规范的这一部分，在为自己的平台定义组件部署步骤时，作出了各自的判断。
第二，组件部署是一个应用服务器供应商可以为其产品增值和增加独特功能的领域，供应商们把该过程标准化的热情不高。另外，这种部署标准的缺乏为应用服务器和Java IDE供应商带来了机会，使得它们能够集成自己的工具集，以便有效地方便EJB开发和部署——只有当你选择的IDE支持你的目标应用服务器时，这个过程才能得以简化。因此，对于一个给定的EJB，它的部署步骤必须根据具体情况进行分析，而且通常对于每一个应用服务器来说，部署步骤往往有所不同。
为了阐明这个问题，我们试验了两种EJB实现，一个LDAP（Lightweight Directory Access Protocol，轻量级目录访问协议）无状态会话Bean和一个简单的容器管理的实体（container-managed persistence，CMP）Bean。在这篇文章中，我们将了解把同一EJB部署到WebLogic、WebSphere和JBoss应用服务器时的主要不同之处。必须说明的是，虽然我们承认，如果利用与特定应用服务器密切关联的部署工具（例如，对于WebSphere服务器，使用VisualAge for Java），EJB部署过程将更加流畅；但是，这里我们将尽可能地用手工方式进行处理（利用vi/Emacs和JDK的jar工具编写代码、编写部署描述器文件、创建jar文件）。
为方便起见，文章最后提供了一个可下载的ZIP文件，它包含了本文用到的两个EJB示例，即HelloWorldLdap和ProfileTest。
二、HelloWorldLdap: LDAP无状态会话Bean
我们的第一个例子是一个无状态会话Bean，它从一个LDAP目录提取信息。用户（在这里是客户）可以在命令行指定一个LDAP服务器、email地址和DN（Distinguished Name）名称，EJB将从指定的目录提取该DN的所有属性。
类的路径问题可能干扰EJB和客户程序的编译。举例来说，我们选择把Netscape LDAP目录加入到第一个例子。一般而言，编译EJB代码的时候应该在类路径中指定J2EE JDK附带的j2ee.jar库，或者与它相当的库（对于JBoss，使用jboss.jar；对于WebLogic，使用weblogic.jar）。然而，编译客户程序的时候，类路径中还必须包含供应商的客户库，因为客户程序必须用到一个与特定供应商以及编译后的EJB组件有关的初始环境。另外，WebSphere客户程序还要求被部署的EJB jar文件也在classpath中。
成功地编译EJB之后就可以开始准备部署EJB。为部署Bean，META-INF目录下必须包含至少一个部署描述器（Deployment Descriptor）。本例的部署描述器ejb-jar.xml就位于该例子的META-INF目录下，在部署之前，我们把它和EJB类文件一起用jar打包。我们的第一个例子HelloWorldLdap有两个目录，即HelloWorldLdap和META-INF，这两个目录都属于同一目录层次。怀着以统一的方式部署Bean的希望，我们让EJB jar包包含以下内容：
| HelloWorldLdap/ EjbLdapbean.class EjbLdap.class EjbLdapHome.class EjbLdapClient.class META-INF/ |
在Unix Shell下，我们用以下命令打包EJB：
| > jar cvf HelloWorldLdap.jar META-INF/ HelloWorldLdap/*.class |
接下来，我们把HelloWorldLdap.jar部署到前面提到的三个应用服务器上。以下内容介绍我们在部署过程中的发现。
| 2.1 BEA WebLogic 6.0 (Service Pack 2) |
WebLogic有一个EJB部署准备工具，称为ejbc（即java weblogic.ejbc）。它有两个输入参数：包含类和部署描述器的jar文件的名字（例如，HelloWorldLdap.jar），以及我们为ejbc编译后的jar文件指定的名字（即HelloWeblogic.jar）。当jar文件编译不出现错误时，ejbc工具确实很不错；但如果EJB的构造存在问题，ejbc会变得相当恼人。尽管如此，ejbc仍旧是一个优秀的检验工具，它能够帮助我们在EJB部署之前找出错误。如果用ejbc编译jar文件，我们可以确信EJB能够在Weblogic上部署成功。
我们还试验了不用ejbc部署同一jar文件。对于简单的EJB，有可能获得成功；但是，不使用ejbc时，“热部署” EJB（在不关闭或者重新启动应用服务器的情况下，或者在不先行删除原有Bean实例的情况下，更新一个EJB）不能进行，而且此时我们不能再用ejbc进行确保部署成功的检验。
对于WebLogic，部署EJB时既可以简单地把jar文件复制到WL_HOME/config/your_domain/applications目录，或者也可以通过Web风格的管理控制台进行。在通过服务器日志报告部署中出现的问题时，WebLogic做得很出色。要检验部署是否成功，最简单的方法是利用管理控制台查看JNDI（Java Naming and Directory Interface）树。对于WebLogic，JNDI名字在另一个名为weblogic-ejb-jar.xml的部署描述器文件中指定。事实上，为了让示例EJB能够在WebLogic上部署成功，META-INF目录下必须存在这个部署描述器文件。
图一：利用Web界面的管理控制台把EJB部署到WebLogic。
总地看来，虽然我们无需修改原始的EJB代码，但必须把weblogic-ejb-jar.xml文件加入到META-INF目录。第二，我们发现，在准备部署EJB以及预先查找Bean存在的问题时，利用ejbc工具具有许多明显的优点。我们惊喜地发现，Netscape LDAP库已经捆绑到了weblogic.jar库，这使得我们的类路径更容易管理。最后，热部署WebLogic EJB可以说是轻而易举！我们只是把修改后的jar文件复制到应用的目录，对Bean的修改就立即生效。
| 2.2 IBM WebSphere 3.5 |
在WebSphere上部署EJB时，我们了解到3.5版本不遵从EJB 2.0规范（根据报告，4.0版本遵从EJB 2.0规范）。WebSphere部署描述器是一个串行化对象，而不是一个XML文件。为便于创建串行化部署描述器，你必须使用IBM的Java图形用户界面（GUI）工具，即jetace，把EJB jar文件转换成串行化的格式。显然，如果EJB至少遵从EJB 1.1规范，jetace工具将解析Bean内的ejb-jar.xml部署描述器，获得有关部署操作的一些细节说明；否则，jetace工具直接从类文件获得必须的部署信息。如果不使用jetace部署工具，我们无法在WebSphere 3.5上部署EJB。
使用jetace工具时，jar文件从File菜单装入。顺便说明，当EJB的部署描述器带有DOCTYPE头时，jetace将拒绝装入EJB。装入jar文件之后，我们实际上是创建了一个新的串行化文件，通过一系列的对话设置合适的部署参数，然而保存它。只有完成这个过程之后，我们才可以利用WebSphere管理控制台安装EJB。在WebSphere上部署EJB时还有一个值得注意的问题，即在重新部署一个EJB之前，我们必须先从管理控制台关闭并删除EJB。如果在不关闭并删除以前安装的Bean的情形下就重新部署它，我们可能在无意之中损坏Bean，导致它不时地返回奇怪的结果。最后，由于在重新部署之前，我们必须从管理控制台关闭并删除EJB，所以WebSphere不支持热部署。
图二：在WebSphere上部署EJB时必须结合管理控制台运用jetace工具
总地看来，对于第一个EJB包，我们只需修改部署描述器（ejb-jar.xml），使它不包含DOCTYPE标记。另外，我们还要熟悉jetace工具以及有关它的特殊的部署步骤。
| 2.3 JBoss 2.2.1 |
JBoss很容易安装和运行，而且它是免费的——它以Lesser GNU Public License（LGPL）的方式发行。在JBoss上部署EJB几乎就象安装和运行应用服务器本身一样简单。尽管如此，在JBoss上部署Bean时，我们仍旧发现了一些细微的差别。
首先，在ejb-jar.xml部署描述器的编写格式方面，我们遇到了一个问题。JBoss希望元素的开始标记和结束标记位于同一行上，而不是把它们分开到多个行。例如，下面的ejb-jar.xml部署描述器虽然顺利通过了WebLogic和WebSphere XML解析器的检查，但在JBoss上会出现部署错误：
| 【初始的ejb-jar.xml文件】 <?xml version="1.0"?> <ejb-jar> <enterprise-beans> <session> <ejb-name> EjbLdap </ejb-name> <home> HelloWorldLdap.EjbLdapHome </home> <remote> HelloWorldLdap </remote> <ejb-class> HelloWorldLdap.EjbLdapbean </ejb-class> <session-type> Stateless </session-type> <transaction-type> Bean </transaction-type> </session> </enterprise-beans> </ejb-jar> |
纠正格式错误之后得到的ejb-jar.xml部署描述器如下所示：
| 【修改后的ejb-jar.xml】 <?xml version="1.0"?> <ejb-jar> <enterprise-beans> <session> <ejb-name> EjbLdap</ejb-name> <home> HelloWorldLdap.EjbLdapHome</home> <remote> HelloWorldLdap</remote> <ejb-class> HelloWorldLdap.EjbLdapbean</ejb-class> <session-type> Stateless</session-type> <transaction-type>Bean</transaction-type> </session> </enterprise-beans> </ejb-jar> |
另外，我们还必须增加一个名为jboss.xml的部署描述器，把它加入到META-INF目录。jboss描述器与WebLogic的weblogic-ejb-jar.xml部署描述器相似，它的作用是把EJB名称绑定到一个JNDI树上的名称。
部署JBoss EJB简单到只需把jar文件复制到部署目录，该目录就在JBoss安装的根目录之下。JBoss支持EJB热部署，有关Bean部署的信息直接在命令行上输出，从而方便了观察（在Unix上，它就在启动JBoss的那个shell窗口）。然而，在JBoss上部署EJB也有一个小小的不便之处，这就是我们不能浏览JNDI树验证Bean已经成功注册，不能在JNDI树中看到Bean的注册名字。如果我们未能在jboss.xml部署描述器中指定Bean的JNDI名称，默认情况下，JBoss将使用ejb-jar.xml中<ejb-name>标记提供的值注册它。如果加入了jboss.xml，我们可以利用<jndi-name>标记指定Bean在JBoss JNDI树上的注册名字。
总地看来，JBoss作为一个轻量级的应用服务器，它在注册EJB的时候只需要很简单的部署操作。我们只需把jar文件复制到部署目录，然后观察控制台上的输出结果。JBoss支持我们所谓的Bean热部署。如果我们在构造ejb-jar.xml文件时足够小心，按照要求正确格式化了ejb-jar.xml文件，原先的EJB可以不经过任何修改直接在JBoss服务器上部署。然而，JBoss也要用到附加的部署描述器，例如jboss.xml和jaws.xml，这使得部署复杂Bean的过程更令人感兴趣。
| 2.4 LDAP EJB示例之小结 |
即使象LDAP EJB这样一个简单的例子，它也很快证明了，我们必须根据具体的部署环境考虑部署过程。第二个例子将进一步示范在不同的应用服务器上部署同一EJB组件时的一些不同之处。但首先，表一总结了本例我们在部署EJB时发现的问题。
| 表一：LDAP EJB示例中出现的部署问题 | ||||
| 热部署支持 | 供应商特有的部署工具 | 额外的、供应商特有的部署描述器 | 遵从EJB 2.0规范 | |
| BEA WebLogic 6.0 SP2 | 是 | ejbc | weblogic-ejbc-jar.xml | 是 |
| IBM WebSphere 3.5 | 否 | jetace | 否 | 否 |
| JBoss 2.2.1 | 是 | 否 | jboss.xml | 是 |
三、ProfileTest: CMP实体Bean
下一个例子是一个简单的实体Bean，它允许客户程序访问一个Oracle 8i数据源，提取数据或者加入数据。我们让这个例子尽量地符合EJB 2.0规范。就象本文前面的LDAP会话Bean一样，我们要把这个实体Bean部署到WebLogic、WebSphere和JBoss这三种应用服务器上。
然而，在部署这类EJB之前，我们必须先在应用服务器上创建一个Oracle数据源和一个JDBC连接池，以便EJB组件使用。每一种产品都有不同的数据源和连接池创建方法，因此，在部署这个EJB之前，你可能要参考具体产品的说明文档。
| 3.1 BEA WebLogic 6.0 (Service Pack 2) |
对于WebLogic，除了前面已经介绍过的weblogic-ejb-jar.xml部署描述器之外，它还需要一个帮助WebLogic把Bean的域映射到Oracle表列的部署描述器。这个部署描述器称为weblogic-cmp-rdbms-jar.xml，而且它必须和ejb-jar.xml、weblogic-ejb-jar.xml一起保存在META-INF目录之下。你可以配置某些应用服务器，让它们根据部署描述器中定义的域映射关系自动创建数据库表。但遗憾的是，WebLogic不能帮你做到这一点。我们必须手工创建数据库表，或者编写自己的工具创建表。下面是一个简单的SQL命令脚本，它在Oracle中创建实体EJB需要的表。
| Create table ProfileTest_ProfileBean ( ID NUMBER(10) NOT NULL, PROFILEID VARCHAR2(255) NOT NULL, FNAME VARCHAR2(255), LNAME VARCHAR2(255) ); |
总而言之，CMP实体Bean本身的部署不要求附加什么东西，但WebLogic要求我们增加一个额外的部署描述器weblogic-cmp-rdbms-jar.xml。
| 3.2 IBM WebSphere 3.5 |
正如前文所指出的，WebSphere不遵从EJB 2.0规范。为此，我们必须修改原先的EJB代码（参见下载包中的源代码）。修改代码实际上就是让EJB遵从1.1规范。完成后，我们重新编译EJB，并用jar打包。然后，我们用jetace工具创建一个适合在WebSphere上部署的jar文件，用WebSphere管理控制台部署该Bean。WebSphere能够根据ejb-jar.xml部署描述器中定义的信息创建Oracle数据库表。例如，下面几行内容属于ejb-jar.xml文件，它们描述了EJB中需要由容器管理的域：
| ... <cmp-field><field-name>id</field-name></cmp-field> <cmp-field><field-name>fname</field-name></cmp-field> <cmp-field><field-name>lname</field-name></cmp-field> <cmp-field><field-name>profile</field-name></cmp-field> ... |
图三显示了WebSphere管理控制台，在这里我们指定是否要在部署CMP实体Bean的时候自动地创建表。
然而，在WebSphere下运用Oracle 8i时，在把Oracle作为数据源之前，我们首先必须进行一些准备工作，比如修改允许打开的游标数量，创建EJSADMIN和/或EJB Oracle帐户。当WebSphere在Oracle中创建表时，它使用的表名根据EJB的名字确定。例如本例中，WebSphere默认创建的表名字为PROFILEBEANTB。
遗憾的是，每次试图在客户程序中访问ProfileTest Bean时，我们总是得到一个“java.sql.SQLException: ORA-01002: fetch out of sequence”错误信息。由于IBM没有为试用版WebSphere提供客户EJB支持，所以我们无法借助IBM客户支持来解决这个问题。不过，我们成功地在Bean上调用了create()方法，向数据库表插入了记录。顺便说一句，当我们使用默认的数据源DB2（而不是Oracle）时，这个实体Bean运行得很流畅。
总而言之，WebSphere能够自动地为CMP实体Bean创建数据库表；然而，在把Oracle 8i作为WebSphere的数据源之前，我们必须先进行一些准备工作。幸运的是，WebSphere不需要任何额外的部署描述器文件，只需一个ejb-jar.xml文件。我们必须用jetace部署工具创建适合WebSphere的jar文件。
| 3.3 JBoss 2.2.1 |
和WebSphere不一样，JBoss不要求预先对数据库服务器进行任何调整。按照JBoss文档的说明，JBoss利用一个对象-关系数据映射工具Jaws管理CMP实体Bean。只要创建一个名为jaws.xml的部署描述器，然后把它放入META-INF目录，我们就可以利用这个文件告诉Jaws创建和删除数据库中的表。另外，我们还可以指定从Bean到数据库表中列名字之间的映射。jaws.xml描述器类似于WebLogic的weblogic-cmp-rdbms-jar.xml部署描述器；然而，jaws.xml是可选的。如果我们没有用jaws.xml显式地指定需要创建的数据库模式和名字，Jaws将创建一个默认的表，这个表的名字是包的名字加上一个下划线，再加上Bean的名字。例如在本例中，Jaws创建的默认表名为PROFILETEST_PROFILEBEAN。
对于在JBoss上部署CMP实体Bean来说，jaws.xml是可选的，但jboss.xml是必需的。正如前面的例子所提到的，jboss.xml和WebLogic的weblogic-ejb-jar.xml部署描述器大略相似。
虽然JBoss在很大程度上遵从EJB 2.0规范，但对于CMP实体Bean来说，JBoss并不完全遵从EJB 2.0规范。作为结果，我们原先遵从2.0规范的代码不能在JBoss下运行。但是，我们部署到WebSphere上的代码却可以成功地部署到JBoss上（假定已经在META-INF下提供jboss.xml）。
（注意：利用MVCSoft公司提供的一个插件，你可以让JBoss遵从EJB 2.0规范草案。MVCSoft销售其持久化管理器的价格为$28.60。）
总而言之，部署到JBoss应用服务器的CMP实体Bean要求增加特别为JBoss提供的部署描述器，即jboss.xml。另外，我们还可以在META-INF目录中提供一个可选的jaws.xml，jaws利用jaws.xml实现Bean域到数据库表列的映射以及表的管理。JBoss 2.2.1还没有按照EJB 2.0规范草案要求的那样支持CMP实体关系。但是，我们可以利用MVCSoft公司的插件克服这个局限。最后，和WebSphere类似，JBoss提供了一个Jaws工具。Jaws能够按照jasw.xml部署描述器中<create-table>标记的说明，自动为CMP实体Bean创建数据库表。
| 3.4 CMP实体Bean示例之小结 |
表二总结了在三种应用服务器上部署CMP实体Bean时我们发现的问题。
| 表二：CMP实体Bean示例中的部署问题 | ||||
| 自动创建表 | CMP部署描述器 | 遵从EJB 2.0规范 | ||
| BEA WebLogic 6.0 SP2 | 否 | weblogic-cmp-rdbms-jar.xml | 是 | |
| IBM WebSphere 3.5 | 是 | 否 | 否 | |
| JBoss 2.2.1 | 是 | jaws.xml | 否 | |
■ 结束语
EJB规范提出了EJB部署员这样一个职务，其实这毫不奇怪。部署EJB的工作很容易成为一种专门的职务，特别是当EJB部署者每次都必须面对来自不同供应商的多个应用服务器时。遗憾的是，开发这类应用的人、应用的部署者、实际管理应用服务器的人之间界限有些模糊。为此，每一组人都必须了解一些有关EJB部署的知识，了解部署过程中可能遇到的问题。
在部署EJB的时候，部署者必须学习和了解面向特定应用服务器的部署描述器，了解应用本身的部署方式（即，从命令行，还是从管理控制台）以及代码应该安装到什么目录，了解可以用哪些应用服务器提供的工具为部署做准备或进行部署，等等。部署过程可能比较复杂，而且对于不同的应用服务器，部署方法也会有所不同。也许为统一EJB部署方式而制作规划称不上真正的艺术，但它富有挑战性，会消耗大量的时间和资源。我们希望，本文帮助你避免了重复地研究和学习，从而得以把更多的时间投入开发工作。
■ 参考资源
1016
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
