我把EE 6称为 一个全新的生态系统的开始。你们中的一些人可能认为这是夸张。好吧，这就是我认为它是可能的原因。
多年来，网络应用开发者被困在“太多”和“太少”之间。像Tomcat这样的Servlet容器并不提供他们需要的所有基础设施，缺少关键的项，如事务管理、持久性和“容器管理”的bean。但许多团队也觉得像JBoss这样的Java EE容器强加了一些他们不需要或不想要的负担。他们不需要或不想要CORBA ORB、对EJB 2.x的支持、Web服务堆栈、EARs、远程EJB等。
同时，像JBoss这样的供应商也被困住了。EE品牌对我们来说很重要，因为它向我们的客户发出信号，表明为我们的平台编写的代码可以移植到其他Java EE的实现，以及现有的应用程序可以轻松地移植到我们的平台上运行。不出所料，我们与许多开发者一样，对Java EE要求的一些技术的有用性持有相同的看法。例如，几年前当大家都在跟随WS-WXYZ悬崖跳的时候，我们都摇头表示惊讶的绝望。我们不得不悄悄地实现这些功能，然后希望我们的用户实际上不会用它们做任何事情。
其他供应商，如Caucho，选择了不同的路径。对于一个小公司来说，实施Java EE要求的所有内容，包括许多对客户来说并不有趣的技术，是一项巨大的负担。因此，他们提供了一个Servlet容器，并部分实现了某些EE API。当然，潜在的客户永远无法确定Resin与其他服务器之间的可移植性。
在这个令人困惑的环境中，许多开发者拒绝使用EE，而是根据自己的需求，基于像Tomcat这样的普通servlet容器拼凑起自己的技术栈。由于这些技术的集成非常困难——servlet容器从未提供过太多的框架集成支持——像Spring框架这样的解决方案应运而生，它为各种技术提供了预构建的集成。Spring最终演变成一个与EE平台竞争的专有容器。遗憾的是，Spring的专有特性导致了供应商锁定和创新的减缓。Spring的创新步伐如此缓慢，以至于与后来出现的CDI等技术相比，Spring现在显得相当过时。
Java Web开发现在如此分裂，以至于像我这样的框架开发者很难编写能够在所有这些环境中运行的代码。例如，自2002年以来就有完整、标准的解决方案，但事务管理现在却是一团糟。
以下是Java EE 6如何改变这一切。
Java EE Web Profile定义了一个更小的容器，只包含大多数开发者真正需要的技术：servlets、JPA、JTA、CDI、EJB Lite。这使得EE更容易实施，可能会导致市场更加活跃，有更多的实现，以及更短的发布周期。它确实消除了许多开发者不采用Java EE的主要原因。
更好的是，CDI便携扩展SPI使得将技术集成到Java EE环境中的过程变得更加容易。而且，由于一些CDI实现也运行在像Tomcat这样的普通servlet容器中，CDI还可以作为将这些环境中的技术集成的基础。
因此，我们为一个新的生态系统奠定了技术基础。这是一个开发者可以感到舒适的平台，可以让供应商专注于客户真正关心的事情，使得框架开发者可以轻松集成。唯一缺少的成分就是让社区对此感到兴奋。:-)
