SOA怎么應對尷尬的障礙局面？
網(wǎng)界網(wǎng) 發(fā)表于：13年05月28日 12:27 [轉(zhuǎn)載] CIO時代
當我們把目光轉(zhuǎn)向SOA時，同樣的問題出現(xiàn)了當應用因為一個根本性的故障而被迫終止的時候，應該由誰來負責接聽并處理用戶的緊急求助?對于很多企業(yè)領(lǐng)導者來說，半夜兩三點電話響起不是什么好事情這很可能意味著，企業(yè)出了事，而且這些事情很有可能不知道該由誰解決。
隨著企業(yè)規(guī)模的逐漸擴大，企業(yè)的復雜性也不斷增加，不同部門之間職責、利益、流程的交錯，讓包括部分高層管理者在內(nèi)的很多人不清楚，如果企業(yè)某個地方出了問題，到底應該追根溯源到哪個部門、哪個人。
這種現(xiàn)象對于已經(jīng)深入到企業(yè)每個角落的IT產(chǎn)品、IT服務也是如此。早上ERP登錄不上去了這到底是網(wǎng)絡問題，還是ERP問題，或者是數(shù)據(jù)庫、服務器出錯了?IT部門到底應該找哪個供應商解決問題呢?
目前SOA已經(jīng)步入實施的縱深階段，然而，近來國外的一系列SOA實施案例表明，曾經(jīng)備受肯定的SOA架構(gòu)正暴露出其架構(gòu)的固有缺陷當基于SOA的服務管理達到一定深度時，目前的SOA管理策略在服務故障的追根溯源方面力有未逮，這一現(xiàn)實對整個SOA架構(gòu)和管理理念都提出了嚴峻的挑戰(zhàn)。國內(nèi)SOA用戶應該對這一動向保持足夠的警惕。
誰該為故障負責
分析師蘭蒂·海福納認為，曾經(jīng)被廣為稱贊的SOA的架構(gòu)特性正在暴露出它的固有缺陷目前，大部分應用了或正在應用SOA架構(gòu)的公司和組織對于“應該由誰來負責響應故障求助”這一問題困惑不已。
從目前的狀況看，似乎總是能找到這樣或那樣的團隊負責提供應用故障服務，但是最后的結(jié)局往往是所有應用相關(guān)的開發(fā)團隊都被扯進來，圍繞糾纏不清的責任問題一籌莫展，問題的根源卻無從確認。
SOA架構(gòu)擁有太多處于移動狀態(tài)的組件，因此，順藤摸瓜找到服務故障發(fā)生的根本肇因并不是一件容易的事情，更何況與此同時SOA還是一個由多個相互關(guān)聯(lián)的層組成的架構(gòu)，這更增添了查錯的復雜性。
海福納認為，目前的大部分SOA管理工具必須進行有針對性的改進以應付這種尷尬局面。SOA管理工具必須具備鎖定深層次服務管理問題的能力。應該說，現(xiàn)有的SOA管理工具在定位問題的發(fā)生方面做得不錯，它們大都能在問題發(fā)生時通過一項服務提醒CIO，即使故障產(chǎn)生的環(huán)境非常復雜。比如在Java、。NET、消息中間件或者是遺留系統(tǒng)接口內(nèi)部這類環(huán)境，這些管理工具仍然能夠迅速發(fā)現(xiàn)問題。
但是，僅此而已。
CIO們被告知系統(tǒng)中產(chǎn)生了一個故障，“好吧，接下來問題來了，SOA服務產(chǎn)生了問題，我們該向誰撥打這個求助電話呢?”海福納說，面對實施過程復雜、需要由多個團隊協(xié)作的SOA架構(gòu)中產(chǎn)生的問題，每個團隊都會龜縮在各自的陣地中大喊：“這不是我的錯我負責的部分工作得很好!”這顯然是CIO們始料不及，卻可能得到的唯一答案。
