在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实施成败的关键。