十年 SOA：当前的位置和未来的方向

很少有人记得微软 BizTalk 服务器曾经是 SOAP、WSDL 和 UDDI 发展的幕后主要推动者之一——它们主要作为一种跟 ebXML 标准竞争的 B2B 技术，“互操作性”一词在当时还未成为时髦用语。那个时候的许多专家和分析师都草率地得出结论：

Web 服务是一种新型模型，其本质是基于 Web 的对象的面向对象编程。2000 年 4 月，SOAP1.1 规范朝着这个方向迈出了一步，规范中描述了如何将 XML 格式的消息用于请求和响应。在整个拼图中，UDDI 负责让业务可以发现这些服务。Web 服务描述语言（WSDL）则是描述服务和服务提供者的 XML 词汇。因此 [……]：Web 服务 = SOAP + UDDI + WSDL

十年过去了，我们仍然在纠结于服务或者基于Web 的对象的含义，甚至不去考虑 SOA 曾经对信息系统建设是多么的重要。

2009 年，InfoQ 召开了一次虚拟研讨会，与会者都是在这十个年头中大多数时间内体验和实施过 SOA 的企业架构师，我们期望能借这次会议更好地理解 SOA 对于 IT 的意义。

会议的参加者包括 Jeff Andres、来自 MomentumSI 的 Eric Ballou、来自 Saber 的 Dave Hollander 和来自 Carlson Wagonlit Travel 的 William El Kaim。

InfoQ：我们已经花了 10 年来做 SOA。对此，您作何感想？未来十年，SOA 将会是个什么样子？

Eric：哇，我简直无法相信我们从事这个行当已经 10 年了，但这是千真万确。大体来讲，让我感到震惊的是，在厂商和大牛们在花了这么多精 力去教育人们之后，还有这么多的公司认为只要写个 Web 服务就是 SOA 了。那些尚未踏上 SOA 之路的企业将继续为了提升自己的成熟度而奋斗，由于缺乏坚实 的基础，他们的业务和信息服务团队将付出极大的努力：相对于他们那些已经走上 SOA 之路并且已经开窍的竞争对手而言，他们面临的是一个非常高的市场技术入 口。所幸，如 Gartner 指出的，SOA 正进入“启蒙的斜坡”。

SOA 的未来将会是：随着厂商将焦点转移到以业务 / 用户为中心的服务和产品上，它开始被打上新方法论和实践的标签。这些标签，诸如 Web3.0、业务驱动 架构和给最终用户授权的用户中心（User Centricity），就是这个方向上的一个极为隐蔽的转变，又或象 Yahoo 给它贴上的：Y!ou。信息服务必须很到位（参见服务架构），才能使授权 到位，SOA/BPM/ 云只是这个方向上的一小步。

Jeff：看看 SOA，其本质非常类似于 80 年代就已经完成的功能设计和构造。回顾从当时到现在我们已经了解的事实，然后再对未来进行预 测，会发现“事件”驱动架构、基于流程的架构这些领域也跟着成熟起来，同时 SOA 也变得更轻量级——因为新语言、介质和设备要求它这样。那么，为什么我会 说是这些领域，以及如何到达这些领域呢？让我们先回过头来了解 SOA 今天所处的位置，以及它可能的方向和进入的领域。在我看来，SOA 目前并没有触及实时 和事件驱动领域，因此，“事件驱动”的语言和构造（中断、分支、汇合）以及类似需求就需要被考虑。这可能会引来争论，即这到底是基于语言的，还是它就是架 构。这暂且不管。其次，SOA 已经明确成为一个招牌，许多大厂商已经烙上它的印记（如 SAP）。然而，他们还遗漏了“流程”的交付。因此，可以肯定，在未 来几年，流程和服务的联姻及融合都需要做得更好。最后，技术总在变化。若干年前，象诸如 iPhones、iPods、Smartphones、 BookReaders 这样的设备都未曾出现。要是我们想在它们身上构建和交付功能，SOA 也需要变得更轻，成为精简版（SOA-lite）！就像敏捷改 变了瀑布或 OOP 的开发实践，SOA 需要针对新浮现的技术进行改变。

William：SOA 将真正的把数据和业务流程当作服务来关注。在今后几年中，SaaS 供应商将关注自动化和可配置的业务流程，这些流程 将导致产生随需应变的世界，驱动企业的业务价值链。SOA 还将用来让诸如安全（认证、联邦、身份认证），日志、监测、分析等这样的 IT 服务变得灵活和可持 续。门户将成为面向服务企业的入口点。

Dave: 谈到 SOA 的未来，这让我想起了一个形容词：淹没的。SOA 将会像客户端 - 服务器曾经的情形一样，无处不在。新的架构方法会引人注目，但更有可能的是，它们都将构建在 SOA 的原则之上。

InfoQ：在 2004 年左右，SOA 治理成了 SOA 一个主要组成部分，您认为它是促进还是阻碍了 SOA？

Jeff：绝对有帮助！但我们要看到任何事物总存在着两面性。首先，治理（取决于它的力度）已经为服务的创建和管理以及生命周期管理提供了 某种控制级别和结构。要是没有治理，混乱就会到处肆虐，我们只会得到大量“闲置（即无法重用）的”服务。它也让开发者、管理层和其他人明白，监督很重要。 在事物的另一面，它也暗示，由于官僚主义，创新会被扼杀。再次强调，这完全取决于治理水平以及它对组织的意义。我相信，赞同治理有积极影响的比率会是 65/35。

William: SOA 管理当然阻碍了 SOA。治理不是仅靠安装个工具或是创建一打 Web 服务就能搞定的。你需要管理组织变更、培训人 员、改变人们的思想。根据公司业务、技术能力和成熟度，差距会很大。然而，值得注意的是，SOA 治理的开源工具已经从纯粹的一个存储库 / 注册库的单独应 用，演变成了一个面向工作流的平台……治理在未来会变得越来越重要，因为对服务使用、结算、访问和集成的控制需要会变得越来越重要。

Eric: 随着企业试图实现 SOA 愿景，他们很快会发现一两的预防要比一斤的治疗好得多。治理正是我们保证工作成熟的手段。SOA 治理的 学习曲线最终会克服人们所说的障碍，“哦，我还没有这么做过，也没有大师可供参考”。因为任何改变，为了支持 SOA 而对公司治理和软件开发生命周期进行修 改都不会那么容易进行——即使公司有老练的 SOA 专家帮助安全地走过这个阶段。这种组织学习曲线对于不怎么能适应变化的公司会伤害 SOA 的成果，但是那些 坚持下来的公司会发现它对 SOA 成果还是有价值的。总的说来，正确地运用 SOA 治理会对 SOA 有帮助，因为它促进了业务的可见性以及项目成果 ROI 的可追 溯性。我曾经一同工作过的很多架构师已经被治理授权，真正贴近业务，并让开发团队的生活变得更加舒心。

Dave：SOA 治理肯定对 SOA 有帮助。优秀的治理不是 SOA 治理，而是将 SOA 治理包含到现有和可能需要增强的治理进程。

InfoQ：服务治理常被吹捧成让业务 /IT 更好对齐的一种方法。您如何看待服务治理中 **** 业务的参与？

Jeff：因为刚通过 ITIL 考试，我会对这一概念和服务支持保持警觉，因为从 IT 角度看，它会被滥用和过度利用。然而，至于 SOA 服务治 理，我相信在开发对彼此都有价值的组件时，它为业务和 IT“合二为一”提供了机会。还没有其他情况（好吧，业务流程中可能有）能让 IT 和业务一起合作，而 双方彼此互利。通常，IT 去找业务的目的只是为了理解需求，接着他们就会开始试验，开发解决方案。在服务治理中，他们实际有机会在一个开放的论坛中从对方 的角度进行讨论，抛开“老子天下第一”的念头。这时，业务可以了解一些 IT 的运作，而 IT 则赢得了业务的援助，以及对他们目前所从事的事情的支持。

William：业务不会对服务治理感兴趣，除非你能证明它能给公司带来效益或能加快推向市场的时间。截至到今天，对齐并不存在。业务的快 速发展和它的需求让 IT 现在就跟它对齐不太可能。当前的 IT 流程和技术还不够成熟。这就是我们为什么要就地改变 IT 范式的原因。业务制定的规范应该被重 用，以业务的形式创建出软件。这是模式驱动的方式。新语言和平台也能进一步的加快这一进程。我们唯一不能加快的变量就是人。

Eric：我在上一个问题中曾经提到，SOA 治理的工作真的能让架构师更接近业务。这种亲密性为业务所有者在决策制订过程中培育出了一种更 好的控制感，通过架构师交付实际所需要的一种更好的能力。治理成功的手段是在业务或架构师分别代表自己提出新想法和新需求时，将两者在一系列快速“自然 的”公司运营步骤中拉到一起，然后将验证 / 审批作为交付的保证。尽管这听起来很简单并且‘容易’，但是要实现这样的沟通和流程级别，要求公司大量的自我评 价和批判指导。我还没有在市面上看到有多少成熟度提供在该领域下实做的指导，因此，业务所有者仍然会因为发现他们所察觉的应该属于信息服务的内部事务而感 到沮丧。

Dave：这种参与至关重要，另一方面，服务和 SOA 仍会继续节省成本和提高效率。当然，在我们跟业务打交道时，还是不要明确点出服务和 SOA，但是它们必须驱动系统提供价值的方式。

InfoQ：业界有很多关于“重用”的争论，您认为重用在行业内取得成功了么？

Jeff：“圣杯”是重用。怎样才能让构建和制造项目更有效和高效呢？当技术人员能够通过 SOA 的手段在此基础上交付的时候，价值是巨大 的！然而，重用通常不会马上被发现，在部署多年后才能开始看到结果。此外，要让此发生还得要有好的“架构师”和“工程师”。顶级管理层时常期望在 18 月内 就看到结果，不幸的是结果通常不会那么快就自动现身。服务治理能帮点忙，但这需要好的领导，以及从组织（文化）到真正“采用”SOA 的大宗买进。前面说 过，倘若 SOA 和重用只是耍耍嘴皮子，那么它们注定要失败。不管治理是否有帮助，因为它不会在一个“积极的”状态下进行考虑或具有价值提供能力。

William: 在讨论重用时，说明其困难程度的最好例子就是 Portlet。在 Portal 中，我们要构建多个 Portlet。但是大 多数 Portlet 在 Portal 首页中只会使用一次。这里，并未发生重用，但是 Portlet 必须具有可移植性。我想说的是，重用越来越不重要了。真正 重要的是在企业中创建可持续的资产。这些资产是公司的知识产权，具有内在价值。

Eric：由于不止一个，你需要澄清这里讨论的是哪个“重用”。总的来讲——每个企业都关注用尽可能有效的方式来使用他们的资源。然而，由 于业务和 IT 都不清楚他们拥有的哪些属于 IT 资产，这严重阻碍公司最大化重用的好处，使重用的成功故事成为空白。服务治理已经强调了可见性的需求，并造就 了了解在用 IT 资产、使用人、有意使用者，以及未来使用存在的障碍等需求。在回答可见性问题时，存在有很多风格和技术使用，但是成功故事已经大大增加了， 不仅仅是重用，而且是以一种可理解、可度量的方式将资产度量指标反映到业务上。

Dave：我不确定。我们避免将重用作为一个主要卖点，因为它太难衡量和量化了。

InfoQ：您能否介绍一下 SOA 或者服务治理组织成功的元素？

Jeff：拥抱这一变化的上层领导的大力支持和认可。愿意抓住这次机会进入该领域成为变革推动者的工作人员！开发流程的修改，类似面向对象 开发 VS 瀑布模型：服务设计上的前期工作对于有意义并有机会在将来重用的服务的界定和构架至关重要。随着时间日渐“成熟”的治理模型；设置一个它要达到的认识水 平，完成之后再改变，然后再来执行。不要一开始就搞专制，否则你不会有任何追随者。

William：我们需要：

• 关于现有服务的一个清晰服务分类，并将其在注册库中实现，以始终提供准确的服务目录；
• 服务的任何配置都通过保存在具体存储库中的元数据来完成；
• 管理服务全生命周期（设计时、运行时、终结）和发布；
• 每个服务都有针对其消费者的 SLA 契约，并有工具可以对其进行度量；
• 公司内有一个集成能力中心来管理 SOA，并有相关的专门预算。

Eric：我在公司中看到的成功元素首先是拥有灵活思维和能够适应流程变化的人。他们大多数都拥有技术，这让他们能够自动治理流程并能得到 IT 资产的联合视图——不 仅限于 SOA 资产，而是整个企业的视图——人、流程和技术 / 服务。最大的成功因素——具备强大业务本领以及与最高层及高级经理有政治关系的拥护者。

Dave：我会建议将它包含到其他 IT 和开发治理中，并且建立一套统一的标准来进行考量。

InfoQ：要是您能改变 SOA 中一个事物，您会选择哪一个？

Jeff：标准……我个人没有太密切关注过这个领域，但是我能确认我们需要将采用过程变得简单。此外，这跟其他领域没什么不同，我们需要建 立一个路线图，明确指出我们要前进的方向。不幸的是，我认为 SOA 标准是“老鼠洞”。对不起…如果我参与了委员会，可能我不会这么想——不幸的是，我不 是，因此我还是会这么看。

技术也是一个它可以发挥作用的领域。没人会喜欢在微软和 Java 之间来一场战争的想法。因而，折磨世界的不是观点统一而是分歧。尽管我知道有好几种方法能让它们一起工作，但没有必要将世界统一成一个 SOA。

William：我会说服大家采用契约优先的方法并定义描述服务 SLA 的唯一标准。我很想有一个 Web 服务管理平台的开源实现。

Eri：我们能否更早地把它创造出来？;) 说实话，要是能改变 SOA 中的一个事物，我会选择一开始就击中靶心。企业承受的任何改变都会导致 公司的成本。尽管 SOA 现在 10 岁了，对于大多数信息服务和企业而言，他们仍然将 SOA 看成开销而不是节约。MomentumSI 已经反复给客户证明了这 一点。

Dave: 我会不惜代价阻止市场炒作和夸大其词对 SOA 品牌的消弱。

你已经看到的，即便 10 年过后，SOA 的某些方法和预期收益方面还是很容易产生不同观点。你对这些问题的答案又是什么呢？

查看英文原文： A Decade of SOA: Where are we, Where are we Going?

感谢马国耀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。