CIO进行BPM产品选型应从IT环境、业务环境出发选择

作者: 前端  发布:2019-12-28

在过去的两周里, Progress软件收购了两家公司mdash;mdash;IONA科技和Mindreef,以期拓展其SOA产品系列。该产品系列包括以下种类的产品:企业服务总线、企业消息传递、数据互操作、主机集成、复杂事件处理及SOA管理。IONA是CORBA集成技术方面的业界领军者,它所销售的SOA基础设施产品套件Artix由一个ESB,以及SOA注册库、编配引擎、主机集成与元数据管理等构成。它还通过其FUSE产品线提供开源的SOA集成组件。Mindreef是SOAPscope的生产厂商,那是一个受欢迎的SOAP质量、测试与诊断套件。

尽管SOA的风潮已经鼓荡了几年,但在新业务层出不穷、旧系统之间的联系盘根错节的IT环境之下,许多CIO不得不先忙着应对集成的难题,并希望把面向未来的SOA也一起解决,ESB(企业服务总线)为此提供了一条兼收并蓄之道。在众软件厂商高举SOA大旗展开竞争之际,ESB成为竞争的前沿。Forrester研究公司将ESB(企业服务总线)技术描写成“通过起到中间件的中间层作用而实现面向服务架构(SOA)的软件基础设施,通过这样的中间件,就能广泛利用一套可重复使用的商业服务。”最近,ESB不仅需要支持异构环境中的服务、消息,以及基于事件的交互,还被认为具有适当的服务级别和可管理性。在近一段时期,多家软件厂商都加大了对ESB产品的投入力度,并声称自己的SOA解决方案因此而更加完善,在SOA的赛跑中,ESB是竞争的前沿。 ESB让SOA落地以Cape Clear、Sonic、IONA为代表的ESB领域专门厂商的出击,以增量式部署SOA为口号,强调以一种低廉的、基于标准的Web服务编排工具,并在此之上构建健壮的SOA。而SOA平台厂商纷纷反攻,正在向原有的套件产品中添加ESB和IT治理功能。甲骨文公司去年还只是把ESB产品内嵌在其业务流程管理产品中,今年已经推出了独立的ESB产品。BEA推出了 AquaLogic Service Bus、BEA AquaLogic Data Services Platform来加强ESB的产品线。IBM在原有WBI Message Broker、WAS 6 SIBus这些集成产品之外,又推出了独立的WebSphere ESB产品。而传统的EAI厂商Tibco和WebMethods也宣布了各自的ESB产品。众厂商之所以都看准了ESB这块蛋糕,还得益于SOA理念与现实应用环境的差距。SOA的风潮在软件行业内铺天盖地,连一些硬件厂商都忍不住参与其中,如果解决方案不提SOA就好像落了伍。但在实际应用中,SOA的实施依然不怎么起劲。因为对许多用户来说,SOA目前还是空中楼阁。大谈按照SOA的理念重建应用系统,这种理想状况相信每个人都不会反对,但现实中这样的事情太少,企业的CIO大多面临一件事,就是处理好目前应用系统的运行—集成就自然而然成为最容易切入的话题,由集成开始而赋予应用系统以SOA的灵魂,才确有其现实意义。ESB的冒头也就由此产生,它与EAI(企业应用集成)密不可分,同样是集成,ESB所提倡的集成与EAI的集成既有相同点,也有不同之处。“ESB 的意义在于让SOA有了一个可实现的基础设施。”IONA公司大中国区高级架构师陆飞舟这样认为。他说:“ESB与EAI的主要目的是相同的,但是ESB 更具开放性,尤其是对Web服务的支持,使得它成为实现SOA的基础设施。”BEA公司中国区技术经理刘汩春认为:“SOA的‘服务’不仅仅是可重用,而且必须是可组装编排; 可快速注册发布; 质量可监控;生命周期可管理的。这样SOA才能在整个IT范围内实现服务治理和优化,从而直接推动业务的优化。而从简单的服务重用框架到SOA演进的过程中,ESB就是其中最重要的催化剂之一。”作为国内中间件领域的后起之秀,中和威公司在2005年发布了其最新的ESB产品,该公司的总经理王志伟说:“SOA是一种架构上的创新,但其中的技术并没有创新,ESB明确了中间件的细分层次。”无论SOA的理念有多么吸引人,终究不能纸上谈兵,ESB的成熟让SOA有了一个可以落地的依托。竖井之惑尽管软件厂商对ESB表现出很强的关注,并投入了大量的力量,在对ESB的作用并非只有一种声音。有一些人将ESB视为过时的EAI—感到它们藐视SOA 的开放本质。在今年InfoWorld的一期报道中,介绍了Burton Group分析师Anne Thomas Manes的观点。她说:“EAI与SOA完全不同。EAI是为了在业务流程竖井上架一座桥梁,而SOA是为了推倒这些竖井。”她对使用ESB配置服务或将细粒度的服务编排为可广泛访问的粗颗粒的服务没有疑问。但她十分不满地批评总线作为连接所有服务网关的概念,尤其当转换到ESB消息传输和从ESB消息传输转换造成额外的开销时。一种替代ESB方式的选择是使用XML专用设备(也即所谓的网关)来传送消息、处理转换和映射,以及代理服务,使它们可以被有效地管理和保护。记者就这一对ESB的质疑询问了几个厂家的专家。甲骨文公司大中华区SOA技术推广经理周有衡说:“如果在纯粹的SOA世界里,每一个应用都通过BPM (业务流程管理)编排来实现,流程之间也需要传输,系统内也存在着数据交换的需要,中间状态也需要保存,如果系统内有交互的需要,就应该有总线,只不过这个总线可以是网络的,而不是单一的,在现实的应用环境中,总线更是不可少的。”陆飞舟认为:即使企业完全按照SOA的理念划分模块,但以后出现了新业务也会产生连接与交换的问题,而且企业外部的系统如果没有实现SOA,那么跨企业的系统之间仍然需要总线来连接。Burton Group分析师Anne Thomas Manes的看法其实是把ESB与EAI的技术机制混为一谈。东方通公司首席软件架构师、SOA-RA-TF主席朱律玮告诉记者:“EAI最早的技术机制是点对点的集成,而后来更成熟和被业界所接受的是Hub-Broker机制,即EAI 软件创建了一个交换中心,用于转换不同应用程序间的数据和消息。EAI 交换中心使用这些适配程序将所有进入数据的格式重新转换为一种 EAI 交换中心内部和外部适配程序都可以理解的通用格式,并将其称为规范格式。”在Hub-Broker机制之下的中心总线确实有可能成为系统的瓶颈,并造成额外的系统开销,或者用户必须购买更强大的硬件设备来保证总线的效率。但在ESB的天空下,EAI的Hub-Broker机制已经烟消云散,代之以更灵活、轻便的结构。朱律玮说:“ESB的总线方式可以是多样的。例如,总线可以是一个网络,而不是一个中心Hub,甚至还可以直接通过点对点的方式。多样的方式是为了减少总线的压力,具体的形式可以很灵活。”刘汩春的看法更为直接,他说:“信息系统中竖井的存在是必然的,因为企业中本来就有着不同的部门,每个部门有不同的业务系统,竖井不一定是贬义的,竖井太多才会有问题,只要企业内和企业外有跨系统的应用存在,总线就有其生命力所在。”超越EAIESB在开放性上的进步,使其在EAI的基础上又进一步,在秉承EAI集成的理念之上,ESB能够做到面向SOA的集成。 王志伟说:“在SOA之下,ESB具有了透明化与标准化的特点。例如,今天你用了一家厂商的ESB产品,如果以后你觉得不好,还可以用其他厂商的ESB产品代替,而不会影响ESB上层应用和下层的数据库和操作系统。”刘汩春说:“如果具体的把ESB产品和传统EAI里面的消息总线类产品做个比较,两者差异就很大了,主要有三方面。第一,ESB以SOA面向业务的哲学为基础,所以它主要是通过配置来建立,而不是通过编程建立;第二,ESB必须有能力在不同的协议之间建立互通机制,包括传统的消息机制和Web服务接口;第三,除了消息(服务)代理方式外,ESB还必须为SOA服务治理提供服务的生命周期管理,而非简单的过滤、转发、路由。”陆飞舟说:“ESB 采用了轻量级的分布式体系结构。当必须将程序间的每次交互转换为规范格式时,集中式的交换中心才有意义。ESB(如 IONA Artix)可以将更多的处理逻辑分配到端点上。这与大型主机和现代的分布式系统体系结构间的区别相似。交换中心与大型主机一样,仍然可以用于某些需要它的体系结构中,但它们只是开发人员的一项选择,而不是供应商指定的要求。”陆飞舟说:“ESB采用了Web服务这样的开放标准,而EAI采用的是私有化集成方式,许多接口都是某厂商自己的技术,而且往往许多集成并不透明。”BEA公司的刘汩春认为:“ESB除了运营支撑系统作为服务提供者和消费者的中介提供服务交互、代理和路由功能外,还必须提供可扩展的服务编排、目录、元数据管理、生命周期管理、服务质量和级别控制等功能。通过这些功能,ESB帮助屏蔽各种服务生产者的差异,集中管理所有的服务消费行为。从而避免服务的大量蔓延,简化用户SOA环境的复杂性。”进化中的技术与产品从广义的角度而言,ESB最主要的技术与Web服务密不可分,如WSDL(Web服务描述语言)、UDDI(统一发现、描述和集成)和SOAP(简单对象访问协议),这方面的技术目前处于稳定的发展阶段,而有关WS*的发展正处于一个整合和渗透不稳定过程中。此外,还有一些相关的技术正在活跃起来,比如流程方面BPEL(业务流程执行语言); 安全方面SAML(安全断言标记语言)、XML处理的XQuery;服务组件模型SCA/SDO(服务组件架构/服务数据对象)与JBI(Java Business Integration)等。朱律玮告诉记者:“目前大部分的ESB技术规范还处于发展之中。例如服务的查找,在行业内是基本可行的,但在互联网上,由于语义的差异,服务的查找还很困难,WSDL规范了技术语义的描述,但关于商务语义的描述还没有正式的规范出台。目前比较火的SCA/SDO的版本还是0.9,没有正式发布。”刘汩春说:“ESB目前正处于快速发展的时期,随着ESB逐渐在实际项目中深入应用,用户对其提出更多的要求。比如,服务生命周期管理,就是指从服务发布、注册、使用、推广、效益统计、升级等;服务质量控制和服务级别保证;服务目录和元数据管理;异构适应性:跨越具有不同所有权的多种网络、多个协议以及多个管理域的真正意义上的总线。”刘汩春认为,ESB还必须解决用户对传统EAI的主要诟病,就是其客户化开发工作量问题。ESB必须提供给客户越来越多的在线配置功能,而非开发框架来适应业务变化,所以其工具的优化是促进应用的一个重要因素,也是一个发展趋势。目前,从厂商产品的划分来看,专门以ESB为主要产品线的中间件厂商的ESB产品覆盖面较广,他们一般认为自己的ESB产品可以帮助用户实现所有与SOA 有关的工作,其中也包括了BPM。有些厂商还把门户功能也加入其中。而原来提供SOA平台产品的软件厂商则认为ESB是SOA中的一部分,他们的ESB产品是其整个SOA平台软件中的一块,通常会把BPM作为另一个单独的产品,例如BEA、甲骨文、IBM、东方通等公司。王志伟谈到:“SOA影响力的扩大,让目前的中间件产品有了更细分的市场,最明显的就是产生业务流程管理和总线两个独立的市场,而在以前这两个部分都统称中间件。”无论是IBM,还是BEA、甲骨文等公司都在套件产品的同时,推出了单独的BPM产品和ESB产品,对于用户服务而言就有了更多的选择,因为这些产品可以与其他厂商的中间件产品相互搭配使用,中间件产品原来的功能也是集成的,ESB的成熟对原有套件型中间件产品市场产生了不小的冲击。王志伟说: “SOA带来了ESB与BPM等产品市场的细分,是一个重新洗牌的机会,但对于国内的中间件厂商而言,更需要完善主要产品的功能,还不可能与国外的平台厂商全面竞争,重点突破是目前能做的事。”朱律玮谈到:“东方通的ESB产品线不会追求大而全,实用是第一位的,对于里面的关键技术都做到最好,例如连接服务和流程服务是我们的重点,其他一些产品可能会寻找合作伙伴或开源产品。”ESB的应用由于目前厂商对ESB产品有不同的划分,导致ESB的应用范围也产生了不同,综合主要ESB的产品应用,可以概括为应用在消息层面的转换、数据集成、以及流程的集成和管理。从应用领域而言,ESB与EAI没有大的区别,但由于ESB是基于开放的Web服务而来,在通向SOA的道路上,ESB可以当仁不让地挑起大旗。例如政府部门之间的跨系统互联,企业之间的跨系统电子商务应用。周有衡说:“目前国内的用户还大多更关心例如数据整合、门户整合、应用集成这类的集成项目,从这些项目开始,SOA才得以导入。”SOA的岔路口实现SOA有两种途径,一种是在现有应用系统的基础上将需要复用的的模块进行SOA封装,另一种是将所有的应用系统按SOA重新设计和开发。前一种SOA 之路是平滑的渐进之路,更容易被多数的企业用户所接受,毕竟,许多早期开发的应用系统正在承担着关键业务运行的重任,容不得半点闪失。而后一种SOA之路则是彻底地“动大手术”,肯定会在短期内带来巨大的阵痛,做好了可以脱胎换骨,做不好可能伤筋动骨。站在SOA的岔路口,也许用户会感到有些为难。“目标是光明的,道路是曲折的,”这句话最能反映SOA实施策略的选择。信息化不是革命,而是促进业务发展 (至少在大部分情况下笔者这样认为),从这个角度而言,选择SOA的渐进之路是可以掌控的,但如果是一个新企业上全新的应用系统,那么不妨来个彻底的 SOA。ESB的兴起让SOA的渐进之路可以走得更开放和平稳,而ESB也代表了中间件产品本身的进化方向,中间件已经由广义的产品范畴向着细分的领域深入——应用服务器、ESB、BPM的分界逐渐清晰。尽管每个领域都在不断发展,但每个领域之间的关系变得更加透明、标准化。对于用户服务而言,分步实现SOA不是一句空话,因为在产品上已经有了可以实现的基础,用户可以根据自己的应用系统环境,由小到大、由局部到整体地去实施。那么,站在SOA的岔路口就不必心慌了。(end)

分布式SOA架构完全可以替代EAI,如果用户已经建立了EAI,可以将其纳入分布式SOA架构这个体系之内。宣传SOA的厂家非常之多,但是真正提出分布式SOA架构的并不多。在SOA被炒得火热的时候,IONA公司不失时机地开始推广分布式SOA的概念。IONA公司中国区总裁薛志勇回忆,2005年,IONA在内部讲SOA架构的时候,对企业服务总线(ESB)提出了一些自己的看法。IONA当时的解决方案很像是SOA网络,网络和总线的概念还是有所不同的。虽然公司高层曾考虑提出分布式SOA,并且顾问公司也建议这么做,但是最后的综合意见认为,市场已经习惯了ESB的叫法,所以还是沿用比较好。他说:“但是到今天,大家对SOA提出的问题越来越多,比如SOA如何保证服务质量?SOA如何保证服务安全性?SOA如何进行综合治理?IONA感觉到,市场已经作好准备,是提出分布式SOA基础架构这个理念的时候了。”SOA是分布的薛志勇认为,SOA与生俱来就应该是分布式的,因为组织和业务的价值链是分布的,SOA解决的就是分布式计算、分布式应用这样的需求。分布式就是没有中央的集线系统,分布式SOA是一种架构,不是一种简单的产品或者技术,分布式意味着必须不断应对市场的变化以及用户的要求。分布式的价值在于,它是帮助企业构建SOA的捷径,是通过IT系统实现企业业务变革的捷径,包括:降低运营成本,更好的投资回报,更快速响应业务变化的IT架构。现在宣传SOA的厂家非常之多,但是真正提出分布式SOA架构的并不多。因为很多大型软件厂商习惯了以紧耦合的方式提供SOA架构的主要功能,SOA紧紧地和他们的数据库、操作系统、服务器和存储绑定,这种紧耦合方式缺乏与其他系统的互操作性,初期需要大量的资金投入,往往会导致用户对某个厂商的依赖。紧耦合式SOA架构导致用户对采用SOA处于犹豫状态,因为在还未看到成功的希望时就需要大量的投资。分布式SOA基础架构可以帮助用户摆脱紧耦合的方式,以较少的投资开始SOA建设,用户只配置需要的功能,并根据需要以渐进的方式扩大整合的规模。分布式SOA可以在运行环境中动态配置,也就是说用户的业务无需中断。在分布式SOA基础架构里,具备今天SOA所涉及的全部元素。在这个架构里,为了使各种服务能够重用以前的或者是现在的各种应用,实现各种服务元素的共享,首先要把这些元素互联、互通,消除信息孤岛,不管是基于主机、CORBA还是基于Java,统一对其进行封装,就像原来不同的网络协议被TCP/IP封装一样。IONA的分布式SOA基础架构分为三层,最底层是对不同应用进行SOA封装,使其成为标准;第二层提供中间层服务;第三层是基于Eclipse的开发工具。取代EAI企业应用集成(EAI)曾经被认为是应用整合的好方法,而薛志勇的观点是,目前全球很难找出EAI成功的案例。这是因为,首先,EAI的投资比较大,而用户却无法确定到底能获得哪些收益;第二,EAI平台所使用的很多协议都是专有协议,是不标准的;第三,EAI平台承担了很多的任务。中间件要占用资源,数据转换要占用资源,业务流程的编制还要占用很多资源,这意味着对硬件平台提出了比较高的要求。分布式SOA架构完全可以替代EAI,如果用户已经建立了EAI,可以将其纳入分布式SOA架构这个体系之内,加上端点,加上封装,就可以进入SOA网络。以某省网通公司为例,如果对BSS、OSS和MSS系统进行EAI建设,投资是1500万。而如果采用分布式SOA架构,预计能够节省80%的投资。(end)

背景回顾 企业的组织结构和业务流程管理一直是企业CIO们面对企业信息化建设不能回避的问题,如何让系统更好的服务于业务,如何让系统更好的帮助实现业务水平提升?分析传统组织结构的划分割离了企业的整体目标、降低了应对迅速变化市场的能力,企业的价值只有通过流程实现,静态的组织结构不利于企业业务目标的顺利实现,因此,建立在业务流程需要上的灵活组织结构才是企业管理者应该处理的问题。同时,单纯业务流程而无组织结构的企业会出现管理混乱。两者相互依存,但CIO要认清改善企业发展环境的本质是流程而非结构。BPM是一种持续改进企业流程管控水平的活动,BPM套件中业务流程通常可由企业管理人员、业务分析人员创建,尽管实际上业务流程的定义创建需要BPM套件与底层IT系统进行集成并定义用户与流程之间的交互关系。企业CIO在面对简单的应用环境——设置和使用人员是同一群体时,可直接选择BPM套件实现业务流程的管控;但如果CIO面临的是BPM部署者和系统实际服务者是不同群体时,通常所见的非SOA架构的BPM套件就不能很好的解决这一问题。SOA的作用是简化BPM套件产品的处理机制、帮助IT组人员更好的维护服务的策略,同时SOA还能支持从BPM套件中获得对它所连接到的系统的更好可见度。这些优点得以发挥的前提是企业IT基本架构足够复杂,或者企业在使用BPM套件进行业务流程管理到一定阶段后希望对流程进行创新改造时。所以,通常我们建议计划使用BPM套件进行企业业务活动控制的企业,在选择BPM产品时,充分考虑自身所处的IT、业务环境,从BPM产品自身提供的连通性、及它与SOA的兼容性角度来选择适合企业的BPM。观点企业信息化建设应该重视业务流程管理,打破静态组织结构设置对业务发展的障碍,从业务流程管理抓起;CIO进行BPM产品选型应从IT环境、业务环境出发选择,而不应盲从SOA倡导的“BPM”。(end)

本文由9159.com发布于前端,转载请注明出处:CIO进行BPM产品选型应从IT环境、业务环境出发选择

关键词: