J2EE成功背后的问题

Dan Creswell(这个人在2004获得了Jini Contributors Award,而且是Apache River项目的重要成员)发表了一篇Blog"Victims Of J2EE Success,",其中谈到:现在J2EE已经在Java中间件中成为统治地位的技术标准,但一些特定的应用程序的需求却不能够使用J2EE所设计的标准去解决,例如eBay,MySpace或者Google,这时问题就产生了.

对于J2EE编程者,他说:(下的的引用是从Blog中翻译的)

  

作者的文章里谈到一些其它技术,但核心的问题就是这个.
不知道各位有没有遇到他所说的情况?

. 外刊IT评论  
.

 

Deploy more or bigger boxes to scale:通过部署更强大或更多的服务器来提供可伸缩性
So where does one find Java programmers that can cope with such a challenge?
到哪儿去找可以应对这一挑战的Java程序员呢？

ebay只是开发了自己的基于j2ee的框架，以及在应用配置、部署上作了些文章，并没有跳出j2ee吧？

其实现在很多人提到J2EE或者JavaEE，这个名词本身的概念都是含糊不清的。我们需要讨论以下的几个问题：

1. JavaEE是否仅代表JCP所制定的各种规范？
是否只有JSF和EJB属于JavaEE？Spring是否属于JavaEE？Hibernate呢？（当然，Hibernate现在已经能够支持JPA了，那么在它不支持某个JCP规范之前呢？）还有貌似另类的Cocoon呢？
2. JavaEE能否代表服务器端基于Java的各种技术的总和？
如果只有RMI/EJB和SOAP/WSDL/JAX-RPC属于JavaEE，那么Hessian是否属于JavaEE呢？还有Lucene呢？
3. 与Rod Johnson提出的J2EE!=EJB一样，Java!=J2EE。做服务器端的Java开发，是否一定要把自己局限在JCP官方所制定的各种规范上呢？

把这几个问题讨论清楚之后，才能认识清楚究竟很多地方是Java语言本身的问题呢？还是因为一些拙劣的设计和缺乏实践检验的规范（就是Rod Johnson所谓的“委员会驱动的设计”）所造成的。

虽然据我看来，Java的能力要比现在的JavaEE规范还要大的多，但是我们确实也应该眼界更加宽广一些，多了解一些其他社区例如Ruby、Python社区的成功实践经验。这样才能以pragmatic的观点来做设计，而不是处处design by buzzword。

JavaEE是什么，很清晰，JavaEE规范有明确的定义，某技术属不属于JavaEE，去查官方规范吧。 spring, hibernate能实现企业级解决方案，但明显不是JavaEE这个词所包含的。 rod johnson很pragmatic，早在几年前已经在他的书中提出J2ee并非万能，应该根据具体应用去组合各种j2ee/非j2ee技术去设计系统。

这篇blog的意思也就提醒设计都不要把思维被“规范”，“标准”所束缚。规范比较适合解决已经遇到过的问题，但像myspaces, ebay, google, yahoo等“非典型”的网站来说，他们的问题都是不是规范可以解决的。当然当“非典型”的数量大了，慢慢地也就成了典型了。

Rod Johnson等人应该不是这样想的。他们写的书名叫做《J2EE Development without EJB》，说明他们认为基于轻量级框架（例如Spring、Hibernate等开源框架）所做的开发仍然是J2EE开发。Spring和Hibernate仍然属于J2EE，只是把EJB这个技术排除掉了。否则Rod Johnson会将书名改为《Server-side Java Development without J2EE》。Spring和Hibernate仍然是基于一些J2EE规范（Servlet、JDBC、JTA、etc.）来做开发的，只是更多地利用了Java语言本身的能力，而不是将自己限制在J2EE规范的狭小范围内。

JavaEE应该扮演的是基础库,兼容规范,平台的角色,Spring、Hibernate等开源框架都属于兼容性方案