模板
教程
環境
性能
功能
管理
SOA：人、流程以及導向
這些言論對于業務流程顧問或者軟件工程顧問來說都是很平常的。隨著數據管理或數據存儲數量的增長，他們會告訴你同樣的事情：客戶已經對service-enablement和面向服務架構(SOA)念念不忘了。
最近由SHARE(獨立主機用戶群體)發起的一項SOA調查結果顯示：四分之一的公司目前已投入SOA的努力，另外的三分之一則在考慮或在計劃實施SOA的過程中。
諷刺的是，許多專家指出：相對較少的實施者預計了在他們開始實施SOA之后，SOA負責人之間的矛盾將如何妨礙他們的項目。這種矛盾不僅僅是人與人之間和過程慣性的問題――即使這兩者都是SOA實施中可怕的壁壘――而是在于導向的不同。
Madsen的一個客戶最近展開了一項較為簡單的SOA實施行動。應用軟件架構師將此行動看作為堅定的企業服務總線項目(ESB)：他通過ESB的有色眼鏡看待這一項目，因此我們并不意外看到他制定了一個計劃使用企業服務總線作為該公司SOA行動的支柱。Madsen承認這并不是一個非主流觀點，但在這個公司案例中，一個以ESB為中心的觀點使得原本可以很簡單的整合項目變得復雜了。換句話，這個組織其實能夠在不使用全面ESB路線(這要求從最近收購的軟件供應商那里采購和實施ESB)的情況下就達到其所想要達到的結果。
實施ESB需要引入另一層的提取(如：在ESB本身可能消費的容器中打包或已經打包好的服務)并且需要組織除了其現存的應用程序服務器投資之外去使用一個品牌的應用程序服務器。除此以外，它也引入了一個充分的潛伏期時間：通信不能在服務終端之間直接進行，而要通過作為服務通信導管的ESB來進行。
Madsen說這只是諸多例子中的一個而已，他最近進行BEA AquaLogic ESB和Mule開源ESB的深入研究。
但是，他并不是最終否定SOA和ESB信徒。他指出：“在這種情況下，(使用ESB的情況)有一些非常復雜的東西本不應該如此復雜?！彼€補充道，ESB中的SOA使他想起了另外一種全面再利用技術：分布式對象系統(CORBA)。
那么，問題在哪里呢?數據聯盟專家復合軟件公司的市場副總裁Bob Eve認為問題應該歸結為導向的不同――如果不是理念的不同的話： ESB推行者來自火星，而數據管理領袖則來自金星; 反之亦然。Eve想要突出的一點是他們的思維方式不同。
Eve說：“在SOA世界中，存在著事務(導向)型人士、舊的企業應用系統集成(EAI)人士，而現在他們都是從事ESB的。他們同時是事務導向的也是業務流程導向的。在涉及到數據時，他們是單向讀寫的。這些開發人員使用的范例基本上都是過程邏輯的一種?！?/P>
Eve認為數據管理類型傾向于使用更廣闊的視角。數據界人士習慣于以數據集合的形式來進行思維。他們不撰寫編碼，而是在表格之間尋找連接點。這才是他們的思維方式。他們是屬于98%讀取類。Eve指出“我認為在SOA世界中發生的事情是這樣的，起初它確實是由那些嘗試將應用程序合成的人主導的――EAI人士。而目前，數據導向的人士也開始發表自己的聲音，這將帶來大的變化?！?/P>
他還說：諷刺的是Web 2.0類型，如那些與企業應用程序集成或企業數據管理都無關的開發人員。
Eve指出：“Web 2.0人士將問題看作一個他們想要加入的大的數據集。他們從一個很新鮮的角度來處理這個問題。他們并沒有陷入僅僅考慮事務類型或數據集的情況。他們也并不認為自己必須要擁有ESB，而只是在尋找一個最整潔、最有效的途徑來集成他們的資源?！?/P>
那些執行SOA策略的客戶在面對如何分配ESB支持與數據管理之間的鴻溝問題時必定會遭遇到不可避免的窘境。來自IT服務構造性企業的項目總監Brad Marshall說道，最突出的一點，你不能把一個重點的SOA項目完全就是單純的按照SOA的做法來做。當然，也不是因為周圍的人(或者僅僅只是其競爭對手)采用了更簡單的ESB路線所以就去采用ESB的做法。公司應及時的接受SOA所能帶來的轉變，例如它可能會需要更新或替換現有的資產或服務，它會計劃引入新的業務流程(或重組現有的工作流程)等等。
在另一個角度來說，在公司有一個明確的變化需求的時候可以考慮采取一個大的SOA項目計劃。即便如此，Marshall繼續強調公司需要清楚的對技術解決方案有一個準確的評估：正如你可能并不是完全有必要一個絕對成熟的數據整合平臺去構建一個全面的數據倉庫，不需要一個完全成熟的ESB應用(在保證必要應用的前提下)去實現SOA。他強調，在某些情況下之所以有些項目會出錯是因為在其實施過程中過分的沉迷于某些特別的技術和解決方案，不管是對于內部的成員也好或是對外的集成商也好，這樣一來會影響更多全面的功能選擇。
