面向服務的8個原則
服務可復用 不管是否存在即時復用的機會，服務被設計為支持潛在可復用。
服務共享一個正式契約 為了與服務交互，只需要共享描述每個服務信息交換術語定義的正式契約。
服務是松散耦合的 服務被設計為無需緊密的、跨服務的依賴而交互。
服務是底層邏輯的抽象 只有經由服務契約所暴露的部分服務對于外部世界是可見的。契約之外所表達的底層邏輯是不可見的，且與服務請求者無關。
服務是可組合的 服務可能組合其他服務。這允許表示不同粒度的邏輯，并促進復用及抽象層的創建。
服務是自治的 邏輯由服務所控制，并位于一個清晰的邊界內。服務已經在這個邊界內被控制，并且不依賴于執行其控制的其他服務。
服務是無狀態的 服務應當不需要管理狀態信息，因此能夠其維持松耦合性。服務應當盡可能設計成無狀態的，即便這意味著要將狀態管理移至別處。
服務是可發現的 服務應當允許其描述被發現，并被人工和可能會利用其邏輯的服務請求者所理解。
這個8個面向服務的原則乍看很像我們熟悉的OOP啊，不過如果你把一個服務抽象成一個對象來看的話也就不難理解了。
下面介紹一下依據這8個原則構建的SOA的各個服務層：
1、連通性服務層
所謂的連通性是指對于原有系統的數據連通，由于原有系統不能提供一個具有通用性的數據服務，所以在連通性服務層的主要任務就是負責把原來已有的JDBC的，EJB的，webService的各種數據服務，封裝成具有統一標準的java pojo控件，然后其它的就可以方便，簡單的實現對數據服務的調用。
連通性服務層：
服務對象：需要獲得數據的對象         如業務層、表示層等
提供服務：可以操作原有系統的數據層   如對一個sap服務器進行操作、對一個DB服務器進行操作鄧
調用資源：原有系統的數據服務接口     如EJB、Hibernate，JDBC等
圖1：
在這里值得一提的是bea在使用workshop對于連通性服務層創建，非常簡單，完全圖形化的方式，只需簡單的鼠標拖曳，就可以實現服務控件的建立。
2、業務流程服務層
我們知道一般的業務系統都會有一些自由的業務流程的，那么如何讓這些原有的業務流程來提供給SOA系統使用呢？
在bea專家給我們演示的demo中，我看到bea的做法是把每一個流程節點封裝成了服務，這樣，這些流程節點每個都可以成為一個向外提供服務的服務者了。
業務流程服務層：
服務對象：需要流程控制的對象         如其他業務層，表示層等
提供服務：業務流程控制               如從a入口進入后是應該去b節點還是應該去c節點
調用資源：通常是連通性服務層的服務  
圖2：
在bea演示的時候對于業務流程服務層的構建依然采用的是圖形化的方式，這里值得稱道的是在使用圖形化的過程中，bea的工具還可以支持對于服務的格式轉換
3、服務中介層  
上面已經介紹了兩種服務層了，在soa中這兩層的調用不是簡單的上下層關系。在實際項目中，也許有的需求是需要流程控制的，但是也許有些需求是直接要求展示數據的，那么如何處理這兩種的需求呢。這里就是在soa中最重要的一個層了，服務中介層。很多人應該聽過soa中service bus這個概念。我之前一直理解為服務總線僅僅是為客戶端提供服務的，其實是不對的，實際上服務總線是一個用了穿起來各個服務層的，就好比是一個糖葫蘆，服務中介層就是中間的那根棍子。
圖3：
做為服務中介層來說，主要有兩種服務，一種是應用服務；另外一個是代理服務，用來對應用服務進行代理封裝的，是服務總線中向外暴露的服務。
4、表示層服務層
表示層服務主要和不同的客戶端有關，bea在這里的講述中由于時間緊張所以比較簡單。重點還是在演示他們可視化得頁面編輯。但是這里有點給我洗腦得就是，對于不同的客戶端所提供的服務是直接可以使用的，比如判斷一個用戶名是否合法，表示層服務不是返回的true，false，而是直接返回，“該用戶名可用”，“該用戶名已被占用”這樣的字符串。
關于表示層我就不再畫圖了，最后是一個整體的soa層次結構圖：