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".

    

6
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的挑战,见:新编程范式:面向事件的数据库