写点什么

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

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

关注

评论

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

代码随想录Day28 - 回溯(四)

jjn0703

死磕Java八股成功拿下Offer,结果背调没过...

程序员小毕

程序员 面试 高并发 架构师 java面试

代码随想录Day31 - 贪心算法(一)

jjn0703

在 Amazon EMR 上构建实时数据湖

亚马逊云科技 (Amazon Web Services)

Amazon EMR

2023-07-29:给你一个由数字组成的字符串 s,返回 s 中独特子字符串数量。 其中的每一个数字出现的频率都相同。

福大大架构师每日一题

福大大架构师每日一题

对线面试官-线程池连环问

派大星

线程池工作原理 Java 面试题

项目管理的成功秘诀:架构评审的力量

乐思项目管理

架构评审 #项目管理

项目管理中的代码评审:一种有效的实施策略和常见问题解析

乐思项目管理

代码评审 #项目管理

彻底学透分布式事务看这篇笔记就够了!

小小怪下士

Java 程序员 分布式 分布式事务

C++中互斥锁的使用

芯动大师

一个写了3年半flutter的小伙,突然写了2个月uniapp的感悟!

编程的平行世界

uni-app Vue 前端 Flutter Android Apk

Dify.AI 接入 Claude2 模型:支持 100K token 上下文,登录即免费获得 1000 次消息额度

Dify

开源 更新 LLMOps

高可用三大利器 — 熔断、限流和降级

Java研究者

架构 高可用 熔断 限流 java 架构

获评最高级别权威认证!融云通过中国信通院「办公即时通信软件安全能力」评测

融云 RongCloud

通信 即时通讯 办公 融云 百幄

项目管理中的测试:确保项目成功的关键环节

乐思项目管理

项目管理 软件测试

使用APP源码搭建直播网站难不难

山东布谷网络科技

APP开发 直播APP源码

Java Stream 源码分析

java易二三

Java 编程 计算机

致敬图灵!HashData拥抱数据智能新时代!

酷克数据HashData

如何在几分钟内创建一个带有业务数据的官网 AI 智能客服?

Dify

开源 AI开发 LLMOps

项目管理中的'右转必停'原则:慎重决策与风险管理

乐思项目管理

项目管理 #观察生活

代码随想录Day29 - 回溯(五)

jjn0703

代码随想录Day30 - 回溯(六)

jjn0703

慎思笃行,兴业致远:金融行业的数据之道

脑极体

金融数据

代码随想录Day32 - 贪心算法(二)

jjn0703

MedicalGPT:基于LLaMA-13B的中英医疗问答模型(LoRA)

汀丶人工智能

人工智能 自然语言处理 LoRa llama LLM模型

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