什么是j2ee

j2ee
开放分类： 科学技术
J2EE Java2平台企业版（Java 2 Platform,Enterprise Edition）
J2EE是一套全然不同于传统应用开发的技术架构，包含许多组件，主要可简化且规范应用系统的开发与部署，进而提高可移植性、安全与再用价值。
J2EE核心是一组技术规范与指南，其中所包含的各类组件、服务架构及技术层次，均有共通的标准及规格，让各种依循J2EE架构的不同平台之间，存在良好的兼容性，解决过去企业后端使用的信息产品彼此之间无法兼容，导致企业内部或外部难以互通的窘境。
    在J2EE架构下，开发人员可依循规范基础，进而开发企业级应用；而不同J2EE供货商，同会支持不同J2EE版本内所拟定的标准，以确保不同J2EE平台与产品之间的兼容性。换言之，植基J2EE架构的应用系统，基本上可部署在不同的应用服务器之上，无需或者只须要进行少量的代码修改，即能大幅提高应用系统的可移植性(Portability)。
J2EE主由升阳(SUN)与IBM等厂商协同业界共同拟定而成的技术规范，以企业与企业之间的运算为导向的JAVA开发环境。J2EE架构定义各类不同组件，如Web Component、EJB Component…等，而各类组件可以再用(reuse)，让已开发完成的组件，或者是经由市面采购而得的组件，均能进一步组装成不同的系统。
对于开发人员而言，只需要专注于各种应用系统的商业逻辑与架构设计，至于底层繁琐的程序撰写工作，可搭配不同的开发平台，以让应用系统的开发与部署效率大幅提升。
    J2EE的核心规范是 Enterprise Java Beans（EJBs）。EJB依照特性的不同，目前共分为三种，分别是Session Bean、Entity Bean，以及 Message Driven Bean 。其中 Session Bean 与Entity Bean 算是EJB的始祖，这两种EJB规格在EJB 1.x版本推出时就已经存在，而Message Driven Bean则是出现在EJB 2.0的规格之中。
目前业界许多程序设计师，或者是网页设计人员，多利用JSP/Servlet的便利性，进而在J2EE服务器之上开发相关的应用，或是整合公司内部的各种资源。
    Java 2平台依照应用领域的不同，共分为三大版本，分别是J2EE、标准版本J2SE（Java 2 Platform, Standard Edition）、微型版本J2ME（Java 2 Platform, Micro Edition），以及Java Card等。
从整体上讲，J2EE是使用Java技术开发企业级应用的一种事实上的工业标准(Sun公司出于其自身利益的考虑，至今没有将Java及其相关技术纳入标准化组织的体系)，它是Java技术不断适应和促进企业级应用过程中的产物。Sun推出J2EE的目的是为了克服传统Client/Server模式的弊病，迎合Browser/Server架构的潮流，为应用Java技术开发服务器端应用提供一个平台独立的、可移植的、多用户的、安全的和基于标准的企业级平台，从而简化企业应用的开发、管理和部署。J2EE是一个标准，而不是一个现成的产品。各个平台开发商按照J2EE规范分别开发了不同的J2EE应用服务器，J2EE应用服务器是J2EE企业级应用的部署平台。由于它们都遵循了J2EE规范，因此，使用J2EE技术开发的企业级应用可以部署在各种 J2EE应用服务器上。
    为了推广并规范化使用J2EE架构企业级应用的体系架构，Sun同时给出了一个建议性的J2EE应用设计模型：J2EE Blueprints。J2EE Blueprints提供了实施J2EE企业级应用的体系架构、设计模式和相关的代码，通过应用J2EE Blueprints所描述的体系模型，能够部分简化架构企业级应用这项复杂的工作。J2EE Blueprints是开发人员设计和优化J2EE组件的基本原则，同时为围绕开发工作进行职能分工给出了指导性策略，以帮助应用开发设计人员合理地分配技术资源。 
J2EE组成了一个完整企业级应用的不同部分纳入不同的容器(Container)，每个容器中都包含若干组件(这些组件是需要部署在相应容器中的)，同时各种组件都能使用各种J2EE Service/API。J2EE容器包括：
    ◆ Web容器 服务器端容器，包括两种组件JSP和Servlet，JSP和Servlet都是Web服务器的功能扩展，接受Web请求，返回动态的Web页面。Web容器中的组件可使用EJB容器中的组件完成复杂的商务逻辑。
    ◆ EJB容器 服务器端容器，包含的组件为EJB(Enterprise JavaBeans)，它是J2EE的核心之一，主要用于服务器端的商业逻辑的实现。EJB规范定义了一个开发和部署分布式商业逻辑的框架，以简化企业级应用的开发，使其较容易地具备可伸缩性、可移植性、分布式事务处理、多用户和安全性等。
    ◆ Applet容器客户端容器，包含的组件为Applet。Applet是嵌在浏览器中的一种轻量级客户端，一般而言，仅当使用Web页面无法充分地表现数据或应用界面的时候，才使用它。Applet是一种替代Web页面的手段，我们仅能够使用J2SE开发Applet，Applet无法使用J2EE的各种Service和 API，这是为了安全性的考虑。
    ◆ Application Client容器 客户端容器，包含的组件为Application Client。Application Client相对Applet而言是一种较重量级的客户端，它能够使用J2EE的大多数Service和API。
通过这四个容器，J2EE能够灵活地实现前面描述的企业级应用的架构。
在View部分，J2EE提供了三种手段：Web容器中的JSP(或Servlet)、Applet和Application Client，分别能够实现面向浏览器的数据表现和面向桌面应用的数据表现。Web容器中的Servlet是实现Controller部分业务流程控制的主要手段；而EJB则主要针对Model部分的业务逻辑实现。至于与各种企业资源和企业级应用相连接，则是依靠J2EE的各种服务和API。
在J2EE的各种服务和API中，JDBC和JCA用于企业资源(各种企业信息系统和数据库等)的连接，JAX-RPC、JAXR和SAAJ则是实现Web Services和Web Services连接的基本支持。
J2EE容器也称为J2EE服务器，大部分时它们概念是一致的。
衡量J2EE应用系统设计开发水平高低的标准就是：解耦性；你的应用系统各个功能是否能够彻底脱离？是否不相互依赖，也只有这样，才能体现可维护性、可拓展性的软件设计目标。
为了达到这个目的，诞生各种框架概念，J2EE框架标准将一个系统划分为WEB和EJB主要部分，当然我们有时不是以这个具体技术区分，而是从设计上抽象为表现层、服务层和持久层，这三个层次从一个高度将J2EE分离开来，实现解耦目的。
因此，我们实际编程中，也要将自己的功能向这三个层次上靠，做到大方向清楚，泾渭分明，但是没有技术上约束限制要做到这点是很不容易的，因此我们还是必须借助J2EE具体技术来实现，这时，你可以使用EJB规范实现服务层和持久层，Web技术实现表现层.
J2EE的各种组件
我们就J2EE的各种组件、服务和API，进行更加详细的阐述，看看在开发不同类型的企业级应用时，根据各自需求和目标的不同，应当如何灵活使用并组合不同的组件和服务。
· Servlet
Servlet是Java平台上的CGI技术。Servlet在服务器端运行，动态地生成Web页面。与传统的CGI和许多其它类似CGI的技术相比，Java Servlet具有更高的效率并更容易使用。对于Servlet，重复的请求不会导致同一程序的多次转载，它是依靠线程的方式来支持并发访问的。
· JSP
JSP(Java Server Page)是一种实现普通静态HTML和动态页面输出混合编码的技术。从这一点来看，非常类似Microsoft ASP、PHP等技术。借助形式上的内容和外观表现的分离，Web页面制作的任务可以比较方便地划分给页面设计人员和程序员，并方便地通过JSP来合成。在运行时态，JSP将会被首先转换成Servlet，并以Servlet的形态编译运行，因此它的效率和功能与Servlet相比没有差别，一样具有很高的效率。
· EJB
EJB定义了一组可重用的组件：Enterprise Beans。开发人员可以利用这些组件，像搭积木一样建立分布式应用。在装配组件时，所有的Enterprise Beans都需要配置到EJB服务器(一般的Weblogic、WebSphere等J2EE应用服务器都是EJB服务器)中。EJB服务器作为容器和低层平台的桥梁管理着EJB容器，并向该容器提供访问系统服务的能力。所有的EJB实例都运行在EJB容器中。EJB容器提供了系统级的服务，控制了EJB 的生命周期。EJB容器为它的开发人员代管了诸如安全性、远程连接、生命周期管理及事务管理等技术环节，简化了商业逻辑的开发。EJB中定义了三种 Enterprise Beans：
◆ Session Beans
◆ Entity Beans
◆ Message-driven Beans
· JDBC
JDBC(Java Database Connectivity，Java数据库连接)API是一个标准SQL(Structured Query Language，结构化查询语言)数据库访问接口，它使数据库开发人员能够用标准Java API编写数据库应用程序。JDBC API主要用来连接数据库和直接调用SQL命令执行各种SQL语句。利用JDBC API可以执行一般的SQL语句、动态SQL语句及带IN和OUT参数的存储过程。Java中的JDBC相当与Microsoft平台中的ODBC (Open Database Connectivity)。
· JMS
JMS(Java Message Service，Java消息服务)是一组Java应用接口，它提供创建、发送、接收、读取消息的服务。JMS API定义了一组公共的应用程序接口和相应语法，使得Java应用能够和各种消息中间件进行通信，这些消息中间件包括IBM MQ-Series、Microsoft MSMQ及纯Java的SonicMQ。通过使用JMS API，开发人员无需掌握不同消息产品的使用方法，也可以使用统一的JMS API来操纵各种消息中间件。通过使用JMS，能够最大限度地提升消息应用的可移植性。 JMS既支持点对点的消息通信，也支持发布/订阅式的消息通信。
· JNDI
由于J2EE应用程序组件一般分布在不同的机器上，所以需要一种机制以便于组件客户使用者查找和引用组件及资源。在J2EE体系中，使用JNDI (Java Naming and Directory Interface)定位各种对象，这些对象包括EJB、数据库驱动、JDBC数据源及消息连接等。JNDI API为应用程序提供了一个统一的接口来完成标准的目录操作，如通过对象属性来查找和定位该对象。由于JNDI是独立于目录协议的，应用还可以使用 JNDI访问各种特定的目录服务，如LDAP、NDS和DNS等。
· JTA
JTA(Java Transaction API)提供了J2EE中处理事务的标准接口，它支持事务的开始、回滚和提交。同时在一般的J2EE平台上，总提供一个JTS(Java Transaction Service)作为标准的事务处理服务，开发人员可以使用JTA来使用JTS。
· JCA
JCA(J2EE Connector Architecture)是J2EE体系架构的一部分，为开发人员提供了一套连接各种企业信息系统(EIS，包括ERP、SCM、CRM等)的体系架构，对于EIS开发商而言，它们只需要开发一套基于JCA的EIS连接适配器，开发人员就能够在任何的J2EE应用服务器中连接并使用它。基于JCA的连接适配器的实现，需要涉及J2EE中的事务管理、安全管理及连接管理等服务组件。
· JMX
JMX(Java Management Extensions)的前身是JMAPI。JMX致力于解决分布式系统管理的问题。JMX是一种应用编程接口、可扩展对象和方法的集合体，可以跨越各种异构操作系统平台、系统体系结构和网络传输协议，开发无缝集成的面向系统、网络和服务的管理应用。JMX是一个完整的网络管理应用程序开发环境，它同时提供了厂商需要收集的完整的特性清单、可生成资源清单表格、图形化的用户接口；访问SNMP的网络API；主机间远程过程调用；数据库访问方法等 。
· JAAS
JAAS(Java Authentication and Authorization Service)实现了一个Java版本的标准Pluggable Authentication Module(PAM)的框架。JAAS可用来进行用户身份的鉴定，从而能够可靠并安全地确定谁在执行Java代码。同时JAAS还能通过对用户进行授权，实现基于用户的访问控制。
· JACC
JACC(Java Authorization Service Provider Contract for Containers)在J2EE应用服务器和特定的授权认证服务器之间定义了一个连接的协约，以便将各种授权认证服务器插入到J2EE产品中去。
· JAX-RPC
通过使用JAX-RPC(Java API for XML-based RPC)，已有的Java类或Java应用都能够被重新包装，并以Web Services的形式发布。JAX-RPC提供了将RPC参数(in/out)编码和解码的API，使开发人员可以方便地使用SOAP消息来完成RPC 调用。同样，对于那些使用EJB(Enterprise JavaBeans)的商业应用而言，同样可以使用JAX-RPC来包装成Web服务，而这个Web Servoce的WSDL界面是与原先的EJB的方法是对应一致的。JAX-RPC为用户包装了Web服务的部署和实现，对Web服务的开发人员而言， SOAP/WSDL变得透明，这有利于加速Web服务的开发周期。
· JAXR
JAXR（Java API for XML Registries）提供了与多种类型注册服务进行交互的API。JAXR运行客户端访问与JAXR规范相兼容的Web Servcices，这里的Web Services即为注册服务。一般来说，注册服务总是以Web Services的形式运行的。JAXR支持三种注册服务类型：JAXR Pluggable Provider、Registry-specific JAXR Provider、JAXR Bridge Provider(支持UDDI Registry和ebXML Registry/Repository等)。
· SAAJ
SAAJ(SOAP with Attachemnts API for Java)是JAX-RPC的一个增强，为进行低层次的SOAP消息操纵提供了支持。
企业级应用示例
下面我们通过假设一个企业应用的J2EE实现，来了解各种组件和服务的应用。假设应用对象是计算机产品的生产商/零售商的销售系统，这个销售系统能够通过自己的网站发布产品信息，同时也能将产品目录传送给计算机产品交易市场。销售系统能够在线接受订单(来自自己的Web网站或者来自计算机产品交易市场)，并随后转入内部企业管理系统进行相关的后续处理。
参见图3，这个企业应用可以这种方式架构。该企业应用的核心是产品目录管理和产品定购管理这两个业务逻辑，使用EJB加以实现，并部署在EJB容器中。由于产品目录和定购信息都需要持久化，因此使用JDBC连接数据库，并使用JTA来完成数据库存取事务。
图3 J2EE应用示例
然后使用JSP/Servlet来实现应用的Web表现：在线产品目录浏览和在线定购。为了将产品目录发送给特定的交易市场，使用JMS实现异步的基于消息的产品目录传输。为了使得更多的其它外部交易市场能够集成产品目录和定购业务，需要使用Web Services技术包装商业逻辑的实现。由于产品定购管理需要由公司内部雇员进行处理，因此需要集成公司内部的用户系统和访问控制服务以方便雇员的使用，使用JACC集成内部的访问控制服务，使用JNDI集成内部的用户目录，并使用JAAS进行访问控制。由于产品订购事务会触发后续的企业ERP系统的相关操作(包括仓储、财务、生产等)，需要使用JCA连接企业ERP。
最后为了将这个应用纳入到企业整体的系统管理体系中去，使用Application Client架构了一个管理客户端(与其它企业应用管理应用部署在一台机器上)，并通过JMX管理这个企业应用。 


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