从J2EE谈到EJB技术的缺陷

万恶的软件构建于中间件课,猥琐的老师,完成论文如下

Declare:非抄袭,非原创

从J2EE谈到EJB技术的缺陷
       Java是一种语言,或者更准确的说是一种平台。很多人只把Java当成一种语言,其实这是非常片面的理解。在以前,我对Java的理解,也仅限于此,认为Java是一种简单的语言,速度很慢的语言,甚至认为这是没多大用处的语言。然而,现在我理解的Java是一个平台,看看J2SE、J2EE、J2ME这些的名字,Sun已经非常肯定的把Java定位为Platform了。记得C++之父Bjarne Stroustrup说过一句话:Java is not platform-independent, it is the platform。如果说以前Java宣称的是一种跨平台的语言,那么现在Java已经发展成了平台,而且不是一种平台。

      自从上学期学习Java以来,先后接触了J2SE和Jsp、Servelet、Struts等技术,还有MVC这样的设计模式,对EJB一直只有耳闻,并不十分了解。随着业界对J2EE平台的不断投入,大量优秀的设计思想都在EJB平台上得到了应用,正好学院开设了Software Middware这门课,使我得以有机会对EJB进行进一步的学习。一项新技术的采用,绝不是因为它很时髦就采用的,应用一项新技术以前,你一定要先了解它的基本原理,它能够达到的功能和性能,有什么优点和缺点。

       J2EE是一个相当庞大的技术体系,也是一个相当庞大的平台。J2EE建立在一系列的Java平台技术之上。计算机技术的发展从来就是为了简单,为了生活更简单,为了工作更简单,为了编程更简单。EJB的出现使得组件程序的开发更完善了,开发人员分为很多角色,每种角色负责相应的工作,分工更细,每个领域的人的熟练程度都得到了提高,各个领域更容易产生“专家”。举个例子,应用服务器厂商开发应用服务器,另一家公司在该应用服务器上开发bean,然后这家厂商把bean卖给一家开发应用程序的公司,这就公司用bean开发程序,然后卖给另一家负责发表J2EE程序的公司,这家公司在目标机器上部署应用程序,最后的维护工作却是另一家公司。这个过程就正如我们现实生活中的工业生产,不同部门生产出的部分最后被组合在一起。这就是我体会的EJB,也许现实的应用并不是这样,很多时候一家公司就把这些角色做完,但是它体现出来的思想却和现代工业是一致的。按照J2EE的想法,一个应用都是一个大型的应用类似于生产一架波音飞机,如此大型的工程,只由一家公司来完成,显然是不可能的。因此需要一些技术让更多的公司来参与开发。如果市场上有现成的EJB卖,直接买来岂不更好。如果自己开发,未必经济,程序也不一定成功,当然如果自己以前开发的组件能够复用就更好了。

       J2EE是一个非常好的企业应用设计规范,它采用了大量优秀的设计思想。J2EE设计的目标,就是让企业应用开发人员能够在一个规范的平台之上,不用考虑具体的技术问题,专注于业务逻辑实现,就可以开发出在性能性、稳定性、可管理性等各个方面都达到较高水平的系统。作为J2EE的核心,EJB具有可重用性、可移植性、简化开发、软件质量高等优点,EJB的众多特点使得它已经成为了在多万环境中开发和部署分布式组建应用程序的事实标准。然而,令人难以满意的是,经过一学期的学习,我体会到了EJB存在如下一些缺陷。

       首先,EJB技术的一项最根本的技术缺陷来自于对象序列化技术。对象序列化技术是EJB跨平台通讯的基础,所有的EJB之间通讯都依赖了对象序列化技术的应用。从设计架构上看,这是个简单清晰的设计,通过对象的序列化实现了对象在多个进程之间的复制传递。但非常遗憾的是,设计者对于Java平台对于对象序列化的实现的考虑却做的很草率,对象序列化的性能很差。当然,这个问题也不是不可避免的,只要重载对象的序列化方法,实现自己的序列化方式就可以达到高性能的序列化。但是可以想象一下,为每个对象写序列化函数,这是个多大的工作量,为什么SUN的JDK本身至今也没有实现高性能的序列化?仅仅考虑设计架构上的简单性,而把大量的性能优化工作推给业务开发人员,是不负责任的做法。

       另一项EJB技术更为严重的缺陷来自于RMI(远程方法调用)。EJB限定必须遵守CORBA规范的RMI-IIOP技术,实际上所有采用分布式对象调用的技术,包括CORBA、COM+、RMI等,这种技术的根本原理上都是一样的,通过本地的一个远程对象代理,通过网络上的多次通讯实现对远程对象的方法调用,这种设计架构的初衷是隐藏对象的具体位置,可以让对象使用者不用关心对象的实际位置。但是这种方法的实现性能极差,像CORBA这种系统的设计者当初就没有把性能问题作为一个重要问题去考虑,正是性能问题,导致隐藏对象位置这个目的实际上也并没有达到,因为通过通讯访问远程对象的性能太差,因此使用者处于系统性能的考虑不得不考虑远程对象和本地对象的区别。更可悲的是,EJB的上层设计上也没有能够把远程对象和本地对象的差别消除,从EJB设计人员自己的说法,远程对象调用和本地对象调用在语义上就无法统一起来。既然上层就必须区分远程对象和本地对象,那底层技术上就完全没有必要采用这种性能很差的设计了。从CORBA开始,这种分布式对象访问的技术就是不成熟的,EJB墨守了分布式对象技术的陈规,导致自己背上了沉重的包袱,使用者必须很小心地使用EJB技术,稍有不慎就会导致系统性能大幅度下降。我们从大量的J2EE设计模式中看到,很多设计模式都是为了补救EJB的性能缺陷而设计的,与其在一个有根本缺陷的平台上施展你的才能弥补、避开系统的种种缺陷,不如放弃这种平台,消除问题的根源所在,把你的精力放在能为客户创造价值的地方去。

       我认为,在分布式系统中,对象与对象之间的通讯应该采用轻量级的消息传递,我们不能为了实现面向对象的设计就一定要在每个地方强制使用面向对象调用的方式,面向对象技术本身也是需要不断改进的,我们在自主开发的中间件平台中,采用轻量消息传递的方式实现多个服务对象之间的数据交换,同样实现了服务对象具体位置的隐藏,而且实现了很高的性能。

       与前面提到的两个根本缺陷相比,EJB技术的其他方面的问题就显得微不足道了,比如EJB本身定义的复杂性,实体Bean的性能问题等等,这些问题一定可以解决,或者很容易被新的设计替换掉,比如复杂性问题可以通过工具解决,实体Bean可以用轻量级的对象持久化层代替等等。

       我想说的是,EJB的设计方面是非常优秀的,有许多设计思想值得我们借鉴采纳,但由于它本身还是存在着一些难以令人满意的地方。对于J2EE,相对简单的项目还好,但如果项目不断增长以至于变得越来越复杂就会不断出现越来越多的问题。通常情况下程序员们都是在清除一系列的警告信息。EJB也许想把复杂的问题简单化,但是它并没有更贴近于现实中的持久化问题或业务逻辑的解决方案。这一切都使得J2EE离便于开发、提供多路访问稳定性、本地化模式的部署操作、具备可靠的性能和可测试性和开放的标准的所谓的完美平台还有不小的距离。

One thought on “从J2EE谈到EJB技术的缺陷

发表评论

电子邮件地址不会被公开。 必填项已用*标注