AICon 深圳站聚焦 Agent 技术、应用与生态,大咖分享实战干货 了解详情
写点什么

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

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

关注

评论

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

加入我们|申请成为亚马逊云科技 Community Builder,共建云端社区!

亚马逊云科技 (Amazon Web Services)

MIAOYUN荣获“新质榜样·2024信创力量最佳技术解决方案奖”

MIAOYUN

云计算 云原生 解决方案 信创 超融合

从0到1:基于SSM的陪诊小程序开发笔记(一)

CC同学

HBase深度历险

京东科技开发者

图片秒变短视频!阿里妈妈“淘宝星辰·图生视频”向商家开放使用

新消费日报

Easysearch Rollup 使用指南

极限实验室

Rollup Performance easysearch

AI智能体在自动化测试中的应用

测试人

【GreatSQL优化器-11】finalize_table_conditions

GreatSQL

音视频编解码开发的技术难点

北京木奇移动技术有限公司

音视频开发 音视频引擎 软件外包公司

版面分析技术研究方向:真实世界中更丰富的版面布局

合合技术团队

人工智能 AI 数据集 Transformer

PIRF 421:Measurements – Embracing the Imperial System

Echo!!!

English

智能网联汽车的数据脱敏

芯盾时代

车联网 物联网 数据安全 智能汽车

面向法律场景的大模型RAG检索增强解决方案

阿里云大数据AI技术

人工智能 阿里云 LLM rag PAI

2025-01-15:执行操作可获得的最大总奖励 Ⅰ。用go语言,给定一个整数数组 rewardValues,其中包含 n 个代表奖励值的数字。 你开始时的总奖励 x 为 0,并且所有下标都是未标记状

福大大架构师每日一题

福大大架构师每日一题

反向 Debug 了解一下?揭秘 Java DEBUG 的基本原理

京东科技开发者

记录一次RPC服务有损上线的分析过程

京东科技开发者

基于云主机搭建Termgraph绘图工具,将数据转化为可视化图形

华为云开发者联盟

Python 云主机 鲲鹏 ECS 华为开发者空间

SimCorp最新买方调查显示,人工智能必须更好地融入投资流程

财见

如何在 Windows 上安装 Python 环境的详细指南

克莱因瓶

音乐 NFT 系统的智能合约开发

北京木奇移动技术有限公司

智能合约 软件外包公司 音乐NFT

普通人如何赶上AI大模型浪潮

老张

人工智能 AI 自由职业 第二曲线 大模型

音乐NFT系统开发的技术难点

北京木奇移动技术有限公司

区块链技术 软件外包公司 音乐NFT

深入了解淘宝天猫API接口:商品详情与关键词搜索商品列表的实用指南

代码忍者

淘宝API接口

【FAQ】HarmonyOS SDK 闭源开放能力 —Map Kit(4)

HarmonyOS SDK

harmoyos

地平线Vision Mamba:超越ViT,最具潜力的下一代通用视觉主干网络

地平线开发者

自动驾驶 算法 地平线征程6

《CPython Internals》阅读笔记:p151-p151

codists

CPython Internals

基于Springboot: 宠物小程序开发笔记(上)

CC同学

音视频编解码的性能优化

北京木奇移动技术有限公司

软件外包公司 音视频编码 音视频解码

哈啰:构建智能出行RAG,ES还是向量数据库?

Zilliz

Milvus 向量数据库 rag 哈啰 zilliz cloud

没想到学会这个 canvas 库,竟然做这么多项目

秦少卫

Fabric.js 开源图片编辑器 开源vue图片编辑器 商品定制工具 服装设计工具

音视频编解码的开发框架

北京木奇移动技术有限公司

音视频开发 音视频引擎 软件外包公司

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