我們正處於轉向網路中心平台的轉換過程的最初階段，這個過程漫長而又不可避免。在如何構建應用程式和分配支援業務需求所需的開發勞工這兩個方面，企業應用程式架構師和開發人員都必須採用新的思維模式。
面向服務架構（ soa ， service-oriented architecture ）是建立靈活、可適應和分布式計算環境的一種應用程式設計風格。為了將應用程式功能設計為共享的、通用的服務， soa 定義了一組規則、模式和實踐。最佳實踐使得開發人員意識到 soa 對最大限度地提高服務共享、重用、靈活性和互操作性都有好處。服務設計實踐使得公司能夠建立更靈活的架構，這些架構可更容易適應變化的業務需求，同時縮減開銷。有 5 個主要設計主題是開發人員和架構師必須採用的：共享和重用、具體化（ externalization ）、松耦合、互操作服務合同和復合應用程式。
soa 更多時候與思維模式有關，而不是與技術有關。首先，開發人員必須接受這樣的看法，即重用現有服務要比從頭構建這些功能好。在沒有事前存在的服務可用的情況下，開發人員應該實現該服務，這樣其他開發人員才可能重用它。開發人員必須經常考慮可重用性和互操作性。
構建業務流程
客戶 / 伺服器架構與 soa 之間的真正區別在於如何分解元件相互依賴關係。在客戶 / 伺服器架構中，焦點是構建乙個特定應用程式，並將該應用程式分解成邏輯元件。在大多數環境下，開發人員完全期望實現整個應用程式。在 soa 中 ，焦點是構建可重用服務，然後組合這些服務來實現業務流程。乙個給定服務也許可以用在任意數量的應用程式中。在 soa 中，開發人員期望重用盡可能多的現有服務，並且只實現編制業務流程所必需的**。
每個服務都應該實現一項特殊的業務任務，並相對自治地進行運作。開發人員可將這些服務組合或重新組合成編制好的應用程式，實現各種業務流程。通過與適當的基礎架構結合， soa 使得 it 系統能夠對變化的業務條件作出迅速響應。核心開發人員將把業務邏輯和基礎架構服務作為可重用元件來構建，與此同時，開發人員的工作將更像是構建承包商，通過使用標準化服務作為構建材料來組裝（然後重新建模）面向過程的系統。
通用服務的理念是可以由多個應用程式重用，而不是為每個應用程式例項重新建立乙個通用服務，這也正是 soa 的本性，但也帶來了一些挑戰。乙個特定服務實現可能在安全性、可靠性或事務等方面要求不同的操作語義，比如，根據使用的應用程式上下文來要求語義。在傳統應用程式架構中，開發人員通常在應用程式**內實現這些操作語義，這降低了（如果說沒有消除的話）服務的可重用性。
soa 通過具體化操作語**決這類問題。而不是將安全語義（諸如身份和權利管理）直接應用到服務中，比如，開發人員根據指定特殊服務在特定應用程式上下文中所需的安全語義的說明性策略，依賴於增強身份驗證和授權規則的外部通用安全框架使用語義。同樣，開發人員沒有將自己的事務語義構建到服務中，而是依賴通用事務框架，而這些又再一次取決於說明屬性。
因此，重用服務的能力成指數增長。隨著新用案的增加——這可能要求不同的安全和事務語義——外部事務和安全框架很容易適應新的用例，無需改變服務**。
以這種方式， soa 通過分隔業務改變了開發人員之間的勞動分工。它還減少了開發工作量，並產生更加健壯的應用程式。基礎架構程式設計需要許多不同於業務邏輯開發的技巧。業務開發人員沒有必要是安全性、可靠性和事務方面的專家。考慮到這些技術的複雜性，業務開發人員犯錯誤的可能性極其高。類似地，安全專家也沒有必要是清單控制或工資單處理方面的專家。
通過將業務開發職責從基礎架構開發中分離出來，每一類開發人員可專注於他們最擅長的工作。面向業務的開發人員可以充分利用那些懂得如何實現複雜基礎架構服務的程式設計人員更技巧化的系統級工作。
實現分離
在 soa 中，實現應用程式不同功能部分的服務之間的聯絡是松耦合的——這意味著乙個特定服務對環境中另乙個特定服務沒有強烈依賴，松耦合通過一致化以下設計實踐來實現：無狀態互動、抽象服務合同以及粗粒度（ coarse-grained ）服務介面。
通常，服務互動是無狀態的和非事務性的。開發人員必須使用不同的技術（比如可靠的非同步訊息傳遞）來管理松耦合架構中的狀態和事務。
松耦合服務可以將服務外部介面的外部介面與其內部實現分離。在松耦合環境中，服務之間的互動是通過虛擬邊界發生的，虛擬邊界是由像 web 服務描述語言（ wsdl ， web services description language ）這樣的服務合同定義的。這些服務合同只公開該服務願意授權給其他服務的那些行為、邏輯和上下文引數，而保持服務內部實現其他所有方面的不透明。分離允許改變平台各種功能的內部實現，同時最大限度地減少修訂相應外部介面的需要。通過在中介軟體中實現資料對映和轉換層可以完成這一分離。
抽象服務是通過使用以下設計開發方法來建立的：按業務流程粒度定義服務；通過標準、面向文件的方法，特別是簡單物件訪問協議（ soap ， ****** object access protocol ） document/literal 風格介面，來暴露服務功能；通過用於輸入和輸出文件的標準的、意見一致的模式，來實現服務間的端到端語義互操作性。
粗粒度介面涉及到定義一些服務合同，這些服務合同從大量功能中抽象本地物件模型和介面。通常，服務之間的粗粒度介面涉及「 chunky 」會談，它們將幾種功能呼叫和響應打包成更少卻更大的訊息。與之對比，細粒度服務介面通常使用「 chatty 」會談，它們涉及客戶與服務之間的更多更小的訊息（參見圖 1 ）。
圖 1. hunky 或 chatty
服務之間的粗粒度互動涉及一些「 hunky 」會談，該會談將幾種功能呼叫和響應打包成更少卻更大的訊息；然而，細粒度服務介面通常產生「 chatty 」會談，該會談涉及客戶與服務之間更多更小的訊息。
另乙個最佳實踐是定義 web 服務——因此，還要定義相關的 wsdl ——以便與業務流程中的活動和子流程的粒度相一致。開發人員應將 web 服務設計為粗粒度的、離散的任務或編制，它們中的每乙個都擁有乙個業務流程或重要子流程。用這種方法，架構師可以進化平台底層的那些服務，而無需更新相應的 wsdl 服務合同。
因為 soa 的乙個關鍵目標是建立乙個統一所有應用程式組合資產的完整架構，因此 web 服務開發人員必須小心不要對映平台的本地物件模型、元件、 api 以及它們的 wsdl 中的其他工件。當開發人員從特定於平台的物件模型中自動生成服務定義時，他們不經意地在公開的 wsdl porttypes 中構建了平台的本地物件模型和方法。
相反，互操作 web 服務一開始就應從頭開發 wsdl ，並按以下的方式來定義 wsdl ，即其元素不必一對一地對應於底層服務平台的物件模型、方法和其他工件。根據外部互操作合約， wsdl 必須通過更改底層應用程式和平台來保持穩定。
復合應用程式
在 soa 中，應用程式並不真正由層組成——至少與客戶 / 伺服器應用程式架構對它們的定義不太一樣。應用程式由一組松耦合的服務組成。每個服務作為另乙個服務的完全對等實體來運作，服務由通訊部件連線。
服務可以自己完成整個任務，或者它可以呼叫其他服務來執行各種子任務。呼叫其他服務的服務成為了其子任務的控制器。復合應用程式由乙個控制器元件組成，該控制器呼叫一組適當的服務來完成期望的業務流程。
向面向服務的思維模式轉換不可能一蹴而就。各團隊應該建立以共享、可重用性和互操作性為中心的設計開發準則。這些準則應該將重點放在定義與應用程式分解相關的策略、模式和 wsdl 的定義和設計模式方面。此外，應該部署開發過程和相應的工具，以確保與架構原則的一致性。
關於作者
chris haddad 是 burton group 的實習經理和高階顧問。您可以通過 chaddad@burtongroup.*** 與 chris 聯絡。
原文出處
開發人員的開發效率
影響開發效率的因素，總結有五大方面 任務不明確 流程不順暢 需求變更多 責任心不夠 能力有瓶頸。針對這些因素，分別可以從以下五個方面來優化和改進。制定清晰的規範尤其是開發規範。無規矩不成方圓。營造良好的團隊文化氛圍，人性化的管理方式。愉悅狀態下的工作效率遠遠高於抑鬱狀態下的效率。定期舉行技術分享交流...
開發人員的七種心態
本文擷取自 膘叔 簡單人生 原文標題 開發人員的七種心態 支付寶楊雲 url thinksite舉辦的技術交流會，支付寶架構師楊雲如是說 1 開發者應當 2 3 建立完善的學習體系。當你看到或者搜尋到你需要的 或者程式時，不應該存著拿來主義，而應該做到 4 5 不要錯過向高手學習的機會。記住，6 7...
開發人員眼中的LINQ
開發人員眼中的linq 微軟講師 張義先 在今年的三月份 微軟發布了最新一代的開發平台 visual studio 2008.在visual studio 2008 中提供了太多的新功能與新特性 這些新功能與新特性都極大地提高了開發人員的效率.提到 visual studio 2008 的新特性就不...