Nick Malik 声称 JaBoWS（Just a Bunch of Web Services，意即一组杂乱无章的 Web 服务）是企业 SOA 的敌人。
在其博客先前的帖子中，Nick Malik 首先提出了你的 SOA 是否是 JaBoWS 的问题。对于 JaBoWS，他并不想发起一个关于技术的讨论，而是就企业 SOA 的一般方法和目标发表了意见：
我是从业务而非技术（服务安全性、可用性、可组合性等等）角度提出这个问题。换句话说，如果业务需要通过 SOA 获得灵活性，那么这些可用的服务是否代表了完成该目标的正确的交互端点。
他认为“评估一个 SOA 有‘多好’是一种为实际存在于公司战略中的竞争机会建模并观察 SOA 是否能同时满足预期和潜在竞争行动的手段”。SOA 的目的主要在于使业务 /IT 协调一致：
SOA 在某些环境（尤其是我们的）中能节约金钱，但是它的最大价值在于可以快速而廉价地增加一个满足一个竞争机会的业务能力。速度很重要；成本也很重要。一个优秀的 SOA 被特意构造成可以按这种承诺交付。
他指出，传统 IT 非常适合很少变化和可能或可能不经常出现的过程。而 SOA 则特别适合频繁出现和变化的过程。
在他最近的帖子中，他声称“JaBoWS 不是架构团队失败 SOA 项目的坏习惯”纯粹是误解：
JaBOWS 是抹杀价值的死胡同。产生无法使用服务的自顶向下方法，或产生重叠和不能很好协作的一组服务的自底向上方法都是错误的。JaBOWS 是这么多高举 SOA 大旗的公司所采取的代价昂贵、耗费时间、毫无价值的练习。
此外，Nick Malik 认为 JaBoWS 是对整个 SOA 社区的一个威胁：
当任何一家公司因 SOA 缺少价值而毙掉他们的 SOA 项目时，我们大家就都失败了。在 SOA 社区中，我们都致力于使每个为炒作而付费的公司成功的实施其 SOA 项目。
文末，Nick 呼吁社区开始“写些关于 JaBoWS 的文章，就 JaBoWS 进行一些讨论，同时分享如何有效避免 JaBOWS 的经验”，他还为 JaBoWS 定义了一个简单的公式：
不是工具的问题，而是过程和人的问题。
工具 + 现有过程 = JaBOWS。这非常非常非常的不好。
Nick Malik 的帖子与 Anne Thomas Manes 的寻找 SOA 成功案例相呼应。如她指出的，所有那些诱人的（技术驱动）架构、工具和产品“仍需示范所有这些基础设施如何产出任何业务价值”。
Scott Wilson 认为 Malik 的声明是“对什么是 JaBoWS 的缺点和什么不可避免地导致了 JaBoWS 的一个过分简单的描述”：
我觉得，那些工具（他完全有权责难）的部分问题好像是它们本身就打算那样做；但是我认为，正是那些严格、强制性的定义导致了企业 SOA 实现中的大多数问题。我反而觉得 SOA 就像我做 ITIL 一样：它是一个需要某些灵活性的概念，这样才能在任何场合有用。强行给其打上它是和不是什么的印记，在具体组织中有很多意义，但是我不确定这样做对于整个概念是否是个好主意。
Mike Kavis 对 BPM 作为任何 SOA 项目的主要驱动力进行了举例说明：
SOA 的问题不在于 SOA，而在于人。人必须理解 SOA，以及将他们的动机与一个关键业务驱动力协调一致的重要性。BPM 是可以得到你的业务发起人支持的杀手级应用。并且，为最终取得成功，你需要对变更管理进行强有力的领导。
您对 JaBoWS、工具、BPM 和企业 SOA 的想法呢？
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论