因為大部分客戶-服務器應用邏輯駐留于客戶端，客戶端工作站負責了大量的處理。80/20比率常被作為一個經驗法則，按此法則數據庫服務器承擔了20%的工作量。盡管如此，數據還是常常成為這些環境中的性能瓶頸。
有大用戶量的兩層客戶-服務器解決方案，通常需要每一客戶建立其自身的數據庫連接。通信可預期是異步的，而且這些連接是永久的(意味著它們需要通過用戶登錄并保持活動直至其退出應用)。專有數據庫連接是昂貴的，并且資源需求經常壓垮數據庫服務器，給所有用戶以可觀的反應時間。
另外，假定客戶被分配以主要的處理職責，他們常要求重要的資源�？蛻舳藞绦型耆怯袪顟B的，并要消耗大量的固定PC內存。用戶工作站因此經常需要專門運行客戶端程序，以便所有可用資源能夠提供給應用。
SOA中的處理是高度分布式的，每一服務都有一個清晰的功能邊界和相關的資源需求。在面向服務架構建模技術中，對于如何能夠定位及部署服務你有很多的選擇。
企業解決方案包含多個服務器時，每一個都裝有Web服務并支持中間件。因此，對于SOA而言沒有固定的比率。服務可根據需要分布，而且在決定物理部署配置時，性能需求是要考慮的因素之一。
服務與請求者間的通信可以是同步的或是異步的。這一靈活性允許進一步改進處理，特別是使用異步的消息模式時。另外，通過在消息中放入更多的智能，可獲得消息層面的語境管理選擇。這促進了無狀態的及自治的服務本性，并進一步經歷減少對狀態信息緩存的需要。
技術
客戶-服務器應用的出現促進了第四代4GL編程語言的使用，比如Visual Basic與PowerBuilder。這些開發環境充分利用了Windows操作系統所提供的能力，來創建更美觀豐富、更具交互性的用戶界面。盡管如此，傳統的第三代語言，比如C++，仍在使用，特別是對于有更嚴格的性能需求的解決方案。在后端，主流的數據庫廠商，象Oracle、Informix、IBM、Sybase與微軟，提供了強健的關系型數據庫管理系統，能夠管理多連接，同時提供了靈活的數據存儲及數據管理特性。
SOA所用的技術集實際上并不象它所延展的那么多。舊版本的程序語言的更新版本，象Visual Basic，依舊能夠用于創建Web服務，且依舊可以使用傳統數據庫。盡管如此，SOA的技術版圖已經變得日漸不同。除了Web技術的標準集(HTML、CSS、HTTP等等)，當代SOA一并帶來了建立XML數據表達架構的絕對需求，還有SOAP通訊框架，以及服務架構所包含的永遠擴展的Web服務平臺。
安全
除了數據的存儲與管理以及嵌入存儲過程和觸發器中的業務規則，安全是經常在客戶-服務器架構的服務器層面集中處理的另一個部分。數據庫十分復雜，足以管理用戶帳戶及用戶組長，并將其分配到物理數據模型的個別部分。
安全也能夠客戶程序中控制，特別是當它與特定應用邏輯執行的業務規則相關聯時(譬如挑選用戶對部分用戶界面進行限制訪問)。另外，與操作系統級的安全協作可實現單點登錄，此時應用直接繼承操作系統的登錄賬戶信息。
盡管有人夸耀SOA的優勢，許多架構師卻羨慕客戶-服務器的安全性。企業數據經由單點鑒權而受到保護，建立了客戶端與服務器間的單一連接。在SOA的分布世界中，這是不可能的。安全變成一個重要而復雜的問題，與必需的安全措施程度直接相關。牽扯到許多典型技術，大多數包含在WS-安全框架中。
管理
客戶-服務器時代終結的一個重要原因在于相關分發的大量維護成本的增加，以及跨工作站應用邏輯的維護。因為每一個客戶裝載有應用代碼，每一次應用更新都要對所有的工作站重新分發軟件。在較大型的環境中，這造成了高度繁重的管理流程。
維護問題跨越了用戶端和服務器端�？蛻艄ぷ髡臼芴囟ōh境問題的支配，因為不同的工作站會安裝不同的軟件程序，或者可能購買不同的硬件廠商。更有甚者，還增加了對服務器端數據庫的要求，特別是當客戶-服務器應用拓展到更大的用戶基礎時。
因為面向服務的解決方案會有不同的請求者，它們還要受到來自客戶端維護的挑戰。同時其分布式后端要適應應用及數據庫服務器的擴展性，會引入新的管理需求。例如，一旦SOA發展為服務復用并成為多服務組合的一部分，服務器資源與服務接口的管理會需要強大的管理工具，包括私用注冊的使用。
文章來源于領測軟件測試網 http://www.kjueaiud.com/