基于经验的SOA成功原则

标签: 经验 soa 成功 | 发表时间:2013-04-15 17:46 | 作者:
出处:http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

多年以来,我们对 SOA 原则这一主题以及什么会促进SOA成功,什么会阻碍SOA实施等内容都进行过很多相关的报道。从初期的狂热宣传,到大规模企业的实施、Web服务以及较近期REST带来的影响力。我们可以通过这7年来的文章,对SOA的演进进行追溯。然而,在此期间的成功案例却通常少之又少,据一些数据表明仅有 20%的SOA项目获得了成功。其中包括了 CISCOeBay等几个著名的成功案例。

InfoQ英文站编辑 Jean-Jacque Dubray不仅帮助我们追溯了SOA在那段岁月的发展,也分享了不少他的个人观点。他对SOA起到了积极的影响并基于SOA原则部署过很多成功的系统。通过基于这些经验背景的思考,Jean-Jacques(JJ)最近在 博客中发表了他所信奉的四条促进SOA成功的原则:

1. 服务接口应该与服务实现解耦

  1. 所有业务逻辑应该标准化
  2. 变更一个服务应该是非常容易的
    • 在服务消费者准备就绪之前,服务变更对消费者来说应该是不可见的
    • 当服务消费者准备就绪之后,服务变更应该是易于消费的
  1. 服务版本控制应该基于兼容性

JJ认为只要你在所有设计和开发阶段一贯地遵守这些原则,成功的机率将会大大提升。虽然这些原则相对来说比较容易理解,但遗憾的是他没有对所列举的这些原则进行更详细的阐述。对于“服务接口”,JJ补充道:

大部分人在SOA中遭遇了失败,因为他们认为服务是一种抽象,就好比OO中的“类”。但实际上服务接口是一种契约,通过它可以暴露和控制变更。[...]不要在你的服务边界(service boundaries)上耗费太多精力,应尽可能的将更多的精力花在构建最好的服务接口上(也就是指有效地管理变更)。

然而,JJ所做的工作还涉及到围绕SOA相关的其他一些领域,这些领域在过去的时间里也曾引起了很多人的关注。其中包括治理(governance),对此他建议道:

不要“过度治理”,治理应该保持最小化并且是基于短期内(3-6个月)的合乎情理的共识。而数据治理(Data Governance)则更为重要,因为你的信息模型发生的任何变更通常都会对服务接口造成影响。

松耦合通常作为成功SOA的核心组成部分而被人们广为称道,对于如何实现松耦合,JJ建议道:

对消费者交互环境的管理不涉及接口背后的业务逻辑实现。在接口消费者中,不出现重复的涉及对各类记录系统状态管理的业务逻辑。

服务复用通常是SOA中另一个被认为非常重要,然而也很难实现的领域。 早在2009年的时候,我们就援引过Burton的Richard Watson曾经说过的一段话:

一个服务可能永远不会被复用,但是我们仍然可以通过其他方式来创造价值:通过适应性和低成本的维护来减少冗余;通过对既定策略的贯彻执行来提升安全性和依从性,以上列举了一些我们期望得到的其他成果。而过于专注在复用上将会蒙蔽我们的双眼,从而导致我们无法看到这些其他的成果。

而JJ也赞同这一点:

没有人会指望今天构建的一个服务会在从现在开始的三年内被持续的新消费者们不断消费,这是荒唐的想法。如果你想以这种方式进行复用,那么你迟早会失败并最后得出一个例如“SOA不起作用了”这样的愚蠢结论。对于SOA(在现实世界中也是如此)的复用,它是以另外一种方式进行的:并不是一个新的消费者复用一个老的服务;几乎都是一个服务的新版本(变更以支持新消费者)在不打断老消费者的情况下被消费者复用。

事实上在2009年的文章中,JJ曾对此有过以下评论:

大多数的人仍然无法理解的是:在SOA中的“复用”并不是人们通常听到的“复用”,对它们的理解是不一样的。在SOA中的复用是向前复用(forward reuse),而例如我今天早上听到的复用则是向上复用(upward reuse)。在SOA中,复用意味着为新消费者构建的服务新版本并不会打断现有的老消费者。对于认为某人能在今天设计出一个服务并且可以在两年内被一直“复用”这种想法,很大程度上来说是个幻想。在SOA中,较老的消费者可以“复用”那些为最新消费者而创建的服务新版本。

正如最初所提到的,所有这些原则和思想都受到了JJ在这个领域中多年经验的影响。其他人对于这些问题又是怎么认为的呢?你愿意也来分享一下你的经验吗?

查看原文链接http://www.infoq.com/news/2013/02/succeed-soa

您可能也会喜欢

相关 [经验 soa 成功] 推荐:

基于经验的SOA成功原则

- - InfoQ cn
多年以来,我们对 SOA 原则这一主题以及什么会促进SOA成功,什么会阻碍SOA实施等内容都进行过很多相关的报道. 从初期的狂热宣传,到大规模企业的实施、Web服务以及较近期REST带来的影响力. 我们可以通过这7年来的文章,对SOA的演进进行追溯. 然而,在此期间的成功案例却通常少之又少,据一些数据表明仅有 20%的SOA项目获得了成功.

SOA资料学习

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

SOA架构咨询

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

从流水程序到SOA

- Allen - 阿朱=行业趋势+开发管理+架构
咱就从函数代码开始谈起,更史前的Goto和汇编代码咱就不谈了. 函数和变量写多了,自然也就发现有些函数和变量互相粘在一起很高耦合,而与其它的一些却没多达关系,于是为了显性化让其他的开发人员知道哪些函数和变量确实关联性很紧密,于是创造了类. 面向对象在80年代的国外代码开发界颇为流行. 但接口思想的风潮在90年代刮起了.

eBay开源SOA-Turmeric架构

- - 人月神话的BLOG
参考: https://www.ebayopensource.org/wiki/display/TURMERICDOC/Turmeric+Documentation+Overview. Turmeric是一个综合的、由策略驱动的SOA平台,提供了对SOA服务及其消费者的开发、部署、保护、运行和监控等方面的支持.

SOA面向服务架构

- - 人月神话的BLOG
今年在这点上谈的比较多,也逐步开始落地实施,将SOA咨询和实施方法论从系统间真正的引入到系统内,将面向对象的需求分析方法和SOA思想进一步融合,从业务建模到系统用例建模,从流程分析到服务识别和分析,从业务组件化到系统模块化,这些工作都逐步开始落地实施. 这样做的好处就是进一步的体现SOA可复用组件的价值,真正的做到业务组件化和组件能力化.

[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实施收益分析

- - 人月神话的BLOG
远行科技自2007年开始即参加了中国移动集团SOA接口平台的建设和实施工作,在SOA规划咨询,建设实施方面有丰富的实践经验积累. 对于SOA实施收益,先以某客户的一个真正业务背景进行分析:. 业务场景:我们现在的工程项目管理,其规划,立项和工程实施计划在项目管理相关系统;工程物资采购在采购管理系统;审批在 OA系统,财务的信息又在ERP核心系统.

数据交换和SOA服务共享

- - 人月神话的BLOG
数据本身只是一种资源,而服务是一种能力;数据仅限于各种结构化和非结构化的数据资源,对于数据资源提供的能力可以使一种数据服务,而数据资源+业务规则形成的某种业务能力也可以作为一种服务提供,也就是说各种技术,数据,业务,平台,流程能力都可以做为服务提供. 交换本质是资源会从一个系统通过传输的方式进入到多个系统,资源在多个系统中形成多种拷贝.