避免JaBoWS成为企业SOA基础

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的想法呢？

查看英文原文：Avoid JaBoWS as the Basis for your Enterprise SOA