J2EE五年: 从起源到目的

起点
在“J2EE”这个缩略语被第一次介绍给世人的时刻，也许没有几个人可以预料出它在日后的奇特历程。那是在1999年6月的JavaOne年会上，时任Sun公司Java企业开发部门主管的Mala Chandra兴奋地预告了Java世界的这位新成员。那些不熟悉背景的听众们，揣摩着她演说中出现的一串串全新术语，表情大概又是惊喜、又是迷惑:一个完整的“多层企业开发架构”、以“容器”和“组件”的形式提供服务、一套“厂商中立的开放技术规范”、对开发者隐藏了不同平台和“中间件”的技术细节、实现了企业级应用间的“无缝集成”等等。在今天的开发者看来，这些似乎都已经是老生常谈，但在当时的场景下，闪动在幻灯片上的每一个口号，都意味着听众们事后又要经历一段困难的学习过程。

幸亏Chandra有一副了不起的口才;这位本科念建筑学的印度裔高层主管，谈起软件架构来也有特强的空间想象力。她清晰地说明了设计J2EE架构的两个初衷：首先，对于厂商，J2EE意味着一套开放标准，加入这个标准，他们的产品就可以运行在各种不同的操作系统和工作环境下，成为一个成熟的企业运算体系中可替换的部件;其次，对于开发者，J2EE是一套现成的解决方案，采用这个方案，企业应用开发中的很多技术难题（包括跨平台移植、事务处理、安全性等等）就会迎刃而解，“信息像一条不间断的河流，经过各种各样的平台和设备，从企业应用系统的这一端流向那一端”。

要想理解这段话在当时的实际效应，我们仍然要把时间指针拨回1999年。除了预备迎接千年虫之外，99年你做了什么？为了回答这个犀利的问题，我翻出6年前的工作记录，发现了自己那时参与的一个项目的规格说明书，它正好能提供一幅“Java企业开发”在1999年的标准照。这是一家日本知名IT厂商的企业信息管理系统，运行在NetScape 3.0 Gold浏览器中的Java Applet界面，通过一个专用的中间层系统与Oracle 8数据库连接。这个中间层已经相当现成、完善，能够提供远程对象调用、事务处理等一系列的底层服务;留给我们的任务只是完成服务器端业务对象代码，以及相应的客户端交互开发。

除了Applet客户端有些特别之外，上述系统与今天常见的J2EE架构很接近;尤其是业务对象编码也由home类、PK（主键）类、entity类等部分构成，很多机制都与EJB如出一辙——只不过这些类并没有继承javax.ejb包的接口，而是采用了专用的API。它与EJB之间的相似不像是偶然的，设计者肯定参照了Sun在1997年底推出的EJB 1.0技术规范。

换言之，在J2EE诞生伊始的语境中，市面上已经存在着很多程度不一的“准J2EE中间件”了。它们主要用于解决三大类问题：事务处理、分布式对象管理和Web请求处理。首先，事务处理管理器（Transaction Processing Monitor）一直是高端企业计算领域的热门产品，著名的应用服务器厂商BEA，正是通过收购事务处理软件Tuxedo进入中间件市场的。另一方面，从90年代初开始，越来越多的人把“N层分布式对象架构” 当成传统的客户端/服务器架构的替代方案。那时刚刚兴起的CORBA技术是推动这一趋势的重要力量（比如说，前面提到的那个由日本厂商自行开发的专用中间层，就采用了CORBA作为基础架构）。最后，Java技术在Web领域中的应用也是当时初露头角的热点。1997年6月，Sun在发布一款“Java Web Server”的同时第一次公布了Servlet API;没想到这项技术副产品（连同1998年问世的JSP）正好迎合了厂商的战略需要。对于上面提到的N层架构来说，HTTP服务是一个非常理想的前端;所以基于Java的Web引擎，也在此时成了企业级Java解决方案的一个必不可少的部分。

Java、Web、事务、分布式对象，这几股