RESTful workflow
Topic分享者介绍:朱可,IBM中国软件开发实验室软件工程师,毕业于清华大学。目前在 CETI Web 2.0 小组 , 主要从事 WebSphere sMash 相关的开发工作。对于Web2.0、工作流都有多年的研发和项目经验。李文兵,IBM中国软件开发实验室软件工程师,加入IBM后,一直在CETI Web2.0小组进行Web2.0方面的研发工作。对于REST、工作流以及Web前端开发有比较丰富的经验。目前主要进行WebSphere sMash以及相关工具的开发。
在本Topic中,朱可和文兵对RESTful workflow做了精彩的分享,应该说,这个Topic也是我很感兴趣的,因为之前被Cordys的那个TPF的deom给深深的吸引过,呵呵,在本次活动的末尾,偶还在现场给大家show了那个demo,让大家都RESTful workflow有了一个很直观的视觉体验。在web2.0的时代,RESTful大行其道,呵呵,jBPM4的控制台也发布了RESTful的API,那么在这个web2.0的时代,是不是也可以这样问一句,你RESTful了么?你的workflow RESTful了么?
可能是因为自己一直在做传统的J2EE应用的缘故。虽然我也同意RESTful很好,让被拔高、封装了很多看起来很酷和唬人很学术化很专业化的web编程重新回到其真正的起点。但问题是我们的企业级应用真的能完全RESTful吗?安全、事务如何保证?但也许我的担心只是多余的,因为RESTful有特定的应用场景,传统的J2EE还是有发挥之地,两者长远来看是相互补充而不是竞争。
嗯,没错,目前来看,其实,确实是各自都有其特定的应用场景。REST本身其实就是针对web的,而且是一种更轻量的web,所以它和传统的企业级应用的场景还是有很大区别的。当然随着各自的发展,或许它会慢慢转向一小部分web型的企业应用呢?至于安全性和事务,这是技术层面的问题,就像web service一样,当初才出来的时候也有很多安全性和事务方面的问题,但是现在有了很多的进步,例如ws*-security,ws*-transaction。
但其实Web Service是一个不算成功的东东:),最初的想法应该是和CORBA一样提供一个互操作模型来统一不同的语言和架构。但越做越膨大,结果现在标准已经整了不下十几个了,比当年的CORBA的那一大堆东西只有多没有少,但实际上的效果也和当年的CORBA一样,只有很少的东西被广泛的接受,其他的也都是为了标准化而标准化。
这也是推动RESTful出现的一大原因把。
所以个人感觉还是RESTful不能走和Web Service同样的道路,简单的东西就得这么简单。谈到安全啊、事务啊、那就交给应用服务器去做吧。
程大侠的2个切入点都点中了要害。
1. 从架构的角度来看REST和J2EE的关系
2. Web Serivces的发展现状和未来
我在REST相关的领域做了2年多的产品开发,能够切实地感受到这种架构风格带来的好处,适合互联网风格的应用程序,对天天抱着浏览器的程序员来说,用RESTful的风格设计程序还是比较开心的。
Java EE是企业级分布式计算的模型,市场日臻成熟,规范和相关技术实现、产品和最佳实践直至人才储备,都非常好。看到JSR-311很快进入Java EE6,然后开源社区、各个主要产品提供商都在支持,以 J2EE 为基础的 REST 风格的应用程序前途一片大好。
就像程大侠说的,Web Services 本来的使命是解决异构系统的互操作问题,但是现在还没实现...一个重要的问题是,什么时候用Web Services,什么时候不该用。你可以看到有时候为系统增加 Web Services 接口的成本要比建设系统还要大。但是有时 Web Services 的确管用,尤其是在一个运行了数十年的陈旧系统要和新上线的应用程序进行集成。
Infoq.com 上关于REST的一篇评论文章,非常中肯:


谢谢辛鹏的总结。在这里欢迎大家围绕REST, Web, 动态脚本语言的话题来讨论业务流程,我也可以根据大家的兴趣分享些参考资料。
http://netvibes.com/shawnzhu