實施SOA，技術不是問題，最大的問題還是管理和溝通(協作)。
實施SOA的話，我們需要重新構建一套基礎架構，提供統一的端點配置管理、異常管理、健康監控、契約協作平臺等。不然到最后的配置和管理將會很混亂。
我們不需要更多的服務器，但我們需要更合理的分配服務器。而且整個系統的部署架構可能隨著時間的遷移不斷調整的，合并壓力小的服務，拆散壓力大的服務。怎么做負載均衡，這都是一直調整的。
實施SOA需要開發人員有更好的意識，包括協作意識，包括架構意識。當然，也需要架構師能夠參與到每個項目中去，心中對業務有大局觀。
配置可能是復雜的，需要有工具來確保這個復雜的過程。服務和網站怎么配置是很重要的事情，需要架構師和開發人員討論決定，不是說隨便放上去能用就可以。
在做架構的時候要站在較高的角度來看，眼光要長遠，暫時的性能問題不一定是問題。按照網絡/磁盤/內存/CPU的層次來考慮。很多時候SOA和性能是有沖突的，就像不能一味覺得ORM性能不好就不去使用�？紤]80/20原則，任何東西滿足了80的應用就達到了目的，剩下的20進行特殊處理。
暫時就寫這些，大家拍磚。
補充幾點：
從服務契約設計上來說，應該讓這個契約盡可能獨立，不依賴于其它的契約。服務的調用過程不能依賴于服務本身的狀態，應該在任何情況下服務的作用不會由環境所變。
雖然說是內部實施，但最好數據契約的類型是標準類型，通用類型，原生類型，方便以后做開放API的時候真正實現對外的服務。其實SOA強調松耦合性，因異構平臺協作的需求產生，強調一切基于消息，無關服務平臺。
SOA的實現包括業務分析、契約規劃、服務管理、消費者管理、文檔管理、配置管理、迭代整合等重要步驟，不是說我要建立A契約就建立，我要消費A契約就消費，要體現在管理中。我一直覺得SOA不是組件升級到服務這么簡單，軟件開發流程、管理流程、設計分析方法、配置管理都會有巨大的改變，前期準備要充分。
在建立前期需要制作完成一個基礎的架構供開發人員使用。比如說是不是需要擴展VS內建的WEB引用，使得生成的客戶端代理包括異常處理、端點配置(從配置服務中獲取)等內容。非業務相關異常的收集和發送等工作應該是自動的，無需編碼。由于調用的復雜性，服務可能還會調用服務，在部署的時候配置問題很難察覺，所以其中的異常處理非常重要。
項目完成后的代碼審閱需要對項目中用到的服務進行逐一檢查，如果有改變需要在拓撲圖(推薦有專門管理軟件來維護這個拓撲圖，并且還能檢查各個節點的健康狀態)中進行修改。必要的話還可以為每一個節點實現信任機制，得不到信任的消費者將不能消費。甚至這個工具可以和SHAREPOINT結合，也提供文檔的管理。
最理想的方式是實現服務的自動部署，全部依靠管理工具來完成，因為在服務器上安裝Windows服務，需要復制文件、卸載原來的服務、安裝新的服務、服務運行賬戶的配置，如果服務達到上百個的話，部署的壓力也比較大。
最后，什么是SOA?個人覺得SOA是提供了系統級的松散組合和重用的基于消息的整合方案。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
