CIO:扯不清 剪不断的BPM ESB SOA

2019/02/13 17:05

新知图谱, CIO:扯不清 剪不断的BPM ESB SOA

SOA和ESB BPM一直是没有明确的定义

原因是这三个词包含的内涵太丰富了,无法用一两句话说清楚,并且,这个词在不同的地方含义也有所不同。

SOA----面向服务架构,实际上强调的是软件的一种架构,一种支撑软件运行的相对稳定的结构,表面含义如此,其实SOA是一种通过服务整合来解决系统集成的一种思想。不是具体的技术,本质上是一种策略、思想。

ESB----企业服务总线,像一根“聪明”的管道,用来连接各个“愚笨”的节点。为了集成不同系统,不同协议的服务,ESB做了消息的转换解释与路由等工作,让不同的服务互联互通。

BPM--业务流程管理,是一种以规范化的构造端到端的卓越业务流程为中心,以持续的提高组织业务绩效为目的的系统化方法,常见商业管理教育如EMBA、MBA等均将BPM包含在内。

为什么ESB总和SOA黏在一块

通常,这两个名词总不分家,谈论的话题中“你中有我,我中有你”。为什么是这样的呢?两者之间究竟有什么微妙的关系呢?ESB不是SOA。SOA的最常见的实现方式方式是SCA和JBI,而SCA的实现需要ESB,相反JBI则不需要ESB其次,因此SCA实际上已经成为SOA的事实标准道SOA,最先想到的就是SCA模式了。ESB是SCA架构实现不可缺少的一部分,ESB产品脱离了具体的应用外,没有任何意义。ESB的作用在于实现服务间智能化集成与管理的中介。通过ESB可以访问所集成系统的所有已注册服务。

BPM 与 SOA 有何区别,为什么如此至关重要?

业界一个众所周知的事实是 “流程在服务上运行”,所以,业务流程管理 (BPM) 和面向服务的架构 (SOA) 是显然分不开的。SOA 的良好设计原则是碎片化、低效地连接到企业的事务主干的流程与作为业务转型的一个重要部分的流程之间的区别。那么我们为什么要问 BPM 在何处结束以及 SOA 从何处开始?一个原因是,这两个缩略语代表着不同类型的概念。BPM 属于业务范畴,以操作改进为目标。SOA 是一种架构风格,以企业的系统(业务和 IT)工程设计为目标。具体来讲,BPM 是一种构建操作解决方案的方法,而 SOA 是一种思维模型,帮助将复杂的问题分解为定义良好且可重用的组件。

另一个原因是,BPM 和 SOA 都对不同的人群有着不同的重要性(并由不同的人群实施)。BPM 对业务和流程分析师至关重要。SOA 对架构师和工程师至关重要。在相互隔离时,二者都有可能生成相同类型的工件,也就是流程和服务定义,但它们是以不同的动机并应用不同的技能集来实现此操作的。架构师和工程师一般无法定义业务希望如何运行自身。相反,业务和流程分析师也无法对复杂的系统进行工程设计,他们不可避免地会将精力集中在解决目前手头的问题上。最后,BPM 和 SOA 各自的输出的生命周期也不同。流程不仅能够独立于服务进行更改,而且它们更改的频率也比设计良好的服务要高得多。事实上,如果一个可重用的服务像许多业务流程一样变化无常,那么该服务会给它的用户带来无法接受的成本,迫使他们对更新的版本进行持续调整和回归测试。流程和服务尽管彼此依赖,但它们没有相同的生命周期,它们仍然需要像过去一样共同支持不断变化的业务目标。如果流程不受约束地带动服务,那么服务数量会激增,而最终的 SOA 结构也会比不上一组纠缠在一起的遗留应用程序。如果服务不受约束地带动流程,那么变革和创新将会受到影响,因为任何更改都会度量最终结果是否可重用,尽管事实上许多业务流程完全不需要可重用。要了解 BPM 与 SOA 之间是否达到适当平衡,则要了解从单个流程解决方案角度来看的目标与从企业服务组合角度来看的可管理性之间是否达成一致。

SOA落地少不了BPM吗

大部分企业在信息化过程中为了实现某种特定的应用而构建的一个个独立系统,现在已经制约了系统间的数据共享,也阻碍着系统效率的提高。如何消除这些信息孤岛,使各类信息资源实现彼此间的关联、整合、协同和互动,正在一次次地考验着企业信息系统的建设,而这正为那些基于SOA中间件或平台厂商的发展带来了巨大空间。而区别于SOA所推崇的以技术创新驱动实现业务需求的做法,国内的大部分BPM中间件及平台厂商则更多的是以业务为核心,以业务领域的需求为出发点,结合实际对BPM应用或平台进行开发。在开发的过程中,厂商力求通过逐步增强系统的集成能力并实现较为丰富连通性,最终达到缩短业务交付周期同时增强综合竞争力的目的。使系统更加地基于组件化、服务化, 并且朝着SOA的方向前行, 最终实现SOA与BPM的完美融合。可以说,在SOA落地后,BPM可能会起到更大的作用。

BPM厂商模糊了 BPM 与 SOA 之间的界限

许多供应商产品,尤其是 BPM 产品,模糊化了 BPM 与 SOA 之间的界限,因为 BPM 产品随带了一个嵌入式企业服务总线 (ESB)。一个企业服务总线是体现和形式化使用者、中介和提供者概念的模式;因此从技术角度来讲,它是一项核心 SOA 技术。嵌入式 ESB 常常随带一个 BPM 产品的原因很简单,前面已经讨论过,因为 BPM 假设流程的自动化部分可连接到基础 IT 功能,所以连接和中介功能必须可用,否则 BPM 解决方案将仅以人为中心。但是,即使使用一个嵌入了 ESB 的 BPM 套件,仍然应该牢记的是,BPM 和 SOA 是由拥有不同技能的人完成的。事实上,组合的 BPM 和 SOA 产品的一个合理需求是每个群体都有专用的工具:流程专家和集成专家。而且,如果 SOA 是企业战略的一部分,必须警惕的是,将 SOA 功能从 BPM 平台外部化需要一个过程,毕竟 BPM 不是服务的惟一使用者,只需想想移动、云和大数据,您就会明白!

ESB与BPM怎么也能粘扯上了?

有些架构师看到ESB支持服务组合(Service Composition)模式,进而认为可用该模式来实现业务流程。因此,ESB产品就演变成了BPM产品。如果关心过ESB的通用使用模式,就会发现ESB的服务组合模式(Service Composition)与BPM中的服务编排(Service Cherography)非常相似,二者都是将细粒度的服务组合/组装起来,形成大粒度的服务,或者业务流程。事实上二者有着本质的区别。

其一:ESB是一个偏向技术层整合的组件,比如将“客户资料查询”服务与“日志”服务组装起来,得到的结果还是“客户资料查询”服务,只是在仲裁流中间插入了一个新的附加功能,即“日志”服务。BPM中的服务编排的含义很侧重于业务流转的概念。比如“项目立项审批流程”,该流程的实现可能需要来自几个相关系统中的服务的参与,它们可能是“立项申请”,接着是“一级职能经历审批”,然后是“部门经理审批”,“财务审批”等。这些服务流转起来形成的是一个完整的业务流程。

其二:ESB上的服务组合是无状态的,ESB运行时会为每个请求建立一个实例来执行其仲裁逻辑,请求与请求之间没有时序关系,是互不相干的、各自独立的。相反,BPM上的服务编排这不一样,未完成的业务流程实例一直会存活在BPM运行时中,存活期可能为一天、一周、甚至1个月或更长;请求与请求之间可能存在着一定的关联性,比如对与一个项目(相同的项目ID)的立项审批流程,一级职能经理、部门经理和财务对流程发出的请求都是针对同一运行时实例的。

除了其他非技术的因素外,导致该实践的一个重要原因是:混淆了ESB的服务组合与BPM的服务编排两个概念。让ESB实现BPM,特别是长运行的流程时,虽然在技术上可以实现,但是这违背了ESB产品的设计理念,会大大影响其ESB运行时的整体运行效率。

建议:认清技术上的服务组合与服务编排之间的差异,分析每个产品所属的概念范畴,选择合适的产品解决合适的问题。ESB带给业务流程管理的好处是连通性——使一个应用中发生在不同部分之间的交互有序化。正如应用变得更加的高度的分布,这样的ESB的作用也越来越多。在企业的BPM开始的时候,应用开发团队必须解决的附加问题是每个独立的ESB支持许多通信方法。

需要注意什么吗

结合使用 BPM 和 SOA (含ESB)仍然目前前是一种常见做法,但是必须花心思有效地解决流程专家、集成专家和服务架构师之间在技能和思维模式上的区别。所有这三个群体都是业务变革的关键,他们必须协力完成共同的目标。如果没有明确定义 BPM 与 SOA 之间的界限,那么每个群体都会对他们的角色和职责做出自己的假设,这些假设很少与其他群体的假设匹配。对于遗留的IT系统改造来说,作为一种技术演进似乎并不天然从属于业务流程管理,这也是为什么很多流程分析师,业务用户甚至CIO看不到存在关联的原因。但是如果没有BPM策略,你是没有办法做好包括流计算在内的应用模型改变的,这些可是下一代应用架构的基础。不要对IT技术人员或像以前一样构建应用系统提出一些在特定业务领域中的需求用BPM实现,而是要让BPM根据业务模型或应用服务的注册来完成端到端的完整的业务生命周期,确定完整合适的业务流程,这样你才能取得胜利,不会重滔覆辙.

更多新知

知识库

已收录新知
2 1 6 7 8 0