通過一個真實故事理解SOA監管

SOA監管(SOA Governance)是SOA實施中的一個重要話題，但是很多人都搞不清楚其含義。我采訪過很多人，也閱讀過一些資料，才基本弄明白?？偟母杏X是，如果 直白地去講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實施成敗的關鍵。

原文轉自：http://www.kjueaiud.com