治理是soa明確的乙個要求，你需要乙個能夠跟蹤、安全、界定和維護服務的地方。於是出現了兩種截然不同的soa治理方法：設計時間治理和執行時間治理。 多數
soa技術在soa範圍內都具有一定的價值，但隨著我們越來越了解soa實施和其成功的需要，許多現存的技術似乎都沒有帶來很大的作用。這是乙個在任何技術趨勢中都會產生的自然的技術正常化過程，soa也不例外。
治理是soa明確的乙個要求，你需要乙個能夠跟蹤、安全、界定和維護服務的地方。於是出現了兩種截然不同的soa治理方法：設計時間治理和執行時間治理。
執行時間soa治理，顧名思義更多的是關於運營要求的，包括實踐服務水平協議(sla)的能力，執行圍繞服務的政策，確保服務共同協作支援 soa，由此支援業務運轉。這個價值是清楚而明確的，因此多數執行時間soa治理產品很是暢銷，我將此技術看作是soa成功之關鍵。
設計時間soa治理，顧名思義通常提供乙個整合的登錄檔或儲存器，試圖從服務設計到部署階段而不是在服務執行時間對其進行管理。soa設計時間治理的關鍵元件大體來說包括：
登錄檔和/或儲存器，跟蹤服務設計、管理、政策和安全，並測試偽冒品
設計工具，包括服務建模、從屬跟蹤、政策建立和管理以及輔助服務設計的其他工具
部署配置工具，包括服務配置，通常是通過與外部開發環境**來實現
與測試工具和服務的鏈結，讓開發者或設計者建立乙個測試計畫和測試情境，而後利用服務測試技術
從本質上說，設計時間soa治理參與了從資料到服務的過程，收集關鍵資訊。因此你一般都從界定基本的資料架構和轉變為元資料的轉折點(或者是數 據提取)開始。進一步你會界定與資料和資料服務互動的服務，而後是更高一層的交易服務，你可以繼續定義流程或編排。所有的一切都在設計時間資訊的幫助下完 成，也就是在設計時間soa治理系統中發生。
問題在於設計時間soa治理技術能夠從何種程度上為上述真正的「設計」概念服務。多數是達不到這個程度的，因此許多soa設計師缺少更強大的特 色和只能，包括在soa設計和開發最佳實踐基礎上的真正建模和模擬能力。因此，多數都繞過設計時間治理直接進入執行時間這是有理由的。
像多數soa技術一樣，另乙個問題就是缺少設計時間soa治理的標準方法。當一些新的標準出現時，許多soa治理技術已經以自己的方式走上了各 自的方向，找不出兩個是相似的。因此，你不僅要挑選乙個工具，你還要選擇設計方式，而這個方式還不一定適合你的架構。我見過的多數soa專案都被設計來最 好利用傳統辦公司自動化工具，而這些專案似乎都還運作的不錯。這對於利用良好設計環境來說是件壞事。不過，好的環境也似乎不存在於現有設計時間soa治理 工具之中。
除此以外，大部分設計時間soa治理工具將大量的時間花在了對於執行時間問題的擔憂上，如服務水平協議(slas)，而絕少解決關鍵的設計時間問題。許多soa架構師對現有的設計時間選擇很失望，轉而採取電子資料表作為他們的設計時間工具。很明顯今天的設計時間soa治理廠商在這方面的理解和表現都非常不足。
那麼你要怎樣解決現有設計時間soa治理工具的問題呢?
首先,你應該得出乙個有意義的高水平方法,再解決如何將這個方法融合到乙個更大的soa設計和配置方**中去。現有的工具基本上不存在背景，也就更談不上價值了。
第二，要麼是執行時間工具要麼就不是，因此你要了解你的工具需要進入到架構哪乙個部分。我的建議是選擇一部分做好而不要所有的涉及，因為已經有許多不錯的執行時間soa治理工具了。
最後，收集並建立工具間一致的標準、技術和方法。目前這些標準、技術和方法是不一樣並且具有版權的，但在人們尋找長期戰略持久標準技術的今天這些是難以銷售的。
SOA 設計原理
最初的面向服務體系結構 service oriented architecture soa 的實現專案的經驗表明，諸如物件導向分析與設計 object oriented analysis and design ooad 企業體系結構 enterprise architecture，ea 框架和業務流...
Soa設計概念
快取，訊息，rpc，檔案，日誌，配置，資料流，監控，通知，服務發現 服務的註冊與發現 zookeeper 中儲存的資訊，如下圖 關於controller與action的資訊，在服務啟動的時候就已經註冊到服務中心去，儲存到資料庫中 系統名稱 controller action zk 上則保留 系統名稱...
SOA分析設計
soa分析設計過程 與ibm的soa架構師交流學習一段時間了，對soa的認識也比以前深刻了，通過ibm的架構師做的乙個簡單案例。我對soa的分析設計過程也有了一點認識。soa的分析建模過程是以系統的用例為指導 以業務流程為核心 以找出合理的元件為目標來進行分析建模的。ibm認為，soa的建模過程是個...