2011 SOA 虚拟研讨会

SOA 一度被认为是游戏规则改变者，它可以变革软件开发和交付流程、统一业务和 IT、显著降低软件维护成本。

SOA 曾经（并且依旧）是软件供应商的一座金矿。这些供应商们异常热衷于定义名目繁多却又常常矛盾的支持标准、热衷于交付所谓的能够简化 SOA 系统的设计和实现的软件产品，但实际上却常常因为把这些产品定义为 SOA 而带来更多困惑。

很多公司提供软件服务，一些已经取得了巨大成绩，另一些却以失败告终。SOA 曾经居于分析师报告的首位，然后又被宣布已死，后来又以不同的名字——如 REST、云计算等——而重生。讨论 SOA 的各个方面的著作和专题文章也有上千本，涵盖内容从架构设计到具体实现细节。

然而，除此之外，SOA 从业者中也存在着很多分歧。从如何成功地创建 SOA 解决方案，到甚至连 SOA 到底是什么、必要的 SOA 组件有哪些，看法均有差异。

在本次虚拟研讨会上，InfoQ 与 5 位 SOA 专家就 SOA 的重大意义、它和其他架构风格的关系、成功实施 SOA 解决方案的最佳技术和方案以及 SOA 的未来等进行了深入探讨。

回答我们问题的 5 位专家们分别是：

1. Jim Webber——首席科学家，《Developing Enterprise Web Services - An Architect’s Guide》一书的作者
2. Claus T Jensen——IBM SOA-BPM-EA 技术战略部的首席架构师
3. Stefan Tilkov——REST 热衷者、InfoQ SOA 社区的前首席编辑
4. Steve Jones——凯捷（Capgemini）基础数据管理的全球主管
5. Mike Rosen——Cutter Consortium 的企业架构主管

给他们提出了以下几个问题：

• 问题 1：当今的 SOA 包含着很多的含义：请用一句话给 SOA 下个定义？可否比较一下 SOA 与“整合”、ROA 以及 EDA 的区别？
• 问题 2：关于 SOA 和 BPM 之间的关系，有很多的讨论，有观点认为它们其实是同一种东西，也有人认为有必要区别对待。您的观点是什么？
• 问题 3：分析师们的新宠是云计算。它与 SOA 之间有什么关系？与之关联的是大数据，那么它又是怎样和 SOA 关联起来的呢？
• 问题 4：SOA 光辉不再的一个原因是项目的失败。您认为 SOA 项目要想取得成功最需要做的事情是什么？
• 问题 5：可否预测一下 SOA 2.0？它会是怎样的呢？

问题1：当今的SOA 包含着很多的含义：请用一句话给SOA 下个定义？可否比较一下SOA 与“整合”、ROA 以及EDA 的区别？

Mike Rosen：SOA 是一种用于寻找解决方案的架构性方法。其中，服务是分析、设计、实现、部署和运维的主要概念。要想从 SOA 中获得最大益处，最好是在跨组织的范围内完成。服务设计必须能体现业务和信息双方面的需求。

虽然 SOA 是实现整合的一种方法，而且如果做得得当，通常还是一个更为灵活的方法，而整合则只是 SOA 的一个方面而已。在以前，只是在一个有限的、企业级一致性作为次要考虑因素的范围内做整合的。SOA 方法通常使用整合技术对资源进行转换并使其成为企业范围内可用的服务。

ROA 和 EDA 是另一种架构风格，“资源”和“事件”分别是其主要的设计驱动力。这些架构风格在系统灵活性和优化上有各自不同的总体目标。它们既不是 SOA 的子集也不是 SOA 的超集，和 SOA 也并不兼容。可以通过混合使用它们，取各自的长处来构建有效的企业解决方案。当然，这超出了今天讨论的范围。

Steve Jones：SOA 依旧是过去的 SOA 所指的意思，也就是通过服务、功能及服务交互来思考架构问题。SOA 用于架构就像 OO 用于开发，它是一种从业务角度来思考整个 IT 的新方法，也使得 SOA 强大，但这不是某种特定的交付方法。所以，在面向服务的方法中用架构的逻辑去思考，就可以选择部分内容是否用面向资源或者 EDA 来实现，这两种方法是有关“如何”交付的，而不是关于提供一种一致的各种不同的技术方法都可以混合起来的精神框架。

在 SOA 中唯一改变了的事情是供应商把各种时髦词汇汇集到同一产品上，所以才会导致人们对于“到底什么是 SOA”如此之困惑了。

Stefan Tilkov：SOA 指任何最符合使用这一术语的东西 。说真的，我已经彻底放弃了去定义它，因为无论你给它什么样的定义，都不会找到一个一致认可的定义，最终的结果无非是浪费时间。已经说过，我更愿意关注高层次的方面，至少，这些方面似乎还能被主要的少数人所认可：即，对企业 IT 的整体分析；无需了解服务的实现细节，即可通过网络消费服务；在总体系统蓝图中应用全面的架构原则；整合不是一场梦魇，也不是事后措施，相反它是关键，所以整合变成了默认的事情。我是一个 REST 热心追捧者，总是把它作为达成目标的最适用的架构风格来使用，但是我承认并不是每一个人都同意这一点——他们并不知道 REST 有哪些更好的地方:-)。

我不喜欢“ROA”这个词；“REST”已经相当好而且足够抽象了，完全符合我的口味，没有必要再去添加什么东西了（我使用“RESTful HTTP”来指 Web 架构为这种风格的一个实例）。在我处理过的任意一个架构中，事件几乎都是其中一部分，但我也见过那种只使用事件，或事件扮演核心角色的架构。所以，我不确定作为以事件本身为核心概念的事件驱动的架构是否值得去研究。再提一下 REST，我的确见过一些有趣的架构选择，它使用以 Feed 为中心的事件通知机制——轮询经常是一种完善的，最具扩展性的解决方案。

Jim Webber: SOA 是设计和交付那些模拟业务的系统的系统（Systems-of-Systems）的方法。整合是把所有的东西联合到一起，而 SOA 提供给它依存的环境。单独的整合任务价值很小——整合本身不是最终目的——尽管系统的系统经常需要使用整合。我得补充一点，单纯的“整合项目”等于臭屁。

ROA 就是胡扯，一个正常思维的人是不可能只用资源去做架构的（除非他们的确在使用 RPC 并使它听起来不那么可怕）。相反，SOA 能给那些基于 Web 架构设计系统的人带来更广泛的指导。关键是 SOA 提供了模板——封装了业务需求的服务——而 Web 则提供了广泛而健壮的基础设施以支持这些服务之间的业务协议。

EDA 则被当作一种特殊的活动，它包括低延时总线，提供复杂的、近似实时事件处理能力。事实上，这样的设计原则同样适用于人为的延时——所有系统都是在响应事件，而 EDA 则是以低延时的方式去做。

Claus T Jensen：我给 SOA 下的一句话整体定义是：SOA 是一种架构风格、一种思考模式，它促使业务和 IT 事件的协作与对齐，以服务和流程的交互为中心。整合当然是面向服务的架构应当考虑的一部分，但它也不是唯一的。很多 SOA 项目都曾经是由 IT 驱动的，而且重点放在应用之间上；不过，这样做的价值不大，仅通过整合不实现业务对齐，也无法实现有效的企业应用集。面向服务的架构可以是事件驱动的，也可以不是——我个人并不认为 EDA 是不同的架构风格，而把它看做面向服务的一个方面。

返回页顶

问题2：关于SOA 和BPM 之间的关系，有很多的讨论，有观点认为它们其实是同一种东西，也有人认为有必要区别对待。您的观点是什么？

Mike Rosen：BPM 是编排模块化业务功能和信息以支持业务流程的一种方法。其中的“M”表示管理。所以，编排只是 BPM 诸多方面中的一个。SOA 是以业务服务的形式提供模块化功能的一种技术。业务服务必须通过编排更小的域和效用服务来实现，但是在 SOA 中重点通常是封装编排，而在 BPM 中，重点是暴露、管理、监控和优化流程。没有 SOA 的 BPM 容易产生竖井式的解决方案。而没有 BPM 的 SOA 则会创建没有业务消费者的服务。二者结合起来才提供完整的解决方案。

Steve Jones：我之前说过 BPM 搞砸了 SOA（查看此链接），而我现在依旧这么认为。实际上，SOA 成就了优秀的BPM，而BPM 是实现业务服务能力的一个很好的方法。我的意思是，如果你从服务开始思考，然后选择在其合适的地方使用BPM，并且用一致的方式将它和非BPM 方法（如ROA、EDA、包开发等）结合起来。若以BPM 开始的话，则容易导致许多粒度过细的只包含单一操作的服务，从架构健壮性的角度来说，这并不是一件好事。因此，关键要首先理解你的服务和能力，然后选择使用BPM 实现能力，这将带给你好的SOA 和好的BPM。

Stefan Tilkov：我认为 BPM 是一个独立的概念。你可以只做 SOA，也可以只做 BPM，或者两个都做。我在 SOA 核心中没有看到什么流程，即使我明白 BPM 供应商也许希望看到不同的一面。有时候，硬编码过程是相当不错的，有时候则不然；即使这样，典型的 BPM 解决方案从来也不是唯一的选择。

Jim Webber：服务应当实现业务协议，否则就不算好服务。编排各服务之间的交互可看作 BPM，但是这个词汇已经被烙上太多产品的印记了，所以我认为它已经名不符实了。作为一名 Web 粉丝，我希望看到在 Web 上（你的组织里是大 Web 还是小 Web 不重要）应用超媒体传输业务协议。所以，我认为服务编排是生机勃勃的，但我不想把它和 BPM 混在一起。

Claus T Jensen：BPM 是一门专注于运营优化的学问，而 SOA 是一种专注业务与 IT 结合的架构风格。SOA 中蕴含的思想是人们应当关注服务和流程的交互，换句话说，SOA 是关心 BPM 的组织所采用的一种非常自然的架构风格。前面已经说过，即便没有 SOA，BPM 一样有价值，只不过你将面临一种“服务无序蔓延”的境况。但是，老实说，BPM 是 SOA 战略中非常天然的组件之一，因为它为架构自身提供了内建的业务环境以及立竿见影的业务运营的益处。

返回页顶

问题3：分析师们的新宠是云计算。它与SOA 之间有什么关系吗？与之关联的是大数据，那么它又是怎样和SOA 关联起来的呢？

Mike Rosen：云是关于提供服务的，不管它是基础设施及服务、平台即服务还是软件即服务。所以，SOA 和云共享通用的基础。云隐含意味着能够用于构建好 SOA 服务的设计原则也应该应用到云服务上，比如：良好定义的接口、松散耦合、适当的分解、通用语义等。不幸的是，和很多 SOA 设计师一样，很多的云服务设计师也没有理解这一点。所以，买家要注意了，你要确保你得到的服务是很好地设计、实现和运营的。

一个 SOA 解决方案应当能整合基于云端服务和本地服务，而且在云架构上提供自己的服务也应当很容易。和其他事情一样，实现这一点，有好的方法也有不好的方法，有些实现会带来安全、性能、可靠性和责任性等方面的问题。这是实现的失败，而不是云或 SOA 的失败。可以预见的是，云服务将增加定制整合的需求，加剧应用间通用语义缺失的后果。作为一名架构师，现在就应当准备一份云使用指南，防患于未然，在灾难发生前把问题降到最低点。

Steve Jones：我在这本书中 谈到过理解服务的业务价值，云真的做到了，因为它有助于让服务的交付成本更好地与其业务价值对齐。业务价值可能是关于降低成本或者转至使用计费，它也可能是创新及大规模扩容上的投资等。

因此，SOA 为理解业务价值提供了方法，从而进一步理解云和大数据如何产生价值。如果你所在的领域，处处都得考虑服务成本、如何降低成本，那么将应用转至云上以降低成本或许是值得的，但可能在大数据上投资就不值得了，因为它在这里没有价值。

Stefan Tilkov：显然是有关联的。无论你消费什么样的服务（在最抽象意义的假定下），你都很有可能通过网络来做，而且不必关心详细的实现细节。对多数 IaaS 解决方案，如 Amazon 的，这么理解都没有问题。但是，我还是发现很难把一些东西如 Google 的 App Engine 和 SOA 概念对应起来，而且常常感觉这种联系是由那些希望把过去的 SOA 思想和今天成功的云计算模型关联起来的人刻意创造的。

Jim Webber：一点也没有关系，除非你在别人的基础架构上运行你的服务，或者租用或绑定他们的（更高层次的）封装成服务的业务流程。这种云中的 SOA 概念、或者云将成为下一代的 SOA 的说法非常白痴。我承认，运行如此规模的系统是非常兴奋和有趣的，但云不是 SOA 的救世主，而是能够吸引思想领袖、分析师们的下一个耀眼的事物。如果你的服务要处理大数据，那正是它们相关的东西。否则，它们就不是——数据就是数据，而服务是业务数据之上的行为。

Claus T Jensen：云是 SOA 和动态基础设施相结合的产物。云基础架构是：

• 完全虚拟化的
• 持续优化的
• 动态响应的
• 不均等地支持不同工作量

但是更重要的是云业务模型是基于可按需消费（支付）的预定义效用服务的效用模型。我经常被问到“如何算别人使用我的云服务的费用呢”——事实上，一些问该问题的人并没有真正实施云，而只是在传统 IT 业务模型内使用了动态的基础设施而已。

返回页顶

问题4：SOA 光辉不再的一个原因是项目的失败。您认为SOA 项目要想取得成功最需要做的事情是什么？

Mike Rosen：我并不认为 SOA 已不再流行，只能说市场不再过度炒作它而已。每一个应用的基础架构和主要应用提供商都是基于或者逐渐基于 SOA 的。如今，如果你创建的解决方案不是面向服务的那将是一件很傻的做法。我相信 SOA 项目在规模上不输给任何其他的软件项目，当然，我并没有具体去查这个数字。当组织试图一口吃成个大胖子而其自身又没有一个全局架构的视野的话，SOA 项目就容易失败。所以，最主要的事情是要有一个能融合 SOA 编目和企业语义的 SOA 架构视野。对于一个好的架构师来说，形成这种视野应当用不了几周的时间。其次重要的事情是做一些小的增量项目，一次实施一些服务，为项目带来一些立竿见影的效果。并在下一个项目中借鉴获得的经验教训，逐步累加架构和服务。

Steve Jones：我认为另一个主要原因是很多项目并没有真正地实施 SOA，他们只是在做基于 Web Service 的整合。我时不时就会听到某组织在做 SOA，但当我问及他们的解决方案服务架构时，单说其业务服务架构吧，根本就看不到，能看到的依然是旧风格的架构配上 Web Service 加以整合而已。当这些人于是转移到下一个闪光的技术方法上之后，同样会失败，IT 的失败率牢牢地维持在高位。为什么？主要因为多数 IT 认为，尽管有很多反面的教材，新技术可以成为银弹，但银弹是不存在的。

一个很好的失败的例子是很多 SOA 程序中没有 MDM（Master Data Management）。如果多个不同的业务领域间需要通信，那你就需要明确相互通信的关键实体是什么。然而，几乎每一个 SOA 项目在获取这种信息的工作上都做得不够好，这就意味着实施变得异常复杂，业务价值也不再清晰。

因此，要想使 SOA 成功，首要的事情就是真正地去做 SOA，即，首先思考你的服务和能力，然后，考虑如何去交付服务。在项目的全过程中，你都应当能看见这些服务，在开发团队中，在代码仓库中，在部署指南中以及在管理报表中。这能提高项目的成功率，它把项目细分成更加独立的领域，这样能帮助敏捷等方法的应用，也可以在项目集中分散风险。这需要在纪律上有所提升，也要意识到，同样的人、流程和精神状态，即便使用新技术，也无法产生新的结果，必须要去改变人的思维方式、工作方式外加一些新技术，才能交付不同的结果。

Stefan Tilkov：用 REST 怎么样？玩笑而已。对我来说，主要因素是实实在在地从小项目开始，交付一些有价值的东西，实实在在的服务，人们真正想要的、而且会开始使用的服务。除非你做到这一点，否则就不该把公司的每一分钱浪费在 ESB、注册表、存储库以及其他的任何花哨的基础设施上，说到底，它们只是方法，本身并不创造价值。

Jim Webber：增量交付。别做那种为期三年的“转型项目”，因为你会失败。别把 SOA 当作一个长期的工作，把它当作由市场或组织内部驱动的变更所带来的一场场短小精悍的小战役吧。我之前说过很多次：这种经验叫做游击 SOA。这么做吧，你就会有取胜的机会。

Claus T Jensen：他们应该理解 SOA 不是关于技术的，不能在项目级别采用 SOA，而应该是在组织级（最起码也应该在项目集级别）。Steve Mills，IBM 软件集团的高级副总裁、集团执行官，2007 年曾说过“面向服务不是从技术开始；而应当从在功能组件方面对身边的世界和业务的一系列的思考开始”。我完全同意这一点，面向服务始于思考模型。

返回页顶

问题5：可否预测一下SOA 2.0？它会是怎样的呢？

Mike Rosen：目前，多数 SOA 都是在企业级（Enterprise Tier）应用实施，以提供业务服务和支持业务流程。企业 2.0（Enterprise 2.0）解决方案要求在企业层需要更多不同类型的服务。当需要在应用层构建丰富的交互式用户体验，并通过它访问灵活的企业级业务流程时，SOA 依然是合适类型的架构。因此，我认为 SOA 2.0 是跨端到端的解决方案栈的 SOA 的扩展。这意味着，解决方案架构师应理解如何使用它，而且通过良好设计的服务接口提供基础设施能力（如位置、存在和协作等）。

Steve Jones：不，我看没有 SOA 2.0，因为我从来也没见到过 OO 2.0。它是思考 IT 及其与业务关系的一种方法，或许，2.0 就是人们真正去做 SOA 而不仅仅是关注下一个闪光的技术而已。关键问题是人们应该看看 IT 和业务是否在为 SOA 的成功添砖加瓦。因此，看看业务价值，看看如何使用 MDM 作为关键 IT 或业务的驱动者来构建简易的 IT。

没有 SOA 2.0，只有合理地实施 SOA。

Stefan Tilkov：我并不认为叫做“SOA 2.0”的东西会有什么成功的机会——这个词已经被滥用得够多了。我非常认同 SOA 背后的核心价值有好处，但是应该给它贴上新的标签。慢慢思考这个问题后，如果业界完全停止使用什么标签，尝试着去做一些有意义的事情，也许事态会更好。可以梦想一下，对吗？

Jim Webber：我认为转向网络是不可避免的。我猜想 Web API 终将更加 REST 化，而我们也会习惯用负责任的方式打开我们的数据。万事已具备——我们能更好地理解如何在网络上分享业务协议；鉴权和授权也算是有用的（即便还不够完美）。因此，SOA 2.0 将利用这个无处不在的、安全的、健壮的平台进行大范围数据分享——它将真正成为一切事物的网络。

Claus T Jensen：就架构思想来说，另一个方法会在将来某个时间点上出现。准确地设想，即使并非不可能，也是很困难的——这就是范型变化的自然特性，它们无法被预测。在可预见的未来，我看不到这种变化，尽管作为通向敏捷和有效的主要架构方法，潜在的 SOA 应用还是很多的。

结论

总之，就连专家对 SOA 的确切含义、它的发展方向和它的未来也不能达成一致意见。这正是让我们的工作——软件架构——如此富有挑战、如此有趣的原因。似乎并不存在什么银弹，我们需要继续求索构建新的更好的 SOA 实现的方法。

关于座谈会专家

Mike Rosen，Wilton 咨询集团的首席科学家，该咨询集团专注于架构咨询。此外，他还是提供 IT 研究和分析的 Cutter Consortium 公司的企业架构主管，SOA Institute 的总编辑。他是一位经验丰富的架构师和技术领袖，在企业架构（EA）、面向服务的架构（SOA）、软件架构、分布式技术和业界标准等方面都有丰富的经验。Rosen 先生 30 年的职业生涯经历着从新人、CTO、首席架构师、到业界领先的中间件产品的产品架构师等不同角色。在他的职业生涯中，他积极参与了十多个国家举办的各种会议的技术演讲和创作。他还与他人合著了很多著作，包括：《Applied SOA: Service-Oriented Architecture and Design Strategies》、《Developing E-Business Systems and Architectures: A Manager’s Guide》以及《Integrating CORBA and COM Applications》等。

Stefan Tilkov是科技咨询公司 InnoQ 的联合创始人、资深顾问，该公司在德国和瑞士均有办公室。他参与一个大型分布式系统的设计已十多年了，该系统用到了各种各样的技术和工具，从 C++、CORBA 到 J2EE/Java EE 以及 Web Service，到 REST 以及 Ruby on Rails 等。他领导 InfoQ 的 SOA 社区多年，发表了很多专题文章，且出版了一本图书（《REST und HTTP》，德文），他积极参与各种全球的技术大会并发表技术演讲。

Jim Webber 博士是 Neo Technology 公司首席科学家，该公司开发了著名的开源图形数据库 Neo4j ，他主要负责图形数据库服务器技术，同时也编写开源软件。Jim 热衷于使用大型网络如 Web 来构建分布式系统，这也促成他与人合著了《 REST in Practice 》一书，之前还写过《 Developing Enterprise Web Services - An Architect’s Guide 》一书。Jim 是活跃的演讲者，定期出席全球各种会议。他的博客在这儿，Twitter 是 @jimwebber 。

Steve Jones是凯捷公司基础数据管理的全球主管，他负责凯捷全球 MDM 销售的协调和建立，包括卓越离岸中心的发展、以及以业务为中心的 MDM 咨询和交付的方法的出版和产业化。Steve 帮助客户交付那些看上去像业务、像业务一样发展，成本符合价值的 IT 资产。他和业务及 IT 领导们一起工作，帮助组织控制基础数据将其控制在符合业务价值的范围内。

Claus Torp Jensen是业务流程优化（BPO）基础团队的高级技术成员，及 SOA-BPM-EA 技术战略部的首席架构师，在概念上和实践中推动（译注：业务和 IT）的对齐及整合。BPO 基础团队负责 IBM 软件产品的架构，确保从客户的立场支持 SOA、业务流程管理（BPM）和业务敏捷的核心原则。Claus 于 2008 年 3 月加入 IBM，在此之前，他是一家地区 Danske 银行的集团首席架构师、架构和业务发展部的副总裁。

从 1999 年开始，他负责驱动 Danske 银行的 SOA 项目及卓越中心，并被认为是 SOA 的专家和布道者。Claus 拥有丹麦奥尔胡斯大学的计算机科学博士学位。

查看英文原文： SOA in 2011 Panel

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

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