写点什么

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

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

关注

评论

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

打破壁垒,实现多引擎3D内容轻量化交付|点量云流

点量实时云渲染

Unity 视频流 实时云渲染 ue 3D实时云渲染

我们小公司,哪像华为一样,用得上IPD(集成产品开发)?

快乐非自愿限量之名

产品开发

为什么AI大模型离不开GPU?

Finovy Cloud

AI gpu GPU算力

AutoMQ 对象存储数据高效组织的秘密: Compaction

AutoMQ

Java 云计算 云原生

对话阿里云云原生产品负责人李国强:推进可观测产品与OpenTelemetry开源生态全面融合

阿里巴巴云原生

阿里云 云原生 可观测

如何使用 NFTScan NFT API 在 Mint Blockchain 上开发 Web3 产品和协议

NFT Research

NFT NFTScan API 文档

学校选择云桌面厂家需要考虑哪些因素?

青椒云云电脑

云桌面 云桌面厂家 云桌面系统

数智时代下的低代码如何赋能传统汽车制造企业实现数智转型

快乐非自愿限量之名

低代码 数智制造 智驾

活动回顾 |观测云在杭州论坛上闪耀:教育创新与技术领导力的双重荣耀

观测云

运维 AI大模型

一图解锁 | 运维管理到工具体系的建设逻辑

嘉为蓝鲸

运维管理 运维工具

反射API与AOP:打造可插拔的插件式架构

技术冰糖葫芦

API Explorer API 文档 API 性能测试

华为云发布ServiceStage:内置优秀业界实践「云应用管理和运维」模板

华为云PaaS服务小智

云计算 软件开发 华为云

小而美:两步完成从源码到应用的极简交付

阿里巴巴云原生

阿里云 Serverless 云原生

基于Python的性能优化(线程、协程、进程)

我再BUG界嘎嘎乱杀

Python 性能优化

业务功能流程图是什么,怎么做?附带推荐8款流程图软件!

彭宏豪95

效率工具 职场 流程图 在线白板 流程图绘制工具

百度王颖:百度文库开启创作新纪元,人人都是内容创作者

Geek_2d6073

智研未来,直击 AI DevOps,阿里云用户交流日杭州站来啦!

阿里云云效

阿里云 云原生

低代码如何赋能电信运营商行业数字化转型

EquatorCoco

低代码 运营商

Apache IoTDB 分布式架构三部曲(一)集群概念

Apache IoTDB

NumPy 正态分布与 Seaborn 可视化指南

EquatorCoco

正态分布 Numpy

AutoMQ 社区双周精选第十期

AutoMQ

Java 云计算 云原生

智研未来,直击 AI DevOps,阿里云用户交流日杭州站来啦!

阿里巴巴云原生

阿里云 DevOps 云原生

机器人流程自动化与低代码流程自动化:技术革新的双重驱动

不在线第一只蜗牛

RPA 低代码 机器人自动化

飞天发布时刻|阿里云可观测全速演进

阿里巴巴云原生

阿里云 云原生 可观测

彻底搞懂JavaScript原型和原型链

快乐非自愿限量之名

JavaScript 原型

心识宇宙 x TapData:如何加速落地实时数仓,助力 AI 企业智慧决策

tapdata

数据库 Clickhouse 数据集成 CDC

带你一起阅读《Forrester Wave:AIOps 调研报告》

乘云数字DataBuff

火山引擎边缘云亮相 Force 原动力大会,探索 AI 应用新范式

火山引擎边缘云

【FAQ】HarmonyOS SDK 闭源开放能力 —Ads Kit

HarmonyOS SDK

HarmonyOS

前端菜鸡,对于35+程序员失业这个事有点麻了

伤感汤姆布利柏

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