技术开发 频道

避免JaBoWS成为企业SOA基础

【IT168 管理文档】

    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是可以得到你的业务发起人支持的杀手级应用。并且,为最终取得成功,你需要对变更管理进行强有力的领导。

0
相关文章