下面我們來看看面向服務的設計，SOA之 所以在實踐中難以實施的關鍵癥結在于面向服務分析設計并沒有形成統一的指導路線。而面向對象技術之所以有現在的普及，得益于各種開發過程的方法論，比如 RUP，XP等。但現階段對于面向服務的分析設計卻沒有成型的指導出現。當然筆者也不排除一些有經驗的技術作家有寫出來，但畢竟沒有形成知識系統和知識體 系。所以，開發者有些彷徨，想利用SOA的好處，但又不知道如何去做。其實隨著SOA技術慢慢在案例中使用，部分敢于探索的技術作家的行文中，偶爾給出一絲SOA技術的分析設計經驗之談。
任何一種技術的出現，其實都是對開發內容進行相關分類和歸類，以便減少代碼冗余，增加代碼復用的機會。所以我們在做面向服務的分析與設計工作時，也應該做相應的分層歸類工作。本人在《面向服務設計原則遐想》中提到
業務流程層 聯合運用下層服務接口層
服務接口層 作用是起到封裝抽象下層應用邏輯，對上層提供接口
應用層 如：應用A、應用B等
這個還處于高層抽象的分層，我們的關注點應該在服務接口層，需要繼續細分該層。暫且將該層分為
編排服務層
業務服務層
應用服務層
通過這個比較粗略的分層，可以看出各個服務層有了上下關系和歸類條件。具體就是：應用服務層放一些公共的、與解決方案無關的工具服務，比如負載均衡服務、 或者是專門用于向員工發送短信息的服務(它會被多處服務所調用)等。業務服務層則放一些有業務含義的原子性業務服務，所謂原子性業務服務就是不可再分解的 業務服務，其中的分析建模技術包括“按業務實體進行分析和建�！焙汀鞍刺囟ㄈ蝿者M行分析和建�！钡膬煞N方式。一般來說“按業務實體進行分析和建�！北取鞍� 特定任務進行分析和建�！狈绞绞沟梅⻊盏膹陀脵C會更多些。畢竟“按特定任務進行分析和建�！钡姆绞降玫降姆⻊兆匀皇菨M足特定任務的大的子流程，含有了業務 流程，其實業務服務層如果嚴格來說只能包含業務實體，而不應該包含業務流程，因為業務流程將在編排服務層里進行歸類。
這里自然有個難點，就是我們做純粹的面向服務分析時，是要求自頂向下分解，而要求實現SOA承 諾的服務可復用性是核心，必須保證分解出來的大部分服務要有機會復用，而我們知道原子性服務的復用性機會自然更大，然后才可以隨著需求的變更來組合現有的 原子性服務來實現企業業務敏捷性。這種自頂向下分析，自下向上復用的現狀幾乎把我們搞糊涂了。所以將服務接口層細分為更為具體的三層意義重大，否則業務流 程與業務邏輯單元都揉在一塊，自然難以提高復用率。
現在已經粗略地談到了面向服務的分析設計，那么與SCA有什么關系。SCA其實為不同粒度的復用提供了條件。
看看下圖先
圖1
SCA里的composite與component是核心概念，具體可以說component是可以設計為原子性服務的載體，而利用composite來做組合性服務的載體，來復用低層component的服務功能。同時SCA認為粗粒度的流程服務也可以用來作為基石來組合出其他的component與composite，所以BPEL也是component的一種實現方式。
如下圖
SCA從不同的粒度復用方面提供的益處得歸因于它的遞歸復用模式，這也與面向服務的分析設計方式有一定的映射，便于自頂向下或自下而上的分析設計工作。SCA除 了這些外，最重要的則是統一了各種不同語言實現的規范，同時利用現階段比較優秀的IOC，DI原則來管理服務之間的引用關系，最大程度地支持面向服務開發 模式中對服務的測試，當然也是便于服務功能復用了。而服務功能復用的先決條件是服務發現，如果服務都發現不了如何復用，則塊工作也是SCA的重中之重。自然，將通訊框架不僅僅局限與Web service的通訊框架，支持眾多的binding類型，將通訊的代碼量減至最小，也為服務的復用提供了前提條件，讓開發者與分析設計者更能集中精力于業務建模，當然也一定程度增加了代碼的復用性。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
