写点什么

基于云的 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:222049
用户头像

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

关注

评论

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

python subprocess-更优雅的创建子进程

jeffery

Python

五种C语言非数值计算的常用经典排序算法

华为云开发者联盟

算法 记录 C语言 排序 非数值计算

WireGuard 教程:使用 DNS-SD 进行 NAT-to-NAT 穿透

硅基新手村

wireguard

产品经理训练营-第三周学习总结

月亮 😝

壁纸欣赏

小马哥

七日更

为什么太过努力有时候也会造成问题

熊斌

学习方法 个人成长 28天写作

人员培养,不是捷径的捷径(上)

一笑

管理 人才培养 28天写作

【Animate.css】CSS动画库

德育处主任

CSS css3 html/css 28天写作

java import 导入包时,我们需要注意什么呢?

看山

Java import

工具词典: MIT

lidaobing

MIT 28天写作 Slidepad Roam Research

创业公司如何做技术品牌? | 视频号28天(25)

赵新龙

28天写作

【初级】个人分享Vue前端开发教程笔记

我是哪吒

程序员 面试 Vue 大前端 2月春节不断更

Elasticsearch Document 增删改内部原理

escray

七日更 28天写作 死磕Elasticsearch 60天通过Elastic认证考试 2月春节不断更

管理笔记[3]:各得其所,各尽其才

L3C老司机

第5周课后总结-技术选型一

潘涛

架构师训练营 4 期

极客大学产品经理训练营 解决方案的设计与积累 第6课总结 John 易筋 ARTS 打卡 Week 37

John(易筋)

ARTS 打卡计划 极客大学产品经理训练营 解决方案的设计与积累

腾讯会议增长背后的技术实践

李忠良

28天写作

创业失败启示录|舌尖辨茶

阿萌

28天写作 创业失败启示录

第十周学习总结

Binary

算法训练营总结

Geek_ac4080

机器学习·笔记之:Gradient Descent For Linear Regression

Nydia

如何理解平行宇宙

陈东泽 EuryChen

科普 物理 平行宇宙 平行世界

PMI 项目管理认证体系

Ian哥

28天写作

写一个玄幻的序章——梦想种植「幻想短篇 24/28」

道伟

28天写作

作业二

KYoKO

科普篇:新冠疫苗解读

石云升

28天写作 2月春节不断更 新冠疫苗

一致性hash算法

Geek_mewu4t

终于用我的那个二手显卡搭建好了TF2的环境

IT蜗壳-Tango

七日更

第5周课后练习-技术选型一

潘涛

架构师训练营 4 期

与前端训练营的日子 --Week14

SamGo

学习

马克吐温关于拖延症的几个段子

Justin

心理学 工作效率 拖延症 28天写作

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