Web服務是為透過Web進行資料交換定義的標準。這並不是說Web服務將暴露給互聯網，只是有一套許多產品支持的一致同意的「Web標準」。當決定採用哪一種標準的時候，最值得考慮的常常是技術人員提出的建議。
他們可能會依序向你推薦一個最容易實施的標準，能夠得到最廣泛的技術支援的產品和最有可能在你的環境中很好地工作的標準。為了有一個能夠經受時間的考驗並且在為來能夠繼續擴展的成功的SOA實施，所有這三個因素都是極為重要的，互通性是極為重要的。
WS-I
Web服務互通組織(WS-I)專門制定Web標準的最佳做法，以確保不同作業系統、平台或程式語言的互通性。 WS-I負責定義Web服務安全和Web服務處理技術規範等最佳做法文獻。這些文獻幫助開發人員和企業符合其他人正在採用的做法，並保證戶操作性。
WS-I也發布技術規格、測試套裝軟體和如何部署這些協定的樣本。實際上，WS-I是由微軟和IBM等許多機構組成的一個管理機構，其任務是推廣互通的Web服務。
使用協議
Web服務依賴協定保證通訊是有意義的。服務之間發送的資料內容必須是先前同意的，以確保雙方都能知道收到的內容是什麼。 SOAP是交換資料時應用最廣泛的協定的一個例子。 SOAP使用XML程式語言，讓雙方都能解碼傳送的內容並且格式化來回傳送的訊息。
說明
我們很快就會介紹一些架構，還要參考一些Web服務協定。不要混淆這兩項內容是很重要的。所以下面簡單介紹一下。
REST和RPC等軟體架構不是協定。它們是規定如何實施協議的方法。
WSDL(Web服務描述語言)是用來以格式化的方式描述一個特定的Web服務的語言，以便應用程式能夠解析這個服務。 WSDL本身不以Web服務互動方式提供任何功能。
SOAP、XML-RPC或DCOM等協定本身確切地定義瞭如何傳遞訊息以及一個程式如何理解它收到的資料。
SOA中有兩種主要類型的架構：RPC系列的協定和具象狀態傳輸(REST)方式。
RPC
遠端過程呼叫(RPC)方式允許程式設計人員在一個系統上編程的時候能夠像「呼叫」本地資源一樣呼叫遠端系統的資源。 RPC式的服務的缺點是人們傾向於像使用他們熟悉的指定平台上的程式語言那樣使用這種方式。如果與本地的過程相同的話，它甚至很容易調用一個遠端的過程。
這個邏輯違反了「鬆散耦合」的概念。鬆散耦合概念實際上意味著遠端過程不應該依賴任何特定的作業系統或程式語言。
SOAP是XML-RPC的後續協議，只是在XML中包含其資訊的一個遠端過程呼叫。 SOAP使用HTTP協定發送數據，這是很好且很簡單的，但是，確實存在一些缺點。儘管如此，最近大多數Web服務仍使用HTTP協定進行通訊，因為它們都是使用SOAP協定建立的。
REST
具象狀態傳輸(REST)方式從根本上是與遠端過程呼叫是不同的，因為它工作的層次不同。一個REST呼叫看起來就像是任何透過HTTP協定的其它Web請求，而RPC呼叫看起來就像是一個標準的功能呼叫。 REST的重點是用穩定的資源操作，而不是單一的信息，從而產生更標準的和廣泛理解的互動方式，就像HTTP協定本身一樣。 REST處理簡單資料的傳送塊，而RPC傳送複雜的過程。
使用REST還是RPC
是否使用REST的問題肯定是一個好問題。它好像是未來的方法。但是，你的SOA需要結合到你目前使用的每一個軟體。 REST的應用程式一直很緩慢，主要是由於Web服務的支援。雖然一個REST系統能夠使用WSDL來描述一個在HTTP上的SOAP訊息，但是，還沒有足夠的支援來真正使用它。例如，如果不安裝插件模組，Apache甚至不支援使用REST所需的方法。
還有一些不屬於Web服務家族的其它標準。但是，正如你所預料的那樣，這些標準並沒有得到廣泛的支持。 Jini、WCF和CORBA等就是一些例子。當一家廠商要向你提供僅支援上述技術之一的產品，你要馬上跑開，而不是走開。 Web服務目前的到了廣泛的支援。 Web服務的應用只會成長。 SOA本身據說是新的、不穩定的和有風險的。但是，當你選擇一個得到廣泛技術支援的合適的Web服務標準時，這些風險基本上可以緩解。
最後，堅持在某些類型的RPC式的系統的基礎上使用老式的SOAP是目前使用Web服務建立SOA的一種可行的機制。如果你這樣做，你就可以大幅減少鎖定廠商的機會。