无论叫它什么,高端产品的开源化/免费化运动注定要在j2ee产业的发展过程中制造显著的后果“jboss的行径恶化了j2ee的商业环境,”这是mcnealy先生2002年的著名论断他的推理过程如下:只有做好商业推广,j2ee产品才能最终击溃邪恶的.net平台;但开源服务器会降低主流厂商的销售利润;销售利润越低,用于商业推广的预算就越少;因此,整个j2ee阵营都将受损于jboss
在j2ee五年之后,人们只能交替地用这两种目光审视它的演化历程它的起Java程序源与它的目的、“它从何处来”与“它往何处去” 的问题紧密地交织在一起,谁拾起了其中的一个,谁也就要连同另一个一起回答
从“轻量级容器架构”这个词被发明出来的那一刻起,人们对j2ee远景的考虑就发生了根本性的分裂:sun和大部分主流厂商更多地关注于“web services”和“快速开发工具”这些利润增长点,而一部分离经叛道的独立专家和开发者则认为,如果不把轻量级容器纳入规划,j2ee的发展蓝图就注定无足称道
而对于异质系统之间的调用,则应该尽量选用异步的、粗粒度的服务接口(所以web services成为了非常理想的选择)换句话说,传统上的“分布式对象架构”,现在看来似乎只适合于银行远程支付等要求极为苛刻Java程序员的应用场景,而绝不是所有j2ee应用都该考虑的标准方案
这些议案的审议过程很少是一帆风顺的,几乎每一个都要经历18个月以上的拉锯战在多项技术规范的审议过程中,我们都见到了这样的现象:最初列名审议委员会的某家主要厂商,没能等到该规范通过就已经被收购或倒闭了
换言之,在5年的演化中,j2ee发生的最大变化可能就在于它放弃了对“分布式对象模型”的强调ejb2.0引入的本地接口使得web层与ejb层可以运行在同一个java虚拟机中,从而使web容器与ejb容器的物理分离部署变成一种昂贵的冗余;j2ee 1.4以后版本支持的web services兼容性,使得客户端可以通过粗粒度的web接口调用远程服务——这两次变化事实上都是java培训学校在论证“分布式对象架构”的无用性
查看本文来源
但在狂热的开源运动支持者看来,以上论证的大前提就是可疑的“难道只有会做广告的软件才是好软件?mysql有过多少广告预算”争论的双方都认为对手误解了软件商业模型的实质究竟谁才掌握了这里的真理呢?也许只有根据j2ee的未来——也就是它的目标和终点(telos)——才能做出最终的裁决
j2ee社区中的另一股重要力量,当然是种类极为丰富的开放源代码项目2002年以来,在j2ee领域的各个层面上,几乎所有主流产品都有来自开源项目的替代方案,在其中很多位置上,开源产品反而是胜过商业产品的首选
考察事物的演化,通常有两种对立的方法考古学家(archaeologist)探究肇始和起源;目的Java学习论者(teleologist)则揭示目的和终点对于前者,“开端(希腊语arche)”从根本上决定了此后的发展,参天大树的繁茂都包含在种子最初的萌芽中;而对于后者,“目的(telos)”才是事物的根本和旨归:谁没见过样态完善的树,谁也就没法弄懂种子到底是怎么回事
而如果失去了应用服务器的这个产品类型,那些靠这项销售起家的厂商又将何以自处?正是在这里,两个阵营之间存在着最深刻的利益分歧;而这场争执的结局当然也将决定j2ee(乃至java企业开发)的最终走向
其实,双方争执的关键是传统意义上的“应用服务器”的存亡——如果所有企业级服务都可以通过aop机制提供给普通java对象,如果管理业务对象生命周期的可以是一个最微不足java编程思想道的“微内核”,那么深盔重铠的应用服务器还有什么存在理由?
技术的离心力
按照这一运动信徒们的说法,j2ee的发展史上只出现过一个错误——不幸的是,这个错误名叫ejb与ejb提供的重量级架构不同,借助aop和ioc机制,轻量级容器能够最大程度地降低代码对于专用接口的依赖性,以简短、轻便、专注、可移植的方式实现业务对象
但正如上文所说,即使是在1999年,j2ee设计者们面对的也不是一张从未着墨的白纸
今天的j2ee在多大程度上符合它的初衷?回答这个问题并不涉及对j2ee技术成败的评判,而只是要考察一下:它是否还运行在最初开辟的那个空间之中在事务处理、对象分布化和web请求处理这三个方面中,也许j2ee对事务和web保持Java学习资料了一贯的忠诚
另一方面,不少开发者也间接地通过自己的开源产品获得了可观的盈利这些人大多以免费的开源产品为依托,以收费方式提供附加的咨询、方案实施以及技术支持服务marc fleury,开源应用服务器的jboss创始人,不无矛盾地把自己倡导的这种商业模式称为“职业开源开发”
前面描述的离心现象毕竟还遵循了j2ee发展的内在逻辑,说到底,ejb的革新和web services的引入更多地是主流厂商倡导的结果但在近年来,还有一股更强劲的离心潮流在深刻地影响着j2ee的演进,它肇始于上文提到的开源软件运动
最初它只在rickard oberg的动态代理rmi设计与jboss服务器的微内核架构中显露过邪恶的一角,java学习资料但是两三年来,经过多个项目、各种技术杂志/论坛/blog的折射和放大,它已经形成了一个名为“轻量级容器架构”的完整解决方案,并暴露出完全取代传统ejb架构的终极野心
我们记得fleury喜欢重复的一个信条:“he who owns the transactional web owns the web(谁掌握了带事务处理的web,谁就掌握了web)”web接口是今天大部分j2ee应用暴露的唯一接口;而虽然事务处理的常用方法已经有了很大改变(借助aop机制,很多非ejb架构的系统也自如地实现了声明式的事务处理),但对事务的重视当然仍将是j2ee开发中的要素之一
多年以后,hapner回忆起j2ee初创的那个时期,深Java程序员感如今sun对java的左右能力已经大不如前:“现在,java事实上属于整个技术社区,它的发展有赖全体参与者的推动”的确,如今sun已经不太可能重演当年的开拓性功绩,很难再为一个已经成形的领域重绘版图
但请别误解,这里的“开源”并不意味着完全的自动自发,j2ee世界中的开源项目也与linux或php世界颇为不同在很多非常成功的j2ee开源项目背后,我们都能发现商业机构的推动作用:apache的jakarta社区是ibm扶植的结果;实现了开源应用服务器jonas的objectweb,则是许多法国it厂商(包括若干政府部门)合资支持的一个联盟组织……这些有商业背景的开源项目资金雄厚,人员齐整;更重要的是,从java培训学校投资者到开发者,参与这些项目的很多人都体现了软件工业中难得的非功利心态,因而最终推出的产品质量甚至高于同类型的商业软件在主流厂商之外,它们是支撑j2ee大厦存在的一组基石
与微软在.net平台上的乾刚独断相比,j2ee发展中的这个“牛步”特征虽说是审慎和民主的表现,但终归不符合软件演化应有的速度
或许两年之后,我们将从纷争中胜利者一方的角度重述j2ee的整部历史——或许两年之后的j2ee本身也将随着纷争的解决而成为历史但让我们换个乐观的口吻:问世五年,j2ee的历史仍在持续的创生之中;此时善待这树种的人,也必在今后的树荫下获得它的祝福
人们发现,同一系统的各个分层最好采用细粒度接口调用,并且运行在同一个进程中java培训学校;之所以划分不同的层次,与其说是为了实现物理上的可扩展性,不如说是设计美学上的考虑
很容易注意到,j2ee与java社区的决策机制jcp(java community process)是几乎同步产生的j2ee下属的各种技术规范,包括1.4版之后的j2ee本身,都作为待决规范议案(jsr,java specification request)被纳入了jcp的议程