新的服務應用程序架構是一種可擴展的中間層應用程序，可以為第三方應用程序或者服務提供數據或某種專業計算能力。新的服務應用程序架構能夠被服務器場中不同服務器所共享，具備一定的負載均衡的能力，該負載均衡可自定義。
全新的服務模型將更加靈活
服務將不再依賴於 SSP，而是相對獨立
Web 應用程序擁有更加寬泛的服務選擇余地
可對高能耗的服務實現更優化的負載平衡
既可依附於單獨的服務器場，也可在多個服務器場之間共享
所有服務器場均可專門用於服務托管
用於超高能耗型服務的成本投入可控，例如Web 分析服務、商業智能、搜索服務、Office Web等等。
以上討論過於直板，為了建立更加直觀的認識，我們從一個實際案例開始吧。
故事發生在某大型能源行業國有制造企業，該企業承擔了國內外眾多大型工廠、工程的設計和施工項目。它已經采購了SharePoint 2007，將為它的市場部、開發部、設計部提供門戶網站、項目管理、產品數據管理的解決方案。三個部門的需求和業務各有特點，又前后相繼，具體如下：
1、市場部
市場部包括項目的立項申請、以及項目執行過程中的保函、佣金、簽約資料、信函等文檔管理和成本測算管理。每個項目產生約數十上百兆的文檔。
2、開發部
開發部承擔報價設計、合同設計、以及交底文檔管理，合同設計過程需要進行簡單的管理。每個項目產生數百兆的文檔。
3、設計部
設計部承擔企業所有在建項目的初步設計、詳細設計、完工設計等工作，要求對設計過程中圖紙目錄、設計計划、設計師任務、設計工時、設計圖檔、設計更改、圖紙曬發進行有效管控。
系統將根據設計計划向任務負責人及時派發任務，提醒設校審人員在線執行校審工作，任務完成后，系統會自動生成工時單，要求設計部人員填寫相應任務所耗用的工時，由專業主管在線審核。設計部每年承擔的並行項目約有十余個，每個項目在完成后，產生約20-50G的各類文檔：Office、CAD、各種三維模型等等。這些文檔最終會形成一個可交付的結構化的項目成果庫。
考慮到本系統承擔了大量的數據存儲和計算工作，因此設計院購買了3台8核16G的IBM 服務器，以及統一備份管理的高速磁盤陣列。然后，組織人員使用SharePoint 2007 實施了以上解決方案，解決方案中包含了大量自定義的工作流活動、事件處理、Web部件、應用程序頁面。
服務器規划：一台SQL Server 報表服務器、一台作為應用服務器、一台前端服務器、數據庫服務器使用了企業的統一SQL Server 集群。
網站規划：
本系統上線不久，就遭遇了用戶較為強烈的不滿，尤其是市場部和開發部，由於這兩個部門的應用只是簡單的文檔管理和較少的工作流管理，他們反映新上線的系統還不如之前一家小公司實施的文檔管理系統響應速度快，這不合常理。
通過上面的網站規划，顯而易見，且不論服務器組合是否有優化空間，網站規划邏輯本身就很有問題：所有門戶和項目網站都放在同一個網站集中。
為什么說這是一個問題呢？我們可以通過SharePoint的幾個基礎概念來弄懂這個問題所在。
1、服務器場
將多台物理服務器組合成一個硬件資源池，從而實現單台服務器所不具備的處理能力。
2、Web應用程序
對硬件資源池的計算和存儲虛擬化，任何系統都離不開兩個方面：計算（CPU和內存）、存儲（磁盤）。SharePoint Web應用程序使用IIS來發布，使用W3WP的一個進程實例，內存上限一般設定為800M – 1G ； 它使用SQL Server來進行數據存儲。
可以回想一下SharePoint ”管理中心”中， Web應用程序的創建過程，指定一個應用程序池名稱，指定一個數據庫名稱（當然，一個Web應用程序可以包含N個內容數據庫，此處指的是創建的第一個數據庫名稱，一般名稱為WSS_Content_XXX），實際上可以認為是對計算資源和存儲資源的分配。
小結一下：一個Web應用程序只能有一個應用程序池（計算資源，有內存上限，尤其32位系統）和多個內容數據庫。
3、網站集
網站集是一堆面向具體業務應用的網站的集合。如果說Web應用程序還是對資源的分配，與具體企業業務沒有具體關系的話，那么網站集則是從Web應用程序分配的資源里面分出一部分，服務於某個具體業務需求。網站集在創建的時候，會默認創建一個頂級網站，以衍生出一些列的子網站，算得上是所有網站的父親、祖父、曾祖父……
一個網站集只能存儲於一個內容數據庫中。 但一個內容數據庫可以存儲多個網站集的內容。一個網站集只能屬於一個Web應用程序，也就只能夠使用當前Web應用程序對應的單個計算資源（一個W3WP，不超過1G的內存使用上限）。
4、網站
網站集中的一個具體應用的示例。
我們通過以上的介紹來分析一下該企業網站規划的問題所在。
首先，由於使用的是單個網站集存儲所有數據，就意味着所有數據都必須存儲在一個SQL Server數據庫之中。該企業設計部以10個年並行項目計算，10 X 20G = 200G。每年該數據庫至少多出200G的數據。而SharePoint 2007 推薦的單庫大小是80G，不超過 200G。實際上很多項目在完工后，都處於只讀狀態，但卻不得不參與數據庫的查詢分析，影響了數據庫的性能。
其次，由於設計部的功能使用了大量的計算資源，如原始CAD dwg圖紙的在線轉換可視化，產品結構基線分析等等。使得共用同一“計算資源”的市場部和開發部不得不忍受着資源被搶占的痛苦。
明白了問題所在，參考以上的幾個基礎概念，在SharePoint 2007下，我們可以將設計部放置在單獨的Web應用程序中，將市場部和開發部放置於另一個Web應用程序中，從而將雙方的計算資源獨立。此外，使用網站集來管理每一個項目，從而確保每個內容數據庫中容納不超過2個項目網站集。似乎一切都開始正常了。
但是也存在一些問題，譬如，由於存在兩個Web應用程序，在部門網站切換時，需要再次認證；在調用另一個Web應用程序數據時，需要額外的認證和設置等等。
在SharePoint2010 中，這些可以進一步優化，譬如我們看到的Office Web App服務，就類似於CAD文檔在線可視化的服務，在新的服務應用程序架構中，這種高能耗的服務被獨立出來了，可以使用單台或多台服務器，甚至一個獨立的服務器場為該運算進行服務。同樣，對於一些具備全局特點的數據，也可以通過服務應用程序來提供。
但是為了適應Sharepoint 2010的服務架構，我們提供一個A+B的加法運算服務，也需要編寫大量的代碼，使它能夠通過Powershell創建、在管理中心被設置，被Web應用程序關聯調用等等。所以，它是一把牛刀，非必要場合不要用它，畢竟開發者都是比較懶的。