從根本上來看，SOAP消息是從發送方到接受方的一種傳輸方法，但就象前面例子中闡述的那樣，SOAP消息一般會和實現模式結合，例如請求/響應。
SOAP的實現可以為特殊網絡系統的特有特征來優化。例如，在section 6中描述的HTTP binding將SOAP響應消息通過HTTP響應來傳輸，使用與相對應請求的同一HTTP連接。
SOAP結點可以是初始SOAP發送者，可以是最終SOAP接收者，也可以是同時作為SOAP發送者和接收者的SOAP中介。SOAP並不提供一個路由機制，曾因此SOAP需要識別SOAP發送者產生的SOAP消息應當通過哪些零個或多個SOAP中介被發送到一個最終SOAP接收者。
接收到SOAP消息的SOAP結點必須能夠實施處理、產生必要的SOAP錯誤和SOAP響應，如果合適的話還應當根據本規范的後續描述生成額外的SOAP消息。
當處理一個SOAP消息的時候，SOAP結點將被告知應當以一個或多個SOAP處理角色來處理，這些SOAP角色由SOAP actor名來標識，SOAP actor的名字是一個URI。每個SOAP結點都必須以一個指定的角色來處理，這個角色使用命名為"http://www.w3.org/2001/06/soap-envelope/actor/next"的SOAP actor來表示，同時可以按照需要應用零個或多個其他SOAP actor表示的額外角色。SOAP結點可以通過以匿名SOAP actor的角色來實施處理以使得自己成為最終SOAP接收者。當SOAP結點在處理一個SOAP消息的時候，其表現出的SOAP角色在整個處理過程中不得更改。這是因為本規范只涉及如何處理單個SOAP消息而無需考慮狀態，因此是否允許在處理單個SOAP消息的時候轉換角色是沒有意義的。
SOAP actor名字是用來識別SOAP結點的，並沒有與路由或者消息交換的語義相聯系。舉例來說，一個SOAP actor可以被命名為一個用來發送SOAP消息給適當SOAP結點的URI。相反，也有這樣一些SOAP處理角色的名字，這些名字或者直接和消息路由相聯系(例如,http://example.org/banking/anyAccountMgr)，或者和路由沒有聯系(例如，當一個消息頭被用來攜帶一個指示，該指示用來告知任何有關的軟件該SOAP消息是長期不變的，是能夠被安全的緩存和重用的，在這種SOAP消息頭中，一個URI可以用於標識“所有緩存管理軟件”)，通過名字使用這些SOAP處理角色也是合適的。
SOAP header條目包含可選的env:actor屬性(參閱section 4.2.2)用來把他們定位到合適的SOAP結點。沒有該屬性的SOAP Header隱含地定位到一個匿名的SOAP actor，這意味著他們被處理為最終的SOAP接收者。我們把SOAP actor屬性的值(隱含的或者直接指明的)作為相應SOAP條目(SOAP Header條目或者SOAP Body條目)的SOAP actor。
如果SOAP條目中SOAP actor(如果出現的話)匹配了一個SOAP結點的角色，或者是SOAP條目沒有actor屬性(包括SOAP Body條目)而該SOAP結點已經假設為匿名SOAP處理角色，這時我們就說SOAP條目被指向一個SOAP結點。
我們認為隨著時間的過去，會有大量的SOAP Header函數規范出現，而且每個SOAP結點都可以包含一個或多個處理這些擴展所必須的軟件。如果SOAP結點的軟件是完全兼容的而且實現了那些由條目中完整修飾的最外層元素名所傳遞的語義，我們說這個SOAP Header被一個SOAP結點理解。
當定位到一個SOAP結點的SOAP Header塊的mustUnderstand屬性為“1”，被指向的SOAP結點必須：或者依照由條目中完整修飾的最外層元素名傳遞的語義來處理SOAP塊，或者更本不處理SOAP消息而失敗(參見section 4.4).。
本節陳述了SOAP消息處理規則。除非另外規定，處理必須在語義上等同於分別執行下述的步驟，同時還必須按照給定的順序。注意到，無論如何在這個規范中都沒有阻止使用如並行、回滾或者其他可以在處理中提高靈活性的技術，只要所有的SOAP消息、SOAP fault和應用程序級的結果和那些直接執行下列規則得到的結果是相同的。
如果一個或多個定位到SOAP結點的SOAP條目有env:mustUnderstand="1"並且沒有被結點理解，則產生一個SOAP mustUnderstand錯誤。如果這樣一個錯誤產生了，那麼必須停止進一步的處理。
處理定位到SOAP結點的SOAP條目，如果需要，產生SOAP錯誤。當定義env:mustUnderstand="1"時，一個SOAP結點必須處理SOAP塊。如果沒有定義，那麼SOAP結點可以處理或忽略該SOAP條目。如果一個SOAP條目被處理，無論如何，這個SOAP結點必須理解該SOAP條目而且必須以和那個SOAP條目說明完全一致的樣式進行處理。而對於錯誤，無論是那種，也必須和SOAP條目的說明一致。有可能處理特殊SOAP條目會控制或者決定其他SOAP條目的處理順序。例如，一個SOAP條目可能建立一個SOAP Header條目用來強制按詞匯的順序執行其他的SOAP Header條目。如果沒有這樣一個SOAP條目，處理的順序是由SOAP結點來判斷的。當處理一個SOAP條目的時候，SOAP結點可以引用SOAP envelope中的任何信息。例如如果需要，一個緩存函數可以緩存整個SOAP消息。
如果SOAP結點是一個SOAP中介，SOAP消息的式樣和處理的結果(如果沒有產生錯誤)可以要求進一步沿著SOAP消息路徑送遞SOAP消息。這種接力轉遞必須以同樣順序包括從SOAP消息源來的所有的SOAP Header條目和SOAP Body條目，除了那些指向SOAP中介的SOAP Header條目，這些條目必須被移去(無論他們是否被處理，這些SOAP條目都將被移去)。附加的SOAP Header條目可以被插入在SOAP消息的任何一點，這樣被插入的SOAP Herder條目可能沒法和剛剛被移走的一個或多個條目區分開來(實際上是會將他們保留，但強調需要沿著SOAP消息路徑重新解釋每個SOAP結點)
所有的SOAP消息都是使用XML格式來編碼的(可參閱[7]以獲得更多的XML的信息)。
SOAP應用程序在生成由SOAP定義的所有元素和屬性的時候，應該包含恰當的SOAP命名空間。SOAP應用程序必須能處理其收到的消息中的SOAP命名空間。它必須丟棄那些包含不正確命名空間(參閱 section 4.4)的消息，並且可以處理那些不包含SOAP命名空間的SOAP消息，就好象他們包含了正確的命名空間一樣。
SOAP定義了以下的命名空間 (可參閱[8]以獲得更多的XML命名空間的信息):
SOAP信封的命名空間標識為 "http://www.w3.org/2001/06/soap-envelope"
SOAP遍序的命名空間標識為 "http://www.w3.org/2001/06/soap-encoding"
SOAP mustUnderstand fault的命名空間標識為 "http://www.w3.org/2001/06/soap-faults"
SOAP upgrade的命名空間標識為 "http://www.w3.org/2001/06/soap-upgrade"
而這些命名空間的模式文檔可以通過解析這些命名空間標識符來獲得。
SOAP消息必須不包含DTD，同時SOAP消息也必須不包含PI(Processing Instructions)。 [7]
SOAP使用局部的非限制的ID類型的id屬性來指定編碼元素(encoded element)的唯一標識，使用局部的非限制的uri-reference類型的href屬性來指定編碼元素的值的應用，以獲得與XML規范[7]、XML Schema規范[11]和XML Linking Language規范[9]的一致。
除SOAP mustUnderstand屬性(參閱 section 4.2.3)和SOAP actor屬性(參閱 section 4.2.2)外，一般允許屬性及屬性值自由地選擇是在XML實例中描述還是在XML Schema中描述，當然前提是他們具有相同的效果。也就是說，在DTD或模式(schema)中使用默認值或固定值定義在語義上等價於在實例中的定義。
SOAP消息是由一個強制的SOAP Envelope、一個可選的SOAP Header和一個強制的SOAP Body組成的XML文檔。作為SOAP消息的該XML文檔將在本規范的其余部分被引用。而本節的元素和屬性的命名空間標識是"http://www.w3.org/2001/06/soap-envelope"。SOAP消息應當包含如下部分：
一個SOAP envelope。Envelope是表示該消息的XML文檔的頂級元素。
一個SOAP Header。Header則是為了支持在松散環境下在通訊方(可能是SOAP發送者、SOAP接受者或者是一個或多個SOAP的傳輸中介)之間尚未預先達成一致的情況下為SOAP消息增加特性的通用機制。SOAP定義了很少的一些屬性來用於指明誰可以處理該特性以及它是可選的還是強制的。(參閱 section 4.2)
一個SOAP Body。Body為該消息的最終接收者所想要得到的那些強制信息提供了一個容器(參閱 section 4.3)。此外，SOAP定義了Body的一個子元素Fault用於報告錯誤。
語法規則如下:
SOAP
