當我們把目光轉向SOA時，同樣的問題出現了——當應用因為一個根本性的故障而被迫終止的時候，應該由誰來負責接聽并處理用戶的緊急求助？對于很多企業領導者來說，半夜兩三點電話響起不是什么好事情——這很可能意味著，企業出了事，而且這些事情很有可能不知道該由誰解決。
隨著企業規模的逐漸擴大，企業的復雜性也不斷增加，不同部門之間職責、利益、流程的交錯，讓包括部分高層管理者在內的很多人不清楚，如果企業某個地方出了問題，到底應該追根溯源到哪個部門、哪個人。
這種現象對于已經深入到企業每個角落的IT產品、IT服務也是如此。早上ERP登錄不上去了——這到底是網絡問題，還是ERP問題，或者是數據庫、服務器出錯了？IT部門到底應該找哪個供應商解決問題呢？
當我們把目光轉向SOA時，同樣的問題出現了——當應用因為一個根本性的故障而被迫終止的時候，應該由誰來負責接聽并處理用戶的緊急求助？
目前SOA已經步入實施的縱深階段，然而，近來國外的一系列SOA實施案例表明，曾經備受肯定的SOA架構正暴露出其架構的固有缺陷——當基于SOA的服務管理達到一定深度時，目前的SOA管理策略在服務故障的追根溯源方面力有未逮，這一現實對整個SOA架構和管理理念都提出了嚴峻的挑戰。國內SOA用戶應該對這一動向保持足夠的警惕。
分析師蘭蒂?海福納認為，曾經被廣為稱贊的SOA的架構特性正在暴露出它的固有缺陷——目前，大部分應用了或正在應用SOA架構的公司和組織對于“應該由誰來負責響應故障求助”這一問題困惑不已。
從目前的狀況看，似乎總是能找到這樣或那樣的團隊負責提供應用故障服務，但是最后的結局往往是所有應用相關的開發團隊都被扯進來，圍繞糾纏不清的責任問題一籌莫展，問題的根源卻無從確認。
SOA架構擁有太多處于移動狀態的組件，因此，順藤摸瓜找到服務故障發生的根本肇因并不是一件容易的事情，更何況與此同時SOA還是一個由多個相互關聯的層組成的架構，這更增添了查錯的復雜性。
海福納認為，目前的大部分SOA管理工具必須進行有針對性的改進以應付這種尷尬局面。SOA管理工具必須具備鎖定深層次服務管理問題的能力。應該說，現有的SOA管理工具在定位問題的發生方面做得不錯，它們大都能在問題發生時通過一項服務提醒CIO，即使故障產生的環境非常復雜。比如在Java、.NET、消息中間件或者是遺留系統接口內部這類環境，這些管理工具仍然能夠迅速發現問題。
但是，僅此而已。
CIO們被告知系統中產生了一個故障，“好吧，接下來問題來了，SOA服務產生了問題，我們該向誰撥打這個求助電話呢？”海福納說，面對實施過程復雜、需要由多個團隊協作的SOA架構中產生的問題，每個團隊都會龜縮在各自的陣地中大喊：“這不是我的錯——我負責的部分工作得很好！”這顯然是CIO們始料不及，卻可能得到的唯一答案。
“這是因為每個人的眼界都被限定在他們自己負責的那部分基礎架構工作里，而這恰恰是SOA架構的特色之一。”海福納說。
那些服務管理達到一定深度的CIO們目前面對的現實狀況很不樂觀，為了解決這一問題，SOA的管理策略和解決方案必須重新進行調整，以幫助他們解決那些深層次服務管理問題。
海福納認為，SOA管理方案應當從多個方面調整各種服務之間的關聯，比如為消息添加更多的標識。這樣一來，服務中產生的問題可以更容易被獨立鑒別出來，CIO們也更容易判斷應當向哪個開發團隊求助。
海福納還指出，通常，SOA管理解決方案的眼界未能上升到整個SOAP界面。但是，即將涌現出的新一代管理工具必須站在整個服務界面的高度審視底層的數據庫、服務和消息層。
“你所購買的SOA管理解決方案，必須能夠處理執行復雜服務的SOA底層服務需求。海福納說，這一任務可能細致到涉及調用Java消息服務、MSMQ、Java RMKI或CORBA等一系列服務，這背后甚至需要一個專門的ESB或應用服務器予以支持。
對此，海福納對那些未來希望基于SOA架構搭建應用的CIO們提出了自己的建議。建議之一就是忠告他們充分理清自己的SOA管理策略。他認為，在CIO開始考慮該選用那種SOA管理工具之前，應該首先搞清楚你打算怎樣做好SOA管理。CIO們將不得不深入了解各種技術，了解自己企業將要實施的SOA管理將會復雜到何種程度，了解SOA解決方案是否能夠幫助自己管理跨技術平臺的服務以及了解SOA管理方案是否能與現有SOA的復雜度匹配起來。
此外，一個稱職的CIO必須站在整個SOA管理全局的高度，著手建立深度SOA監督和管理機制。這套機制應滲透到架構設計、服務組件和服務接口背后的一切細節之中。
總而言之，在尋求任何SOA應用解決方案時，CIO們必須將深度服務管理的理念牢記在心。
AlphaFlow BPM工作流程管理平臺
電話：400-888-6861
//qdhaitiansuji.cn/
