老去的JEE，焕发生命

JEE的社区

JEE从出生到现在，十多年了。在软件领域，好听的说法，基本上就是Legacy系统了，不好听，那就是恐龙。曾经疯魔万千开发者的Springframework， Jboss 社区， Apache 的JEE社区，全都跑去了Node.js, Scala，JQuery，Hadoop, Spark。

一个大家纷纷转向云平台和大规模数据处理的年代，更轻便更灵活的Web框架层出不穷的年代，JEE看起来老态龙钟，那些编程模型和容器，看起来已经是昨日黄花。再也没有人愿意只用别人制定的的模型，在这个git hub和 node.js 的时代。老式的编程模型代表着一种专制和居高临下的态度，只有遵守那些不容违反的规则，并在指定的活动范围之中，才能得到系统的承认。

Spring framework第一个挑战这个哲学，然后迎来了Spring社区的兴盛，没人再关心JEE系统，JEE模型从此变成了基础设施。不过在挑战这个哲学上面，赢得开发者的欢心之后，Spring却也没有走的更远，到最后其实也只是稍稍灵活一些的JEE而已。

真正的Internet时代

Node.js的出现具有非常重大的意义，可能很多人并没有意识到这一点。你可以在任意的抽象层面工作，你可以定义自己的抽象级别，任何层级都是开放的。我们可以看到很多类JEE的框架，但却没有任何编程模型的限制，开发人员可以在任何他愿意的层级上去工作。从前需要大公司指定标准和规范的年代已经一去不回了。

从Google的论文公开的那一天起，MapReduce就代表了这个时代处理数据的方向，各种类-MapReduce一直在涌现。从前的关系型数据库，也失去了光环。

这些技术，极大地压缩了JEE的生存空间。Web方面，JEE得以兴盛的原因，和今天流行的种种框架和技术相比，从前的亮点今天黯淡无光。唯一剩下的，只有分布式事务的处理器和可靠消息的传输机制，仍然有意义。Webservice上面，更不用说远远不如各种轻便的方案。

抽象

但JEE就是消失中的恐龙吗？难道它所代表的技术从此就毫无意义？只能说JEE在Oracle手中，已经丧失了自我更新的能力。

如果我们仅仅从计算上考虑，MapReduce代表的批处理，如果用JEE的模型来实现，远远比从头做起要轻松很多。每个MapReduce的计算，如果用JEE的模型看来，也不过是一堆相互进行分布式调用的对象，而JEE的远程部署，消息机制，难道就不能分发MapReduce Task吗？分布式的文件系统，那就更加简单了，多个分布式的对象的协作就能完成这件事。

需要做的，只不过是把那些繁杂的内容变成简单的接口而已。

而Web这一面，实在看不出从前的模式在今天还有多大的意义。除了能够为Java对象提供面向Http的包装之外，但这并不是不可或缺的。

其实，只要在更高的抽象层面去思考。我们就会发现，JEE不失为好的方案，虽然要扔掉很多东西，但终归他可以在一个更宽广的概念内重生。

【我是标题党，YEAH】【仅仅是个思路而已，如何做，做什么，这就不是一个“扯淡”所能包含的了】【有时间再想想】