J2EE死了 javacript + 后端JSON服务方式胜出

12-11-01 banq

J2EE死了 javacript + 后端JSON服务方式胜出（J2EE is Dead: Long-live Javascript Backed by JSON Services）

以下是大意摘要：

过去我们看到：MVC和HTTP/CRUD 正在被快速开发的Rails替代，后端JMS之类组件从J2EE容器移出进入ESB或其他非基于J2EE的事件驱动系统(EDA)。

企业采取Fuse, Camel 和 Mule作为事件驱动后端选择，虽然我们没有看到Rails铁轨能够全面铺入企业软件。但是我们看到一个很强烈的运动趋势，向轻量的非J2EE容器的Web应用方面去部署和使用。

经过调查，世界上有一半服务器在使用tomcat:

前端浏览器将使用Javascript，其与后端的Json服务交互，Java将实现后端JSON服务，更有甚者，无需tomcat,直接使用DropWizard启动普通的Java Class类，这样，前端人员根本无需学习Servlet或其他J2EE知识。

最后，在这个文章的讨论中，有人说他们采取 RabbitMQ 和修改的Guava EventBus取得成功，这种方式是： "Node.js + Java + Event Bus".

gameboyLV

2012-11-02 09:17

我很好奇，用这样的架构SEO怎么处理？

banq

2012-11-03 16:52

2012-11-02 09:17 "@gameboyLV"的内容

我很好奇，用这样的架构SEO怎么处理 ...

可以用这个试验：http://code.google.com/web/ajaxcrawling/，它能为爬虫Bot产生Html快照。

这篇文章主要宗旨我认为是简化，目标是让前端工程师更简单方便设计界面，提升用户体验，作者推荐后端采取无Tomcat的简单Java Application方式提供JSON服务，没有考虑到大规模并发性能，简化不能减性能，否则用计算机干嘛呢？

为达到简化开发设计但是不降低性能目标，云计算实现了业务和技术分离一文应该解决这个问题，实际上就是"Node.js + java + Event bus"的具体实现。

让javascript跨越前端客户端，在传统后端服务端也可让界面设计师使用Javascript，因为他们是设计出身，有基因设计爱好，所以，他们对软件设计也不会排斥，只要这种设计思想简单直观就可以。

相信，未来可能更多界面(产品)设计师抢软件工程师的饭碗，跨越边界，是喜还是忧？

gameboyLV

2012-11-03 20:57

2012-11-03 16:52 "@banq"的内容

相信，未来可能更多界面(产品)设计师抢软件工程师的饭碗，跨越边界，是喜还是忧？ ...

我曾经参与过一个项目，有明确的角色分工：

axure RP －－需求工程师（原型设计，早期UI）
photoshop －－美术工程师（效果图设计）
==========
flash catalyst －－视觉工程师（根据效果图设计交互和动画效果）
flash builder －－UI工程师（将数据绑定到flash catalyst导出的控件）
REST/WebService/JSON －－前端开发工程师（为UI提供数据）
==========
Business Layer －－软件工程师（处理业务）
Infrastructure Layer －－软件架构师（基础结构层和服务层）

flash catalyst真是一个好东西，他能将效果图直接转换为可以交互的控件，将控件导入到flash builder中可以大大减轻UI工程师的负担

json也是一个好东西，可以将DTO的原始数据直接返回给UI工程师

你说的跨越边界的问题并不存在。
界面设计师可以会PS，可以会axure，也可以会文案，但她再厉害也不可能会RIA吧，毕竟现在FLEX/HTML5/SL都会涉及到MVC之类的框架。
前端工程师可以会RIA，可以会stage3d/webgl，也可以会REST，但他再厉害也不可能跑到业务层去捣乱吧。。。

banq

2012-11-06 11:34

该文主要从过去现状Tomcat Web容器替代了完整的J2EE容器这个角度，从未来角度来看，J2EE/Java EE的持久化部分，也就是JPA/ORM面临CQRS/Event Sourcing的挑战，见：新编程范式：面向事件的数据库

猜你喜欢