soma
的三個階段：服務發現，服務規約，服務實現。（
soma
是將業務轉化到
it系統的方法）
（迭代的過程）
1.服務的發現：得到服務的候選者
採用自上而下、自下而上和中間對齊的方式，。
自上而下
（業務領域分解）方式從業務著手進行分析，我們將業務進行領域分解、流程分解，以及進行變化分析。
業務元件模型
是業務領域分解的輸入。根據業務元件模型的詳細描述，我們可以將業務領域按照業務職責細分為業務範圍，並直接其對映到
it範疇的子系統，實現業務與
it的無縫連線。
頂級的業務流程
是流程分解的輸入。將業務流程分解成子流程或者業務活動，逐級進行，直到每個業務活動都是具備業務含義的最小單元。流程分解得到的業務活動樹上的每乙個節點，都是服務的候選者，構成了服務候選者組合。在大部分情況下，服務候選者組合都是乙個很長的列表，加上自下而上和中間對齊方式還有可能發現新的服務，因此將服務候選者按照某種方式進行分類是一件非常必要的事情。業務領域分解的結果
——業務範圍是乙個業務概念，同時可以無縫對映到
it範疇，因此它是乙個好的分類原則。根據業務範圍，服務候選者組合可以被劃分服務候選者目錄。
變化分析的目的
是將業務領域中易變的部分和穩定的部分區分開來，通過將易變的業務邏輯及相關的業務規則剝離出來，保證未來的變化不會破壞現有設計，從而提公升架構應對變化的能力。變化分析可能會從對未來需求的分析中發現一些新的服務候選者，這些服務候選者需要加入到服務候選者目錄中。（現在不需要但以後可能需要的服務，提公升架構應對變化的能力）
自下而上
（已有資產分析）方式的目的是利用已有資產來實現服務，已有資產包括：已有系統、套裝或定製應用、行業規範或業務模型等。
通過對已有資產的業務功能、技術平台、架構以及實現方式的分析，除了能夠驗證服務候選者或者發現新的服務候選者，還能夠通過分析已有系統、套裝或定製應用的技術侷限性盡早驗證服務實現決策的可行性，為服務實現決策提供重要的依據。
中間對齊
（業務目標建模）方式的目的是幫助發現與業務對齊的服務，並確保關鍵的服務在流程分解和已有資產分析的過程中沒有被遺漏。
業務目標建模將業務目標分解成子目標，然後分析哪些服務是用來實現這些子目標的。在這個過程中，為了可以度量這些服務的執**況並進而評估業務目標，我們會發現關鍵業務指標、度量值和相關的業務事件。
結合這三種方式的分析，我們發現服務候選者組合，並按照業務範圍劃分為服務目錄。同時為服務規約做好其他準備，如：通過對已有資產分析進行的技術可行性評估、通過業務目標建模發現的業務事件等等。 2.
服務規約：定義實現服務的服務元件的細節，包括，資料、規則、服務、可配置概要、可能的變更，同時還會涉及到訊息、事件的定義和管理。
經過服務發現的階段，我們得到了候選服務目錄，接下來就需要決定暴露哪些服務。理論上所有的服務候選者都可以暴露為服務，但是一旦暴露為服務，該服務候選者就必須滿足附加的安全性、效能等方面的要求，企業還必須為服務的規劃、設計、開發、維護、監管支付額外的開支，因此我們會根據一定的規則來決定將哪些服務候選者暴露為服務。
這些規則包含以下幾個方面：
基於企業應用開發的經驗，我們還可以有其他一些方面的考慮。
在決定暴露特定的服務候選者為服務以後，服務規約還需要定義服務的訊息、非功能性需求以及服務之間的依賴關係、組合關係。
還包括服務屬性的描述（輸入輸出，安全約束，響應時間約束，業務規則，消耗等）
gSOAP學習體會
include soaph.h 得到存根程式 include sendemailbinding.nsmap 得到命名空間對映表 include include include soapsendemailbindingproxy.h using namespace std int main int a...
git 學習體會
下午頭暈呀。學而不思則則罔，看了好幾天git，隨便寫寫來整理下思路。這幾天主要做了3個事情，一是寫了20多頁的ppt 準備交流，乙個是看了progit的中文件，還有乙個是在stackoverflow上提了幾個問題。對git也算入門了吧，熟練掌握常用命令的含義和用法 不帶參的 知道了git的儲存和資料...
UI學習體會
很多時候自我感覺做好的一件事情，往往並不會得到別人的認可 經不起別人的推敲，總是自己被澆的狗血淋頭 很多時候，我們都沒有站在另外的乙個角度去看問題 也許不是你要做多少多少事情，關鍵是你要別人承認你的價值所在 今天上完ui作業點評後，才發現自己可以去石化了 很多資訊不是我們自我感覺好了就ok了 我們程...