企業使用者對soa認識上還存在誤區，在這樣的狀況下部署soa，可能會把企業的業務帶入歧途，了解本文中的6個問題，或許可幫助cio避開soa部署中的陷阱。
圍繞服務導向架構（service oriented architecture，soa），企業使用者存在各種各樣模糊的認識，這些模糊認識很可能將企業的soa專案引入誤區。《資訊週刊》根據調研、訪談以及專家意見，整理出較為中立客觀的分析及看法，供企業使用者在了解soa時加以參考，以更明晰的思路決定自己的soa部署計畫。
1. 為什麼不同的人對soa有不同的解釋？
soa 的定義取決於你在組織業務中的角色。
對於業務執行人員，soa建立了企業希望向其客戶和合作夥伴或組織的其他部分公開的一組服務。對於it架構師，soa是一種體系結構樣式，此樣式至少需要有服務提供者、請求者和服務描述。對於程式設計師，soa是乙個由標準、工具和web服務等技術加以補充的程式設計模型。
當然，企業資訊科技系統及流程管理人員之所以存在似是而非的soa概念，還可能因為軟體廠商沒有向企業使用者解釋清楚soa的含義。比如，soa中的服務(service)並非我們理解的傳統企業服務，而是軟體開發的專業用語，指技術層面的、細顆粒度的功能模組，還遠未達到與企業業務流程直接對應的程度。軟體廠商在強調soa給企業帶來巨大商業價值的同時，並沒有具體闡釋這一點。
2. 業務流程管理(bpm)和soa是何關係？
bpm與soa既可以單獨部署，也可以組合使用。
如果企業的it系統比較簡單，企業規模比較小，用同樣的一組it人員就可以控制所有it系統，那麼，部署乙個不使用soa的bpm套件，就可以獲得快速建立、執行和監控/管理業務流程的能力，而不必部署soa。但是，如果bpm套件由乙個it小組部署，而同時使用來自另乙個it小組的系統服務，那麼soa就可以幫上忙了。
如果企業的it系統足夠複雜，可以考慮將bpm和soa組合使用，通常在soa上實施bpm解決方案可以獲得更大的業務靈活性。如果bpm專案達到一定的範圍和規模時效果才能顯現，最好先開發出bpm，而將soa元件留待以後考慮。
最好一開始就讓業務流程團隊和it架構團隊保持持續良好溝通，針對未來進行可行性規劃。例如，bpm套件本身應該能夠提供豐富的連通性，以便無需全面應用完善的soa來使得bpm執行，不要讓bpm與soa成為互不連通的兩套系統。
3. 「瀑布式」開發與迭代式開發哪個適合soa？
企業部署soa最好是通過迭代模型來實現。
迭代模型將標識一組對業務非常關鍵且價值高的功能來進行服務支援工作。此模型可隨後供後續服務支援專案和活動使用。如果採用傳統應用程式開發時使用的「瀑布式」開發方法部署soa，可能導致建立僅能部署一次的服務，而無法在以後對其進行重用。
使用迭代式開發部署soa，可通過允許組織逐步納入到系統中，從而減少出現業務故障的風險。同時，任何組織接受和容納更改的能力都是有限的，迭代式開發可確保引入新的流程和系統帶來的更改非常適應企業的容量，且不會在企業中引起大的混亂。
同時，在soa中，新功能並不一定總是僅受單個業務部門(line of business，lob)的約束，需要考慮很多跨組織的依賴關係，迭代式開發也有助於解決跨組織的協調。
4. web服務與soa是一樣的嗎？
web服務僅僅是目前最流行的soa實現技術，但並非可以用於開發soa的唯一技術。
soa與web服務(web service)的數量無關。對於soa來說，真正有價值的是對於web服務的再利用而不是web服務本身。即使將所有資訊科技系統都用web服務實現，也不見得就等於部署了soa。有些企業使用了太多的web服務來做同樣的it服務，結果部署soa的效果非常差。將web服務等同於soa，很容易發生在一些希望快速實現soa但是並未真正理解soa的企業身上。
很多soa專案都涉及到整合遺留資料，此類資料報含在使用mqseries和corba(common object request broker architecture)等「舊」技術的系統中。其中的許多技術都已針對soa進行了調整，不管有沒有web服務都可使用。事實上，企業可以只使用mqseries、corba甚至遠端過程呼叫(remote procedure call，rpc)技術就能實現soa。
5. 所有應用程式或環境都適合部署soa嗎？
不是所有的應用環境都適合部署soa，很多情況下，部署soa的效果可能會適得其反。
soa可以根據需求通過網路對各種應用元件進行分布式部署、組合和使用，從而滿足使用者統一服務介面、快速部署新業務等需求。但是，如果企業的it系統並不複雜，系統基本上都建立在同一架構上，整合系統並不困難，那麼實施soa並不能給企業帶來太多好處，反而可能會帶來負面影響。
專家認為，針對某些應用程式或it環境，soa可能並不值得推薦。比如，不需要元件或者應用整合的、獨立的、非分布式的應用程式；應用範圍非常狹小或者生命周期短的應用程式；建立在同一架構上的應用程式環境等等。對於一些企業來說，採用了單一廠商的技術和產品，擁有同一架構的it環境，就不需要那麼急迫地實施soa，或者實施的效果並不是很明顯。
有些企業很多年前就已經成形了業務支撐系統，雖然經過了很多次修修補補，但都一直在正常運作。專業人士認為，這種結構老、補丁多、又肩負重任的系統，與其用soa動大手術，還不如等這種系統壽終正寢，重新開發符合soa架構的新系統，進行自然淘汰比較好。
6. 企業應該如何著手部署soa?
部署soa應該制定明確的路線圖，循序漸進。
企業部署soa時最好先制訂乙個清晰的路線圖，然後從單個應用程式開始構建soa架構，可以先從比較簡單的應用開始。這樣，企業可以在做出全面部署soa之前先衡量投資回報率，並在出現大的問題之前積累足夠的經驗。
當企業計畫部署soa專案時，cio要注意各種細節，比如，**商提供的軟體是否支援web服務和soa；開發某些應用程式時，該應用是否要支援其他業務需求；哪些應用需要嵌入對web服務的支援等。如果企業大規模部署soa，還需要建立企業服務匯流排(esb)，通過esb提供服務請求。當然esb的建立也需要乙個過程，cio必須注意部署節奏。
儘管目前已經可以找到很多關於soa的知識，但部署soa仍然非常困難。其中最直接的原因在於soa需要企業部門之間的高度溝通，而且要求整個企業都為變革做好準備。變化帶來的問題解決之後，可能又會出現技術問題。因此，企業部署soa需要提前做好各種各樣的準備，並且有長期的詳細計畫安排。
SOA認識存誤區 詳解SOA企業部署的六大關鍵要素
企業使用者對soa認識上還存在誤區，在這樣的狀況下部署soa，可能會把企業的業務帶入歧途，了解本文中的6個問題，或許可幫助cio避開soa部署中的陷阱。圍繞服務導向架構 service oriented architecture，soa 企業使用者存在各種各樣模糊的認識，這些模糊認識很可能將企業的s...
企業SOA架構案例分析
面向服務的架構 soa 是乙個元件模型，它將應用程式的不同功能單元 稱為服務 進行拆分，並通過這些服務之間定義良好的介面和契約聯絡起來。介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平台 作業系統和程式語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行互動。傳統統的兩...
SOA改變的企業軟體生態
深色西服和t恤衫 諮詢公司的運作和軟體公司的運作，屬於兩個不同的世界，管理諮詢公司和會計諮詢公司在被分拆之前，原來是同乙個組織的兩個部分，它們一直都是華爾街資本體系的一部分，其核心是通過研究最佳管理案例，尤其是銀行，電信，製造業等傳統行業的實踐來為客戶提供諮詢服務。這是古典經濟學作用的範疇。如果說，...