CSDN博客

img zlsunnan

我的J2EE误区 (转)

发表于2004/9/13 17:09:00  1257人阅读

最近参加了一个J2EE的培训,培训本身并没有多少新鲜东西,不过,在培训的过程,我发现了自己原来对于J2EE中不少概念的认识并不那么正确或是正统。

首当其冲的就是JNDI。我之前一直认为JNDI就是为了编写EJB、数据源、JMS等客户端调用代码而附加的讨厌东西。实际上,我们完全可以把JDNI看作一个大规模的Service Locator,我们可以把自己感兴趣的一些东西配置成JNDI的一部分,利用统一的方式进行访问。
正是有了JNDI的透明访问,我们才能写出可移植的分布式代码。
在《恶斗EJB》中,我费了九牛二虎之力,实际上都是与JNDI相关参数打斗。应该说,可以正常运行的代码证明了我的努力没有白费,但实际上,我的做法有些画蛇添足。
通过设置各种参数,我实际上访问的是远程的JNDI,然后得到EJB,这么做固然可以运行,但由于设置参数的原因,我们的代码肯定是无法在应用服务器间移植的。
    +--------------+  +--------------+
    |           ---|->|     JNDI     |
    |   Client     |  |--------------|
    |           ---|->|     EJB      |
    +--------------+  +--------------+

正统的做法是我不必在自己的代码中设置参数,而只是访问本地的JNDI,由本地的JNDI和远程的JNDI之间进行映射。这样我的代码就成为了可移植的代码,至于本地JNDI和远程JNDI怎么映射,那就是具体应用服务器的问题了。
    +--------------+  +--------------+
    |    JNDI   ---|->|     JNDI     |
    |--------------|  |--------------|
    |    Client ---|->|     EJB      |
    +--------------+  +--------------+

另外一个我一直没有搞清楚的就是在应用中,JNDI名字通常还对应一个引用名字。我总是认为有了JNDI名字就够了,要这个引用名字是多余的。
如果说JNDI名字相当于全局变量的话,那么引用名字就相当于一个局部变量。这样做的好处何在呢?还是可移植性的问题。
当我们把应用部署到一台新的应用服务器上时,由于JNDI名字的全局性,这个JNDI的名字可能已经被别人抢先占住,我们只有曲线救国,把自己应用用到的JNDI名字改一下。如果在代码中,直接使用JNDI名字的话,改变JNDI名字势必要修改代码。如果我们使用引用名字,在同一个引用中保证引用名字的唯一性,我们还是能够做到的,这样我们只要修改引用名字和JNDI名字的映射,一切就迎刃而解了。

还有一个认识上的大错误是关于应用客户端的JAR文件。在《恶斗EJB》中,我曾质疑导出这个JAR文件还要我部署到服务器上。实际上,这么做是必须的。
不同于常见的Web应用直接把WAR文件扔到应用服务器相关目录下就算完成部署,如果直接把含有EJB的EAR文件扔到应用服务器对应的目录下,通常是无法运行的。我们都知道,编写会话Bean和实体Bean时,我们会写两个接口(这里就不区分是是本地)和一个类,显然有接口就要有实现,只不过这两个接口的实现不是我们完成,而是由应用服务器完成,这就牵扯到讨论EJB常说的Stub和Skeleton。我们不能指望不同的应用服务器生成相同的Stub和Skeleton,而Stub和Skeleton的生成工作通常会在部署的时候完成,所以,只有部署之后,才会有一个有意义的Stub和Skeleton,这时产生的客户端的JAR文件才是有意义的。

总而言之,J2EE太复杂,不仅仅是J2EE规范本身就很庞大,编写代码就很费劲,而且部署也是一个很有学问的工作,难怪J2EE中还有专门负责部署的人。《Unix程序设计艺术》的第二章回顾Unix历史时说,第一个系统一般都做得不怎么样,第二个系统为了改进第一个系统的问题就会拼命的完善,最后导致被自身重量压得坍塌了,只有到第三个系统,整个设计才会回归简单。由此推算,以EJB 3.0为主的新版J2EE还是值得期待的。

0 0

相关博文

我的热门文章

img
取 消
img