再谈SOA和ESB总线平台价值

标签: IT咨询 | 发表时间:2014-07-25 19:47 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
关于SOA的咨询实施方法论,SOA平台和云平台的融合,SOA咨询方法论和EA企业架构思想的融合在前面很多文章都有谈到。在多年的SOA咨询和实施中,经常遇到的一个问题就是SOA是不是已经过时了?而这个问题追溯本源还是客户没有真正理解SOA咨询方法论,SOA组件化架构带来的好处,而是把SOA或ESB理解为了一个简单的接口平台或数据交换平台,如果一开始的思维方式或规划就是错误或偏差的,那么最终效果自然大打折扣。

对于SOA平台带来的价值,从以下几个方面进行阐述:

首先是集成模式方面的,传统企业内部业务系统之间往往是通过点对点的网状集成模式,接口类型很多,数据库直接连接,存储过程,视图,JAVA API,文件接口等;同时接口本身没有相对严格的接口规范和设计契约。导致后续的接口管理和运维都相当复杂。在转成总线式集成后,所有接口转化为服务,直接接入到ESB总线上,服务遵循严格的规范规范和契约文档,以形成企业内应用集成架构的标准管控环境。

从这个意义上讲,部分人会有进一步的疑惑,即如果原来的业务系统间已经通过标准的Web Service服务进行集成,原来点对点模式也没有发现明显的问题,整个集成过程中也没有类似传统消息中间件的大量消息协议转换工作要做,那么为何还要接入到ESB服务总线而多一个中间步骤?对于这个问题主要分两方面阐述:

其一,原来点对点做服务的时候,往往每个服务都需要考虑日志记录,服务审计,服务的访问安全,传输安全和数据安全,服务的路由分发等一系列问题。而这些内容本质是可复用的,在ESB总线中可以统一接管,并通过灵活可配置的模式进行设置。既统一的SOA服务管控和治理的标准,也减轻了原生服务的设计开发工作量。

其二,ESB含了消息中间件的全部功能,正是有了异步消息处理机制后,可以实现业务系统间真正的松耦合架构,如果ESB平台全部集成的是同步服务,则很难算得上完整意义上的松耦合架构。这个是ESB总线另外一个强大的功能,但是我们在进行服务识别和服务设计的时候往往忽略。

其次,在复用层面,如果仅仅将SOA或ESB理解为一个集成平台,那么SOA平台本身的价值将大打折扣。SOA的核心思想一直在强调就是要找到可以复用的服务,这些服务满足离散,松耦合,无状态,粗粒度等特点,同时这些服务可以组装和编排,灵活满足业务变更的需要。

复用的难点在服务架构规划和服务识别上,当前很多做SOA咨询和实施的厂家基本来说都没有这个系统能力来做这个事情。这个不是简单的理论指导实践的事情,更像我上篇文章谈到的,是必须通过大量的SOA咨询和实施实践,再反向抽取出来的经验和方法论。而我们的SOA架构咨询优化能力就在于融合了EA企业架构,云平台,软件工程和组件化开发,IT管控和治理,BPM业务流程分析和业务建模多方面的知识总结出来的,实际可以操作落地的方法论和最佳实践。再简单点来说就是从端到端流程分析和建模入手,遵循业务驱动IT的核心思想,围绕业务流程,数据,应用,技术,集成核心维度,形成完整的服务架构规划和服务目录梳理。

SOA的实施最终要形成企业可复用的IT和服务资产库,这个是企业很重要的无形资产,在配合服务目录库和服务视图的可视化展示,真正让SOA的价值显性化出来。这个资产库积累的越成熟,那么我们后续做新建系统,功能模块或变更的工作量越小,越标准化。真正形成一个可持续发展的内部IT治理生态环境。

最后即SOA实施后灵活敏捷响应变化的能力,这种敏捷性主要体现在两个方面,一个方面是服务本身可复用而不需要重新进行大量的设计开发工作;其次是服务本身可以灵活的组合组装和编排,以满足一个完整的业务流程的需要。对于第二点对应到我们常说的BPEL和BPM工具环境层面,但是实际效果来看,理想化的BPM业务流程管理平台应用的并不好,同时大量的人工工作流引擎平台号称是BPM平台。这个实施不好的原因也从两方面分析:

其一,当前的很多套装BPM工具往往要求企业原来是白纸一张,即所有的思路和方法都完全按照我们BPM平台和工具的要求来做,这个对很多企业很难,毕竟很多企业原来已经建设和实施了大量的业务系统。如果要保留原来的,在单纯的服务层面容易整合和集成,但是到了BPM流程和完整功能层面,就很难做集成。同时BPM思想做出来的业务应用本身就是跨传统多个业务系统思想的,这种应用最终是体现在门户平台上,那么应用最终的管理和认责部门究竟是谁?这些都是很现实的问题。

其二,BPM要用好又包括两个方面的内容,首先是要有很深厚的业务流程规划和建模能力,这种人既要懂业务又要懂技术,类似BPMN2.0语言等都是衔接业务和技术两端的,业务和技术都懂你才能够建模出来。这比原来单纯的画业务流程图,梳理业务流程难的多,一般人都很难真正胜任;还有就是流程建模的内容最终是要通过调用底层ESB服务目录中的服务进行组装和编排,但是真正需要调服务的时候你才发现ESB上的服务很少或者原来实施的服务根本无法复用,实施一个BPM最终变成首先要协调大量的开发厂商,实施大量的服务封装和接入工作,而这些都是相当难以协调的,也导致理想化的BPM很难真正推广下去。

简单总结下,SOA在咨询和规划阶段的难点在于SOA服务的识别,SOA在实施阶段的难点是SOA集成商如何整体协调甲方和各个开发商资源,构建SOA治理和管控环境。前者的重点在要懂企业架构和信息化规划,懂业务;后者的重点在既要懂SOA治理和管控方法,又要有很强的项目群管理能力。

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [soa esb 总线] 推荐:

再谈SOA和ESB总线平台价值

- - 人月神话的BLOG
关于SOA的咨询实施方法论,SOA平台和云平台的融合,SOA咨询方法论和EA企业架构思想的融合在前面很多文章都有谈到. 在多年的SOA咨询和实施中,经常遇到的一个问题就是SOA是不是已经过时了. 而这个问题追溯本源还是客户没有真正理解SOA咨询方法论,SOA组件化架构带来的好处,而是把SOA或ESB理解为了一个简单的接口平台或数据交换平台,如果一开始的思维方式或规划就是错误或偏差的,那么最终效果自然大打折扣.

[SOA] Mule ESB Linux 部署

- - CSDN博客架构设计推荐文章
本文介绍如何在 Linux 上部署 Mule ESB. Mule 是一个以Java为核心的轻量级的消息框架和整合平台,基于EIP(Enterprise Integeration Patterns,由Hohpe和Woolf编写的一本书)而实现的. Mule的核心组件是UMO(Universal Message Objects,从Mule2.0开始UMO这一概念已经被组件Componse所代替),UMO实现整合逻辑.

集成ESB实现SOA

- - 企业架构 - ITeye博客
  服务消费者,服务提供者, 服务注册中心(UDDI模型). 由于UDDI模型过于复杂,而服务提供者与消费者点对点的进行协作依赖性大大增强,因此产生演变.    服务代理 -- ESB.    基于ESB总线,使得服务请求者统一入口,而ESB管理服务,使得耦合降低,由ESB来应对提供者提供的服务的改变而服务请求者不需要进行任何的修改.

[SOA] Mule ESB 3.x 入门(一)—— 消息流

- - CSDN博客架构设计推荐文章
关于Mule ESB,简单来说Mule接受一个消息,按照某种顺序处理这个消息,这样的处理可导致多种结果. 有时,Mule改变或变换消息返回到原来的消息来源(request-response). 或者,在其原有的基础上改变形式发送到一个或多个第三方(router, transfer). 而在其他一些情况下,如果消息没有达到的具体要求,Mule可以拒绝处理的消息validation, throttling).

谈ESB服务总线改进

- - 人月神话的BLOG
对于消息中间件部分进行单独剥离,即讲服务设计和ESB协议转换和适配部分同消息中间件分离,对于消息中间件部分初步考虑采用RabbitMQ或zeroMQ来实现,其中zeroMQ由于用c语言实现,相当来说更加轻量和高性能. 但是RabbitMQ本身更适合做一个企业级的消息系统,其在集群,持久化,高可用性和分布式可扩展性方面往往更加有优势.

ESB总线和能力开放平台

- - 人月神话的BLOG
上图是ESB企业服务总线和互联网Open API能力开放平台的一个简单对比. 对于在企业内部的服务集成和管控,由于需要面对企业内复杂的业务系统间集成和遗留系统适配,因此使用较多的仍然是ESB企业服务总线. 而对于互联网应用,更多考虑的是轻量和高性能,已经开发和接入的效率,当前使用较多的是类似Open API方式下的能力开放平台.

文章: Mule ESB 3.3与CloudHub

- - InfoQ cn
MuleSoft最近发布了企业服务总线(ESB)产品Mule ESB 3.3. 在新版本中,除了应用程序集成之外,Mule ESB还拥有了数据集成功能;从而为开发者提供了一个面向本地或云端应用的集成解决方案. 分享云计算在传统IDC、移动互联网、SaaS应用、PaaS平台等领域应用,阿里云开发者大会,免费报名中.

SOA资料学习

- - 人月神话的BLOG
从对象到组件,首先可以把对象理解为更细粒度东西,而组件是更加粗粒度的模块,对象更多关注技术,而组件应该更加关注业务. 前面我们谈过技术组件和业务组件,在SOA思想下业务组件化的思想就更加重要. 组件本身而言很简单,南向接口和北向接口,或者再有底座平台支撑. 接口通过服务方式来实现,组件通过OSGI等技术实现高度的解耦和可热插拔性.

SOA架构咨询

- - 人月神话的BLOG
对于SOA架构咨询,其核心还是在于组件化和服务化,然后才是服务管控和治理,基于服务化思想对传统软件开发生命周期过程的改进. SOA架构大家刚接触时候很容易将其理解为一种单纯的技术架构,或者更多的人仅仅是将SOA理解为service服务接口,这些都是对SOA方法论很大的误解. SOA咨询一个重点就是业务驱动IT,而非单纯的IT架构咨询,SOA咨询一般都会结合企业架构和云的思想,结合组件化架构和领域服务的思想,高层结合BPM端到端流程整合目标,并对这些内容进行有效的融合.

开源ESB-Talend产品研究

- - 人月神话的BLOG
对于ETL部分要注意,当前用的更多的是ELT,其最大的差别就在于首先是将源数据库中的数据抽取到目标数据库中,然后再在目标数据库中进行相应的数据映射和转换等操作,刚方法比传统的ELT在性能方面有明显的优势. 在Oracle ODI产品里面当前即用的ELT方式,在Talend产品里面可以看到这部分也是通过ELT方式来实现,但是在ESB产品里面可以看到,对于ELT方式的数据集成提供的相应组件并不多,要实现负责的数据转换和处理往往并不容易.