SOA为支撑业务敏捷性提供了新的思路和方法

SOA为支撑业务敏捷性提供了新的思路和方法,第1张

SOA为支撑业务敏捷性提供了新的思路和方法,第2张

SOA监管(SOA Governance)是SOA实施中的一个重要话题,但是很多人都搞不清楚其含义。我采访过很多人,也阅读过一些资料,才基本弄明白。总的感觉是,如果 直白地去讲SOA监管的问题,必然引进大量的新术语,一般开发者实在不容易听懂。如果能够举一个例子,那么大家就容易理解得多。恰好昨天在书上看到一个真 实的故事,很形象地说明了SOA监管的意义。所以不妨跟大家分享一下。这个故事是关于Sun的,当然这类事情实际上曾经发生在很多大型公司里。

  在90年代后期,Sun推出了一系列产品,包括Java、Solaris等,他们希望能够尽可能地鼓励用户去使用这些产品,但是当时网速太慢,通过 Internet下载几百兆的软件根本不现实,于是Sun在网站上推出一个电子商务服务,下面我们不妨称之为服务A,你只要通过信用卡付10-20美刀快 递费用,就可以免费获赠Sun的超值产品光盘。被叫去编写这个电子商务服务的程序员当时隶属与内部IT部门,他写了一个在线服务,用来完成信用卡付账交 易。当然,这是一个“子服务”,我们不妨称其为服务Z,这个在线服务Z运行在内网上,采用了今天看来都不落后的体系结构——直接通过HTTP传输加密的 XML消息。很快,服务A对用户见面了,并且工作得很好。

  不久之后,这个程序员被调到了Java开发组。当时Sun的Java网站提供一个类似MSDN的Java产品光盘订阅服务,下面不妨称之为服务B,这个服 务每季度向订阅者寄送最新的Java产品光盘。当然,订阅者也要通过信用卡付订阅费。碰巧这项工作又交给了这位程序员来完成。他当然不愿意重写那个很麻烦 的信用卡结帐服务Z,既然原来的那个服务是通过HTTP暴露在内网里的,何不复用之?他就简单地复用了这个信用卡结帐服务Z,完成了任务。这样,在90年 代后半期,这位程序员就率先实现了企业服务的复用。而十年后,服务的复用正是今天SOA追求的目标之一。

  这样就形成了一个有趣的局面,即服务A中包含一个子服务Z,而服务B又依赖于服务Z,Z实际上成为了一个公共服务,但是这个秘密只有那个程序员和少数几个人知道,Sun的经理们对此懵然不知。

  几年之后,这位程序员离开了Sun,随着他的离去,这个秘密变得更加不为人知。

  随着互联网的发展,人们已经习惯于从网上直接下载软件,服务A已经变得越来越过时了。于是终于有一天,Sun的一个经理决定,关闭服务A。结果意想不到的事情发生了,随着A的关闭,服务Z也被关闭了,这就导致服务B全面崩溃,所有的订阅者都无法付款了。

  这就是一个缺乏监管的情况下产生的典型事故。在传统的企业IT架构里,当系统仅仅是部门级烟囱系统时,软件模块之间的关系简单,监管不是一个很突出的问 题。而当各部门系统进行整合时,如果采用EAI/ETL方案,则也不大有监管的问题。只有在实施SOA的时候,把传统的烟囱系统打散成为一个个可复用的服 务时,监管的问题就突出了。SOA监管的意图,就是要让各种服务以清晰有条理的方式组合协作起来,并清晰地度量每一个服务的开销,评估每一个服务的开发和 维护所需的技术,确定当服务失效时采取的必要措施。总之,就是要把服务管起来,让它们有组织有纪律的共同工作。如果没有一个监管的制度和计划,那么就会出 现这样的局面:服务与服务之间有什么关系?不知道。服务之间彼此是否依赖?不知道。这两个服务的功能是否重复?不知道。这个服务是否冗余?不知道。开发维 护这个服务需要什么技能?不知道。当用户量增加时,维持这一服务的QoS所需的硬件消耗怎么变化?不知道。当服务崩溃时,谁来接替?往谁那里打电话?是否 有手工流程紧急应对?不知道!一大堆无法无天的服务以谁也想不到的方式攒在一起,任何一个点风吹草动都有可能会天下大乱。这就是缺乏监管的SOA将发生的 局面。这样的SOA,与其说是一个系统,不如说是一团乱麻,一场灾难。

  因此,SOA监管对SOA来说,不是可选的,而是必须的,甚至是决定SOA实施成败的关键。

位律师回复
DABAN RP主题是一个优秀的主题,极致后台体验,无插件,集成会员系统
白度搜_经验知识百科全书 » SOA为支撑业务敏捷性提供了新的思路和方法

0条评论

发表评论

提供最优质的资源集合

立即查看 了解详情