起点
　　
　　在“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、事务、分布式对象，这几股开发潮流汇合在一处，形成了当时最热门的产品“应用服务器（application server）”或“中间件（middleware）”。
　　
　　为了给定语“最热门”作个注释，我们可以参照一下bea公司在1998年收购web应用服务器厂商weblogic的成交价：1.92亿美元。而这并不是一桩孤立的收购，netscape和sun也以相近的价格买下了另外两家企业kiva和netdynamics。
　　
　　而这也正是j2ee规范出台的背景：几乎所有要厂商都推出了、或是正在赶制自己的应用服务器产品，但这个“应用服务器”究竟应该是什么东西，竞争者们又各有表述、莫衷一是。
　　
　　说到这里，我们才梳理出了j2ee技术规范的第一个版本在1999年12月问世的实际意义。首先，它为java企业开发提供了一幅清晰的全景，各项分支技术在这个领域中的地位和作用得到了客观、准确的定义。
　　
　　至此大家才对一个java企业解决方案的构成要素有了基本共识。其次，它使用“容器”和“组件”等概念描绘了java企业系统的一般架构，明确地划分了中间件厂商和应用开发者的职责所在。
　　
　　最后（但绝非最不重要地），j2ee通过一套公开标准规定了应用服务器产品的具体行为，在执行此标准的厂商产品之间实现了一定程度的可替换性和互操作性。
　　
　　当时的媒体用“b2b开发的默认标准”之类的说法欢呼这项里程碑式的成就――那些撰稿人哪里知道，在j2ee与那个被称为“b2b” 的短命新贵之间，其实并不会有太多故事发生；同样，他们也不会想到，j2ee要想成为一种真正成熟的开发范式，前方还有一段远为艰辛的旅程。
　　
　　社区的形成
　　
　　记得kruglinski在名著《inside visual c++》的某个版本中给出了一个web浏览器的代码例子；在这一节的开头他说到：如果你几年前开发了一个web浏览器，那肯定会给你带来上千万的收益；但如果你现在才想到开发这个东西――那也就是个c++语言的练习罢了。
　　
　　在今天的程序员眼中，应用服务器似乎也成了价格低廉（如果不是全然免费）的日用消费品。所以，想要理解它们在那几年的大行其道，就非得借助kruglinski这样的智慧不可。
　　
　　在1999年底，市面上可以找到30种以上自称“java应用服务器”的产品，可见当时这类软件是网络风险投资的宠儿。但是此时出台的j2ee规范就像是一阵席卷整个产业的劲风，在一夜之间，所有人都有了判断什么是一个“应用服务器”的权威途径。
　　
　　为了获得一张j2ee竞技场的入场券，各家厂商面临两项考验：首先，要具有能够覆盖j2ee中所有主要技术的产品线。这在当时是一项非常苛刻的要求，在没有开源产品可供参照的情况下，短时间内推出包括ejb容器、web引擎和jms中间件的整体解决方案，这决不是随便哪家创业公司都能办到的。
　　
　　完成了若干次成功的并购之后，bea在这一点上抢占了先机，完整的产品线使它成了人们心目中的首选j2ee平台提供商。其次，要让产品通过sun的j2ee兼容性测试。要做到这一点同样不易：就连ibm的websphere也一时还没达到百分之百的ejb支持。
　　
　　到2000年底为止，共有15家厂商能够提供完整的j2ee解决方案，其中9家（包括sun本身）实现了“j2ee兼容”，他们中间包括了日后这个领域的主要竞争者。毫无疑问，这是一次非常残酷的行业洗牌，但留在场内的厂商也相应地形成了推动j2ee发展的主体力量。
　　
　　上面说过，在它的孵化阶段，sun的j2ee团队主管是女强人mala chandra，她本人虽不是工程师出身，但对技术有着很强的感知能力和想象力；j2ee一出台就能够为人们提供一幅完整、直观而不失深邃的图景，此中当然有chandra本人的大量贡献。
　　
　　在她直接领导下工作的几位工程师，也都是sun内部非常杰出的人才。无论是制定了jdbc、jms等规范的mark hapner、javamail的设计者bill shannon，还是ejb的主要设计者vlada matena，后来都是业界一言九鼎的技术领袖。
　　
　　这个班子的合作时间并不太长：2000年左右的那个时期正是it界创业的黄金年月，chandra很快就和sun公司java部门的总裁（也是创造java的功臣之一）alan baratz一起，到一家刚起步的email中间件公司zaplet淘金去了；捷克裔的开发天才matena也离开sun开办了自己的公司。留下的两个人hapner和shannon先后担任了j2ee技术的首席设计师。