在这篇三步曲中，对于 SOA 现今是如何被看待，ThoughWorks 的架构师 Neil Ford 指责了供应商的市场策略。
第一期谈的是 SOA 的需求是如何兴起的：具体战术 vs. 全局战略。
根据 Neil 的说法，当还是小公司时，它们对于 IT 的需求也是很小的。当业务需要更多的软件时，它们将需求交给开发者，编写代码。应用的数量也是有限的，对于应用的交互性不需要一个综合性的战略——也没有时间来干这个。一切只与交付软件以保持业务有关。直到一天，当公司变成企业时才会明白其 IT 系统是一团乱麻。有很多代码冗余，数据库里的数据也存在严重的重叠，等等。Neil 认为，这一切的发生通常是因为：
... 主要出于两个原因：首先，在仍是一个公司（成为一个企业之前）时，你会选择阻力最少的道路，如果你有花费时间去构建一个综合的战略，你就无法让公司存活下来。其次，也是更为重要的，对于业务而言是战略性的东西对 IT 来说都是战术性的。
问题是 IT 无法像业务一样快速变化，这意味着 IT 始终需要战术性的回应业务所带来的决策和计划。
不管你对一个综合的，漂亮的，良好设计的企业架构付出多少努力，它都会在业务第一次做出与以往不同的决策时受到巨大影响。大牌供应商所兜售的 SOA 神话是说你可以创建一个宏伟的企业架构策略殿堂，但在现实世界它却总摆脱不了倒塌的命运，因为 COO（CEO）总是可以推翻 CIO（以及他的伙伴，CTO）。如果你可以说服你的组织允许 IT 为业务的长期能力设定战略的话，你应当这么做。然而，你更加灵活的竞争对手在你建造你的殿堂的时候会吃掉你的午餐。
第二期讨论了基于标准的与标准化的 SOA 两种方式。
Neal 发现软件供应商所鼓吹的主流市场颂歌之一就是“基于标准”的 ESB 实现，它被展示为所有 SOA 问题的灵丹妙药。这里的问题是：
ESB 是基于标准的却不是标准化的。这一点区别非常重要。所有的现成 ESB 都高度遵循标准，但却全部是由高度私有的技术粘合在一起。这种粘合表现在管理工具，以及他们的 BPEL 设计是如何工作的（包括客户的 BPEL 元数据），你如何进行配置，如何处理路由，等等方面。这一清单还可以列出来很长很长。这些供应商决不允许像 SUN 在 J2EE 上所加的那一类型的标准化。供应商最不愿意的就是再次看到他们的（猛挣钱的）孩子转变成日常应用普通的软件。他们会号称说要制定一个真正的标准，但这都是忽悠人的。他们更想成为数据库供应商，而不是应用服务器供应商。
而这不仅只是对于商业化而言，对于那些围绕其产品销售咨询，培训和支持的开源产品而言（例始，JBoss，Mule，Fuse 等等）也是一样的。他们都有将其用户锁定在其私有的粘合剂与工具中的动机。
最后，第三期讨论了 SOA 工具与反行为。
Neal 同时还注意到为眩目、简单的 SOA 示例而兴奋的危险性，供应商通常将其当作对所有 SOA 问题的解决方案来出售：
... 最受欢迎的示例应用就是 [供应商的]BPEL（业务流程执行语言）设计器了。这一设计器允许你通过在方盒之间画上线来将服务联结起来。这些线可以包括转换以及其它吸引眼球的东西。而且示例非常成功。“看啊，只需要在这里和和这里画上线，点击一下运行，瞧！大变 SOA！”
管理层通常会对这些示例感到兴奋并指示开发人员使用这些新工具开始 SOA 实现。问题是，当事物之间的联系显而易见时，这些（工具）对于非常小的“玩具”示例工作得很好。然而，一旦事情变得复杂了，它们都会受到毛团效应的影响：所有的线条开始交错在一起，你也无法再创建一个对别人来说有意义的图表了。Neal 将这归因于图形化语言（带有自动生成）在总体上并非是构建复杂系统，特别是业务流程定义的合适解决方案这一事实。 他指出这样的语言有如下这些问题：
- 重用：你不能真正地重用你的工作流部件，因为没有方法或子程序功能（有子工作流的人会幸运得多）。最主要的是，人们通过拷贝和粘贴来获得“重用”，你决不会对代码这样做。
- 重构：没有重构，要找出可重用的公共工作流块会很困难。当你没有重构时，你同样也不会留意重构的机会。
- 有限的可编程性： 你无法拥有 if 声明和 for 循环，你只能得到这一特定的 BPEL 设计器所支持的东西。你得到的是流程图模样的真正决策陈述的替身，但它们较现今语言所能提供的功能来说，也太弱不禁风了。
- 测试：你不能为工作流编写单元，功能或集成测试。唯一真实的测试选项就是用户验收，这意味着世间万物都得上线并且运转起来。如果你没有单元测试，你的代码里也不会有公共的 Mock 对象或其它测试技术。
- 难于差异比较：假设你打败了怪兽并且让一个不平凡的工作流上线并跑了起来，一切都是大大的好。六个月后，你也用不平凡的方式进行了变更，一切还是大大的好。现在是应该看一下有什么不同了。BPEL 工具没有 diff 功能，你只能可视化的对比图表（呸）或者对比 21 万行 XML 文档（呸呸）。BPEL 要么依赖于重量级的图表工具要么依赖于原始的 XML，没有中间选择。
Neal 将这些工具当作“涂鸦工具”——创建漂亮的图片时管用，但一上规模就倒塌掉。他对于这一问题的解决方案是“用代码保持行为”。
这一系列文章对于 SOA/BPM 软件及其供应商的状况提供了一个有趣的观点。很多人都声称大牌供应商都是在那里销售他们的产品，因此作为结果，通常会夸大他们的能力。另一个常常提到的是 SOA 技术经常被置于许多现存业务问题的解决方案这样一个位置。另一方面，许多实践者相信高端的（领域特定）的工具和语言是提高开发者的生产力的要义所在。一些人将软件工程的整个发展历史看作是关注于设计更加容易使用的软件系统（现在几乎没什么人用汇编了），并且相信在这其中大牌供应商的产品居功至伟。你如何看待这一问题？Neal 的指责是正确的吗，或者对于决定 SOA 实现的合适方案，工具与中间件很自然的只是软件 /SOA 架构师的责任而已？试图为他们的错误决定开脱而指责软件供应商（以及 / 或者 管理层）是否只是一个牵强的借口？
注册/登录 InfoQ 发表评论