欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

说明SOA监管(SOA Governance)实例(收录备查) 博客分类: 网络Framework soa企业应用

程序员文章站 2024-03-24 18:03:22
...

SOA 已经不是单纯技术问题

  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 企业应用