写点什么

基于云的 BPM 需要 RESTful 服务吗?ZapThink 答说是,引发质疑声不断

  • 2012-03-17
  • 本文字数:1872 字

    阅读完需:约 6 分钟

ZapThink 的分析师 Jason Bloomberg声称基于云的业务流程管理(BPM)软件将会给那些传统的、不能很方便地迁移到云交付模式的BPM 引擎带来颠覆性影响。Bloomberg 这篇文章并没有描述基于云的BPM 所呈现的价值,而是着眼于他的一个断言——任何云BPM 引擎想要正常工作,基于REST 的服务都是必不可少的。但是,来自ebizQ 的Michael Poulin对此有不同看法,他质疑这种无状态的RESTful 服务是否真的必不可少。

BPM 被认为是一种准则,以改进企业业绩为目标,对业务流程进行构建、管理并优化。商用 BPM 软件解决方案通常会提供一个平台对基于流程的应用和业务规则进行建模,还会包含一个运行时引擎执行这些应用。虽然目前有些人质疑是否 BPM 本身就是一个失败,但 Bloomberg 还是看到了 BPM 的价值,只是惋惜其发展空间被那些中间件厂商们所干扰。

厂商都喜欢 BPM,这是因为流程引擎对其中间件堆栈而言,是一个自然的附加软件。协调多个应用也就意味着产生多种集成,那么为此就需要中间件。诸如此类种种吧。不管我们喊多少口号说跨平台的服务组装可以实现厂商独立的流程,但大部分厂商还是都推出了各自专有的一套工具包。

Bloomberg 认为,如果这些厂商觉得他们可以方便地将其产品转换到云上,那么由于其带状态的架构设计,他们将会事与愿违。

这里讲的东西会比较有意思。为了达到云为分布式应用带来的可伸缩性优势,应用层必须是无状态的。云可能需要产生额外的实例来处理加载,并且任何特殊实例都可能崩溃。但由于云是高度可用且分区容忍的,这样的崩溃一定不能影响运行由云实例支持的流程。

这样一来,就没有办法让传统的 BPM 引擎在云上正常运行。毕竟,BPM 引擎 _ 存在的价值 _ 在于维护流程状态,但你不牺牲伸缩性在云实例上就做不到!换句话说,大厂商们所投入的用以构建以 SOA 平台为中心的 BPM 引擎上的全部人力物力现在都白费了。云已经改变了 BPM 的规则。

Bloomberg 认为,基于云的 BPM 解决方案必须用(在客户端和服务器端传递的)消息来维护流程状态。这可以通过使用 REST 超媒体方面的特点并删除客户端与运行 BPM 引擎服务端之间的所有耦合做到。

一旦你仔细想想会发现这个观点的强大是显而易见的,因为 W3 本身就是这样一种运行时工作流的原型样例。你可以想象这样一种工作流:任意一系列的点击链接,然后加载 Web 页面,最终——你所见到的那些页面往往是不同服务器上所提供的各种不同的资源。你看不到一个重量级的、统一的流程引擎。

以【面向超媒体的架构】为基础的 BPM 是一种潜在的颠覆性技术,而它也正面临技术革新的窘境。

虽然对 Bloomberg 上述观点表示赞赏,但 Poulin 提出了他的四段论,对无状态性是基于云的 BPM 解决方案的关键这一断言提出了异议。Poulin 对消息中过度的状态传输持保留态度。

由此可见,如果一个服务以流程的方式实现,那么它可以自由管理其自身状态,可以是有状态的或是无状态的(如果你把服务看成是一个服务工厂,并且你可以按需要来初始化服务,那么你的限制就只会在硬件资源上,而不是服务状态)。在 2008 年就有关于在消息交互中携带流程状态信息的想法,但仍然保持服务的无状态性给很多那些通过服务接口来发送以兆计算消息字节的人很痛苦的失败教训。

我没有看到云伸缩性和运行在云中应用的无状态性之间有任何关联。

一个基于云的 BPM 解决方案能否在没有统一引擎支持、仅仅依赖超链接以及客户端管理状态下成功?Poulin 通过一个理论认证表达了他的顾虑。

好吧,假设我们不做流程处理,而只用链接。比如,我们使用 HTTP 的 GET 和 PUT 方法启动一个流程,这符合“无需流程引擎!”的说法:当流程被触发,一个链接指向规则引擎,并期望返回一个下一步该做什么的说明。那这个说明返回何处呢?规则的请求者是“无状态的”流程,执行响应客户端请求;那么,该说明可能只会返回客户端(记住,流程可能并不维护其状态),并且在这种情况下,返回的说明字节数要足够短,以满足 GET/PUT 方法的要求。接下来,客户端再调用同一个流程(可能不同实例),并把说明传递回(到云中?)“流程”继续执行,以此类推。如果你能够这样就把它推销出去并做成生意,拜托,告诉我一下,让我们来庆祝这桩生意是多么的愚蠢。

Bloomberg 说他的方法对某些人来讲可能有点激进,他反驳说许多基于云的公司都已经在按这种新模式运行。尽管如此,Poulin 建议在把 BPM 这样的东西转移到云之前,业务执行者应该谨慎,并且遵循 Peter Drucker 的建议:

“没有什么比有效地做那些根本不需要做的事更无用的了。”

查看英文原文: Does BPM-in-the-Cloud Require RESTful Services? ZapThink Says Yes, but Doubts Exist.

2012-03-17 04:221742
用户头像

发布了 52 篇内容, 共 19.2 次阅读, 收获喜欢 3 次。

关注

评论

发布
暂无评论
发现更多内容

TensorFlow2 Fashion-MNIST图像分类(二)

书豪

TensorFlow2 Fashion-MNIST图像分类(一)

书豪

tensorflow 学习

Gemini双子新约系统软件开发|Gemini双子新约APP开发

系统开发

深入Linux内核架构——进程虚拟内存

赖猫

c++ Linux

LeetCode题解:515. 在每个树行中找最大值,BFS,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

修一座安全的广厦,庇护赛博世界的流浪者

脑极体

生产环境全链路压测建设历程之五 针对稳定性矛盾, 从目标、流程、组织体系发力

数列科技杨德华

架构词典:工程

lidaobing

架构 工程能力

滴滴开源小桔棱镜:一款专注移动端操作行为的利器

滴滴技术

开源 滴滴 移动端

一道腾讯面试题目:没有listen,能否建立TCP连接

linux大本营

c++ Linux TCP 后台开发 TCP/IP

观点|发展区块链金融,长三角如何建设“四梁八柱”

CECBC

区块链

cartographer环境建立以及建图测试(详细级)

良知犹存

cartographer slam

SDK开发质量保障经验总结

张明云

接口 程序设计 接口测试 sdk SDK测试

架构师训练营W08作业

Geek_f06ede

合伙开公司、借款变工资 | 法庭上的CTO(7)

赵新龙

CTO 法庭上的CTO

揭开IP地址的神秘身份!!!

德胜网络-阳

甲方日常 66

句子

工作 随笔杂谈 日常

http client 中的 connectionRequestTimeout, connectTimeout, socketTimeout

不在调上

架构师训练营第 1 期 - 第 11周 - 学习总结

wgl

极客大学架构师训练营

DolphinDB与Pandas对于大文本文件处理的性能对比

DolphinDB

数据库 pandas tsdb 数据库选择 DolphinDB

加密货币可能是人类历史上最大的/富国银行报告:加密货币投资像19世纪50年代的早期淘金热财富转移

CECBC

数字货币

海量数据架构下如何保证Mycat的高可用?

冰河

分布式事务 分布式数据库 分布式存储 mycat 数据库集群

案件数同比下降七成 北京引入“区块链”化解物业纠纷

CECBC

区块链 法律

天下武功,唯”拆“不破| 技术人应知的创新思维模型 (4)

Alan

思维模型 技术人应知的创新思维模型 MECE 组合创新 28天写作

诚招译者 | Bruce Eckel On Java 8 中文版

图灵社区

Java

Redis Sentinel-深入浅出原理和实战

Linux服务器开发

redis 中间件 底层应用开发 web服务器 Linux服务器开发

本文帮你在Unix下玩转C语言

MySQL从删库到跑路

unix C语言

架构师训练营第 1 期第12周作业

业哥

docker与podman的故事:一个方兴未艾,一个异军突起

晓川

大促中为什么需要可视化监控大屏?

京东科技开发者

大数据 监控 数据可视化

CTO与COO联手接了公司的外包项目 | 法庭上的CTO(6)

赵新龙

CTO 法庭上的CTO

基于云的BPM需要RESTful服务吗?ZapThink答说是,引发质疑声不断_REST_Richard Seroter_InfoQ精选文章