據有關報道：作為國內實施服務導向架構(SOA)的先行者，中國外運股份有限公司(下稱中外運)2年前就在其核心業務系統“海運船貨代系統”實施了SOA的架構。
　　采用SOA架構使得中外運構建這樣復雜的業務系統變得更加靈活，從而更快地響應業務的需求。
　  “海運船貨代系統”是中外運的一個核心業務系統，有將近200多家分支機構、上萬名業務人員都在使用這個系統，涉及的營業額每年達上百億元之巨。
　　由于中外運不同分支機構、不同地區的業務不盡相同，以及各地海關、港口的要求、流程有所差異，所以各地分支機構對于信息系統的要求也不完全一樣。中外運原來的業務系統就是由各地30多個不同的系統“拼裝”而成的。但隨著業務的發展，這種系統“諸侯割據”的局面必須改變，否則會越來越影響數據的及時傳輸和共享。
　　中外運決策部門和IT團隊經過討論，認為對這么多基于異構平臺的系統進行集成的代價太大，最后決定重新開發一個統一的核心業務系統。這個系統要照顧到各地業務模式的差異和需求的變動以及今后的可擴展性。中外運信息管理部負責人說：“這是我們最后選擇SOA的根本原因。”
　　事實上，中外運采用SOA架構和編程是在2004年春節后。之前的一年，有60多人的IT團隊一直在進行業務梳理、需求分析以及架構討論的工作，他們同時還請了惠普公司(HP)作為咨詢顧問。當時SOA還沒有像現在這樣被炒得熱火朝天，但是需求分析的最后結果是只有實施SOA，才能解決開發復雜系統所面臨的各種問題。
　　據介紹，“海運船貨代系統”涉及的業務、用戶比較多，既有內部的也有外部的應用，是一個相對復雜的系統。實施SOA的架構后，不同系統、不同模塊之間的關系被統一為“請求和服務”。系統構建者可以只關注每個功能點及其提供的服務，而暫且不必考慮模塊相互間的關系，避免了系統由于復雜而出現的混亂。另外，由于系統工程浩大，“海運船貨代系統”由不同的人開發不同模塊，相互之間協作比較困難。SOA的架構提供了統一的軟件工程標準，使得不同模塊開發人員之間的溝通更加容易。還有重要的一點是，中外運各地的業務模式不完全相同，往往80%～90%的業務相同，還有10%～20%的業務卻不相同，甚至不兼容。應用SOA就可以在已經開發的功能模塊上做一些修改，從而減少很多重復的工作。
　　實踐證明，中外運選擇SOA的架構是正確的。目前“海運船貨代系統”已經在中外運的大部分分支機構上線并使用，成為該項業務的有力支撐。張思宇表示，隨著分支機構擴展或者業務變化，需要對系統進行相應改變時，他們就不需要像以前那樣重新寫編碼，只要把現成的相關模塊做一些修改，就可以封裝成新的服務。
　  作為中外運實施SOA的負責人曾先后被幾家軟件廠商邀請參加相關SOA會議，當時他聽了半天，也沒聽明白廠商所講的SOA到底是怎么回事；而他在某次會上的演講，也讓下面的聽眾面面相覷，小聲嘀咕“怎么和廠商說的SOA似乎不是一回事”。
　　事實上，中外運在搭建該系統過程中，并沒有購買任何SOA廠商的產品，整個系統都是按照SOA的架構自己開發的。張思宇表示，兩個應用系統或功能模塊之間在搭建的時候也可以按照SOA的架構，相互注冊服務，而不需要再通過中間平臺。軟件廠商的SOA產品類似這樣的中間平臺，更適合已有現成應用系統的企業。這樣的企業通過使用廠商的SOA產品，實現SOA的架構會更容易。
　　先將業務流程和需求梳理出來，然后做出一個個服務模塊，這種事先把系統功能完全抽象成SOA模塊的做法在企業中幾乎很難實現。尤其對于復雜的業務來說，工程過于浩大。中外運的做法是，先做出各個功能之間耦合比較緊密的程序，然后將程序切割成小塊，每一塊再做一些相應的修改，形成耦合比較松的關系。
　　盡管SOA給中外運的核心業務系統帶來了更大的靈活性，但中外運信息管理部負責人并不主張所有的企業信息系統都“SOA化”。他表示：“SOA可取之處很多，但也有一定的弊端”。最大的弊端是資源代價大，程序復雜，程序運行中的一些步驟會耗用大量的資源。另外，SOA項目周期相對較長，投入較大，短時間內不一定能看到回報。所以，企業的應用程序如果不是很復雜，就不一定要實施SOA。 “企業一定要清楚，為什么要實施SOA，是否有這個需求。”