提到Web服務的起源就壹定要先說壹說SOA（面向服務的體系結構），和很多具有劃時代意義的軟件技術壹樣，SOA的出現根本上也是為了解決軟件危機問題。做過項目的人都有過這種感受，隨著項目推進，模塊之間關系越來越緊密，任何壹個小的修改都可能引起整個系統的不穩定，而客戶需求偏偏總是在改變，結果是項目以差不多失敗的結果告終。
從（分布式）軟件發展的趨勢來看，C/S->B/S->SOA，模塊之間的耦合度是由緊密到松散的，松散的耦合有利於修改。我們常說的各種設計模式，其中大部分不也是為了降低類之間的耦合度嗎。
這裏我引用壹下IBM網站上對SOA的定義：面向服務的體系結構（service-oriented architecture）是壹個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立於實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種這樣的系統中的服務可以以壹種統壹和通用的方式進行交互。（全文）
說得通俗壹點就是，系統中分為三種角色：服務提供者、服務使用者和註冊中心，提供者發布服務到註冊中心，使用者通過註冊中心發現所需服務，然後與該服務的提供者綁定，並調用服務。
那麽Web服務和SOA是什麽關系呢，可以這樣說，Web服務是SOA的壹種實現，有點像Tomcat和JSP/Servlet規範的關系。SOA是壹個比較虛的概念，例如它只提出定義壹些接口和協議，那麽這些東西具體應該怎樣定義呢，Web服務就將它們具體化了：Web服務使用的協議都是基於XML的；SOA只說應該有三種角色，而Web服務裏這三種角色都有具體的實現方式。看到這裏妳應該會問，那麽SOA還有哪些實現呢？CORBA、DCOM和J2EE都可以算是，但我認為它們不能算很純粹，至少它們並不都具有中立的協議。
現在該用壹個具體的例子來說明壹下Web服務了，假設我們的系統中需要壹項功能是查詢當地的天氣情況（世界時間、貨幣匯率等等，都壹樣），顯然我們不會自己做壹個從氣象部門數據庫中查找數據的程序，這需要很多手續也沒有必要，更要命的是，這樣做會增加我們與氣象部門的耦合度。試想某壹天氣象部門的數據庫結構改變了，我們將不得不修改自己的代碼，如果他們忘記通知我們這壹改變，想象壹下客戶會看到什麽？
為了利用Web服務，我們從某壹註冊中心查找和天氣有關的服務，在結果中也許我們會選擇收費較低，或者收費稍高但更穩定和準確的服務。從註冊中心我們能夠得到所選服務的完整描述，其中包含了各種數據類型和調用方式，利用這些信息，可以使用工具生成這些必要的類，以及客戶端Stub，利用這個Stub就可以調用遠程的Web服務了。在我們的例子中，調用後服務提供者會返回壹個含有結果的消息，在我們的系統中可以從這個消息裏得到所要的結果，並顯示給客戶。這樣就形成壹個完整的Web服務調用。這種調用方式被稱為靜態調用，因為在Stub裏服務提供者的地址（被稱為調用端點endpoint）是寫定的，還有另外壹種方式被稱為動態調用，以後會講到。
那麽Web服務和以前的RPC（遠程過程調用）有什麽分別呢？RPC通常要求調用者和被調用者是同構的，即使用同樣的語言編寫，而Web服務沒有這個要求（訣竅在於使用了XML封裝消息），這就大大增加了靈活程度；另外，Web服務的調用除這種類似RPC的方式外，還可以是基於消息的方式，服務使用者可以只接收消息，或是只發送消息，在壹些應用中這種方式十分有用。
內容總結壹下就是：Web服務是SOA的實現，Web服務不是RPC。