Software AG 发布了一份分析 SOA 治理最佳实践的用户调查。Software AG 的这次调查得到了客户广泛的响应，其中一个关键收获是：企业内，SOA 是真实的并且正在大规模地进行。互连系统已成为现实并正在产生价值。调查表明：
SOA 治理在创建可持续性、企业级实现过程中扮演关键角色
91% 的反馈者认为治理对他们的 SOA 战略非常或较为重要。
绝大多数反馈者都同意以下工具是 SOA 治理必需的：
- 注册中心
- 仓储
- 安全
- 策略管理和执行
- 服务生命周期管理
- 性能监测
- 测试
调查还向受访人询问了哪些标准对于 SOA 来说是重要的。WSDL 和 SOAP 得到 90% 的支持，随后依次是 UDDI、WS-Security、BPEL 2.0 和 WS-Addressing。认为 REST、SCA 和 JBI 重要的大约是 10% 或更低。
InfoQ 对 Software AG 的 VP 和副 CTO Miko Matsumura 进行了采访，请他谈谈对这次调查反馈的看法。
InfoQ: 调查的介绍并没有提到“重用”这个字眼，这是疏忽还是有意为之？
Miko: 我们倾向于小心地使用“重用”一词，因为对不同的交谈对象来说，它具有不同的含义。如果你在和开发人员交谈，人们并不真的相信它。以前在谈论面向对象代码库“重用性”的时侯，他们就已经听说过这个词。重用静态库需要忍受企业生命周期的全部痛苦：预备、部署、质量保证等等，这显然完全不同于连接已部署服务，但是开发人员并不这么认为。随便写几行代码几乎总要比“重用”其他东西要省事。如果与你交谈的是业务人员，重用也同样很难让他们激动起来。提高机动性和开发速度更能吊起他们的胃口。他们对能够将功能块接入业务流程的想法更感兴趣。业务人员和开发人员有一点是相同的，他们都对与策略和流程相关的 IT 限制是如此复杂和迟钝有些厌倦了。他们同样也都对术语“治理”并不感冒！
唯一对这一词反应积极的那群人是负责财务工作的。他们为之激动的原因在于成本模型——将一再出现的成本（IT）转变成一个可重用资产的概念对他们非常具有吸引力，而且他们过去没有愤世嫉俗的经历。他们只是觉得……唔，这是有目共睹的，让我们这样做吧。
因此，假如一个词对不同人来讲有如此多的不同含义，那么我会非常谨慎地使用它。
InfoQ: 人们在实施 SOA 过程中他们遇到的主要障碍是什么？
Miko: 有 4~5 个非常重要。其中一个非常重要的就是资金，并且要能够证明最初和正在进行的努力是值得的。这是一场非常有趣的挑战，人们往往对架构蓝图表现出相当的热情。每个人总是对当前架构有些不满，对其有诸多抱怨。总是对“下一个”架构充满期待。但是，架构从来无法令业务人员激动。业务人员多少有种与企业 IT 作对的心理：这对我有什么好处？这使得和谐很难建立。最初 ROI 的建立需要信任和同盟。IT 团体无法产生利润和资金，它需要与业务团体合作来达到那个目的。
接下来的问题是你如何维持这个成就？在你已经证明 ROI 之后，你仍需为不同服务建立分享和所有权。业务单位未必想拥有服务。他们当然不愿意为其他业务单位打工！那么，谁来支付变更所需成本？一个业务单位“拥有”某个服务吗？共享服务对他们来说有什么好处？
这些都是将服务迁移到一个共享环境中隐含的挑战，尤其当涉及数据的时候，相关单位不会想要共享这些数据的。此外，所有的成本分摊（chargeback）机制也被证明具有挑战性。这显然还未考虑复杂性以及为了使人们在数据模式上达成一致所需的成本。
另一个障碍是治理的建立和实施。这是个十分敏感的问题，对技术人员而言尤其如此，因为人们不想受到约束。人们就“治理范围”取得一致意见并没有给予足够的重视。人们不必分享他们关于治理的理由。遵循的原则是尝试“知情同意（informed consent）（译注：即先告知对方，再取得对方的认可或同意）”。他们之所以同意接受治理是因为：他们都已经深刻认识到了服务为何要以某种一定的方式来设计。人们会不太适应治理，技术人员尤其这样。现实是，诸如互操作性和安全等自动策略执行会使 IT 邪恶的部分更快捷，而不是更迟钝。你只需习惯你未来必须遵守的事实就行了，要么采用自动方式，要么采用非常缓慢和痛苦的人工复审方式。
我还想说，重用是场挑战。学习别人已经完成的东西需要花很长时间。你可能需要请求变更。而且甚至还不清楚这次变更会比完全书写新的代码要好。但是人们常常忽略了新代码的成本：臭虫、可靠性、随重复代码而来的维护成本增长等等。人们常常忘记服务处于“稳定状态”而且具有价值。“重用”蓝图来制造你自己的汽车跟“重用”你朋友的车子是有区别的。实际的车子能让你更快地去你想去的地方。“只让我部署我的代码”是个非常诱人的主意，但是我发现大多数企业 IT 不愿意接受与之相关的风险。因此取而代之，我们依赖已经有的东西，使用它来减少在开发过程中要跨越的障碍。
InfoQ: 治理的理想人员搭配是什么？
Miko: 理想的人员搭配必须能代表这个组织。看看一个政府，它就代表了被治理的人民。第二个方面是，他必须是人们所相信能代表他们利益的那个人。你找到的这个人必须能足以代表他们利益，同时能向他们传递某些策略的意义所在。我认为温斯顿·丘吉尔就是这样的人，他说民主是一种非常愚蠢的政府形式，但是比所有其他的方式要好。这暗示你的 SOA“卓越中心（CoE）”应该是一个代表团——每个受策略创建影响的人在这里都应该有一席之地。
在 CoE 环境中，你不能成为麻烦，要解决冲突总需要互相妥协，你需要兼具闯劲和质疑两种性格。因此，如果你在 CoE 中是开发人员代表，尽管质疑任何东西，但是不要抱怨它。最终你还得跟这些人合作。
InfoQ: 如何让治理在 B2B 环境中发挥作用？
Miko: 可以试试两种方法。通常来说，你已经知道了一些支持基于多个消费者和单个提供者模型的 SOA 原则和实践。这是一种供应链类型的模型，好比一个大型 OEM、沃尔马或波音等，所有人都通过这些接口集合访问它们。你拥有的一般是大把的一对一关系。这种环境中的治理并不困难，因为几乎全部集中在提供者一端。变得复杂的地方是跨提供者和消费者网络的业务流程编配。
在 WebMethods 看来，我们发现提供者 B2B 网关相当成功。我们还没有看到有多个提供者对应多个消费者的情况（类似“ebay”模型，一种自由市场式的模型）。“垂直市场”（在 dot、com 繁荣的时代曾非常火爆）也没有多少成功案例。常见的模式更像单个提供者对应多个消费者。
InfoQ: 成熟度级别会走向何方？企业针对 SOA 的下一步是什么？
Miko: 调查显示人们对概念已经知道得非常清楚。下一步就是由知道转向行动。我们更清楚地了解了技术和组织相关的需求。下一步就是设计蓝图：实现和治理。人们已经非常理解 SOA 的概念，这是必须的，但是只有它还不够。
InfoQ: SOA 治理和 IT 治理有什么区别？为什么它不只是 IT 治理的一部分？
Miko: 逻辑上讲，SOA 治理应该属于 IT 治理范畴。事实上，只要你研究下象 ITIL 这样的 IT 治理实践，你就可发现很多关于优化系统行为的线索。IT 治理强调财务与 IT 的联系，尤其关于成本的基础，具有非常强的成本控制导向。你往往还能看到一种提供者导向的方法，它非常强调 CMDB（译注：配置管理数据库，ITIL 核心概念之一），跟踪资产的整个生命周期。通过“帮助台（help desk）”功能你可以了解很多痛苦，使用 CMDB 来追踪这些影响的根本原因，你就可以最优化你的 IT 资产。IT 治理是一个合适的先驱（强调诸如可靠性、TCO 这类东西），并且现在 ITIL 正开始吸收一些 SOA 相关的东西。SOA 治理的独特之处在于强调业务流程和机动性。从文化上来说，SOA 加入的是基本外部事物：服务消费者、业务单位或客户。现在，你不只是在为服务消费者的成本中心进行优化。
通过对齐业务功能和 IT 功能，SOA 治理具备了改变文化的潜力。你知道，ITIL 和 IT 治理中的“变更管理”概念关注的是帮助台（help desk），一般跟开发或部署新功能无关。在 IT 治理中，“变更”意味着发生了不好的事情，你需要寻找“根本原因”并试图找出是谁犯的错。在 SOA 中，变更可能意味着随重用、组合和配置而来的新功能和机动性。
InfoQ: SOA 治理正演变成一个复杂的科目？（注册中心、仓储、安全、策略管理、逻辑数据模型、……、性能检测……），这会成为 SOA 成功的基础还是成为它的负担？SOA 会是这么复杂吗？
Miko: 这当然是许多人所担心的问题。这正是我们认为治理自动化将大有可为的原因。我们看到的是最佳实践正在浮现，当你在你的 SOA 中打造一致性的时候，你需要互操作性成为其基础。假如你在提供者和消费者之间有很多依赖，你就应该确保有相应的 SLA。利用能帮助管理行为的策略，系统将更具可管理性。这些是运营一个互联系统所必需的。
治理是一种复杂的系统：你应该最小化对人的影响。自动化更容易处理复杂性相关的问题。有很多东西都得跟踪，而人们不可能记得要跟踪所有东西。
要成功实施 SOA 治理自动化，你必须以迭代方式进行，并推动一系列主题：安全性、互操作性、可管理性等。
InfoQ: 版本管理一直是所有远程技术的一个主要障碍。对于版本管理，人们该做些什么？工具如何来简化这种版本管理工作？
Miko: SOA 王国的第一法则是可演变性的原则是关键原则。在某些方面永远没有正确答案。你可以进行完美的粒度划分和重用，但最后总能发现它们不起作用的新场景。另一个陷阱是把你的几年光阴都花在了寻找完美的可重用性和粒度，以及完美的模式上。那你就别指望发货了！因此，与之相反你只管装上最能满足业务需求的不完美服务并尽力想象未来可能的使用场景就行了。那就是你需要版本的时候。你如何避免版本碎片，以免最终因此而把服务毁掉？
关键是建立一个绑定策略，它在消费者和提供者之间带来了某种程度的松耦合。使用一个仲裁：端点必须被做成虚拟的。在某种程度上，你可以使用各种技术透明地迁移版本并减轻其中的痛苦。这里最大的问题是，只要有人与端点是紧耦合，那就意味着你必须首先找到是谁绑定到了这个服务上。缺少某种治理系统，你甚至都不知道谁正在消费这个服务。如果这时你没有仲裁，你就必须在新版本发布时让所有的消费者把代码全部重新编译一遍。因而，你基本上要追着每个使用不完美服务的人，让他们基于新版本重新编译他们的程序。这并不管用，一定要设置一个绑定策略，其中没有匿名消费者（除了你不关心的和那些你需要调整它们的消费级别以免招致拒绝服务攻击的消费者）且所有这些消费者都绑定到一个“虚拟化”的服务端点上。采用这种方式，仲裁可以将它们重定向到任何你期望的地方。
另一个机制就是运行时发现，但是应用并不广泛。基于代理的发现有 Amberpoint 和 Actional，基于网络的发现有 Managed Methods。
采用分类理念和基于角色的访问控制，你也可以隐藏版本管理的某些复杂性。这样不同小组感觉他们正在使用同一个服务，即使实际上那儿有不同版本。拥有多种版本是不可避免的。
还有更多种减轻版本问题的反馈。我们无法否认这个问题的存在。事情必须转变和演变。
治理有 3 个瓶颈：
对开发服务的开发人员来说，他们应该通过可重用性瓶颈，验证一个服务可以或必须被重用，我们需要新版本吗？在这种情况下，策略当然应该出现，如果你可以重用一个服务，尽管做好了。另一个瓶颈就是运行时治理系统：如果我们有一个新版本，使用透明的重定向，以及某种 XSLT 转换或消息传递这个模式，可以让这个新版本对老用户是透明的吗？第三个瓶颈就是发现期间，我们可以在哪儿可以使得这种新版本的发现得以透明并减少侵入性。如果版本很多，我们至少可以隐藏对多数消费者小组不适合的那些。
InfoQ: 如何资助 SOA 治理？
Miko: 第一个模式就是自顶向下模式：一个架构师和某些 VP 级别的 IT 行政人员对收益认可，这是高级别的信任，并且这是你获得资助的方式。
第二个模式是暗度陈仓（smuggling operation）：业务单位往往不会资助其他人的需要。从好的方面来说，业务单位是个绝好的资助者，因为只要一点 SOA 可以帮助业务走得更远。给一个 BPM 项目加一点 SOA 就可以轻松产生上千万美元的 ROI。因此，一种简单的做法就是悄悄地给项目中嵌入某些治理或共享基础设施组件。这要求在项目中包含某种治理活动的努力。
你还可以通过成本机制建立某种共享基础设施，并实施某种成本分摊机制，但是这要求一些相当正式的执行委员会。
InfoQ: 如何从 SOA 治理中产生 ROI？
Miko: SOA 治理和 SOA 实施是实现战略，与 SOA 本身的收益息息相关，一个好的苗头是我们逐渐看到了 BAM、运行时治理的收益，其中你可以通过它们的使用和重用度量服务的动态经济收益。结果，你获得了一个服务可重用性显示其增长和价值的榜样。只要看到不断增长的服务价值，企业就会很激动，因为你看到新消费者正在重用同一个用例或增加了服务数量。
简而言之，如果你能通过服务（它也在不断增长）用户数的增加显示利用率的增加，你就可获得一个“曲棍式”的增长曲线。剩余的其他事情就是显示这种做法是多么的有价值，这样你就有了 ROI。
我们已经看到好的成功案例并且人们能够进行自我判断。
InfoQ: 业界有很多关于 SOAP/WSDL 和 REST 的争吵，调查是否明确显示了什么？
Miko: 人们在企业中使用标准是有利的，人们可以从标准获得最佳实践和互操作性。如果你看看那些驱动因素，你就能理解标准动荡的原因。它们一些已经成为 WS-I Basic Profile。我们看到了大量基于 SOAP 的活动。消息传递方式整体上扩大了企业目前的活动。如果你是基于 Web 的方式，考虑伸缩性，那么 REST 就显得更合适。
SOAP 是所有系统都愿意涉及的最小公分母，因而我们看到了它的广泛采用。REST 显然更轻量级，但是那样（我没有指 WS-*“Web 服务”，我只是指你能在 Web 上使用 REST 服务）你只能得到 JBOWS（Just a Bunch of Web Services，只是一堆杂乱的服务）。
至于 SCA，Software AG 是这一努力的早期参与者之一。至今消费者反响还不热烈，但是从构架系统的角度看，它非常方便。我们将在即将到来的 webMethods 和 Centrasite 产品线中支持大量的 SCA 相关特性，例如动态分析 SCA 装配包元素并将这种依赖关系在 Centrasite 中为治理提供可视化表示。
InfoQ: 我们已经到了 2008 年，并且“技术缺乏”依旧还是我们首先面临的是问题。如今，我们对它有什么解决之道？出路在哪里？
Miko: 到目前为止，企业 IT 是一个业务，围绕 SOA 我们已经走过了很长的路，采用的都是东一榔头西一棒的方式，而不是全面采用。很多年之后，终于实施完了。从这次调查清楚地显示，SOA 是真实的。技术短缺终将自己解决，因为真正的钱正在不断投入，人们会得到培训，而且他们还将看到职业机会。
评论