webservice主要採用了http協議,http是個基於tcp/ip的應用層協議:(注:現在的大部分webservice開發已經能很好的支援socket的實時通訊了.但http依然是它的精髓.)
http採用了"請求-----應答"模式;
http通訊是通過xml序列化通訊的......
http通訊過程:呼叫.asmx
控制代碼,xml
、xsd
、soap
和wsdl處理,
xml中主要提供的有三方面:(下面文章引自:
)個人感覺主要要掌握的是soap請求訊息和應答訊息的xml格式...
當.asmx控制代碼被http管道呼叫時，通過檢視.asmx檔案中的webservice宣告，確定檢查哪個.net類。然後它觀察到來的http訊息中的資訊，確定呼叫引用類中的哪個方法。為了呼叫前面例子中的add方法，http請求訊息應像下面一樣：
上面的http請求訊息中有兩條資訊可以用來確定呼叫類中的哪個方法：soapaction頭或soap體中請求元素的名字。在這個例子中，每種方法都指出了傳送者想呼叫的方法名。
.asmx控制代碼使用soapaction頭的值來實現訊息的分派。因此，.asmx控制代碼檢視訊息中的soapaction頭，使用.net對映檢查引用類中的方法。它只考慮標記了[webmethod]屬性的方法，但通過檢視每種方法的soapaction值再具體確定呼叫哪個方法。因為我們在類中並沒有明確的指定soapaction的值，.asmx控制代碼認為soapaction的值是web服務的命名空間加上方法名。而且我們也沒有指定命名空間，所以控制代碼就把作為預設值。這樣add方法的預設soapaction值就是/add。
可以按如下方法定製web服務的命名空間。把類標記上[webservice]屬性，用[soapdocumentmethod]屬性標記webmethods來指定具體的soapaction值。示例如下：
現在.asmx
控制代碼認為
add方法的
soapaction
值是，subtract
的值是urn:math:subtract
（因為我們在類中明確定義了）。比如下面的
請求訊息呼叫
如果.asmx控制代碼沒為http請求訊息找到乙個soapaction匹配，將會丟擲乙個異常。如果你不想依賴soapaction頭來分派訊息，可以引導.asmx控制代碼使用請求元素名稱。採用這種方法需要為類標記上[soapdocumentservice]屬性的routingstyle特性，同時也應該指出webmethods不需要soapaction值（在類中設定其值為空）。如下所示：
在這種情況下，控制代碼甚至不關心
soapaction
的值，它使用請求元素的名字確定呼叫方法。比如，在下面的
請求訊息中，它希望呼叫
add方法的請求元素的名字是
add：
所以當.asmx控制代碼接收到http訊息時它要做的第一件事情就是決定如何分派訊息到對應的webmethod。在它真正呼叫方法之前，還需要將到來的xml對映到.net物件。
一旦webmethod控制代碼決定了呼叫哪個方法，它就會將xml訊息反序列化為.net物件。隨著訊息分派，控制代碼通過reflection檢查類，然後決定怎樣處理xml訊息。xmlserializer類自動完成xml和system.xml.serialization命名空間中類的對映。
xmlserializer能實現任何.net公共型別到xml schema型別的對映，有了這個適當的對映，它能自動的實現.net物件和xml例項文件的對映（見圖4）。xmlserializer受xml schema所支援功能的限制，雖不能處理所有複雜的現代物件模型（如非樹型的物件圖），卻能處理開發者常用的複雜型別。
再看前面add的例子，xmlserializer將把x和y元素對映為.net的double值（呼叫add方法時必須提供的）。add方法返回乙個double型別值給呼叫者，這也需要被序列化為soap應答訊息中的乙個xml元素。
xmlserializer也能自動處理一些複雜型別（除了上面說到的一些限制）。比如，下面的webmethod計算兩個點結構之間的距離。
請求此操作的
soap
訊息將包含乙個
distance
元素，它包含了兩個子元素，乙個稱作
orig
，另乙個是
dest
，每乙個都包括了x和
y元素，如下所示：
這種情況下
soap
應答訊息將包含乙個
distanceresponse
元素，它包含乙個
double
型別的distanceresult
子元素。
預設的xml
對映使用方法名作為請求元素名，引數名作為子元素名。每個引數的結構依賴於型別的結構。公共欄位和屬性的名字簡單對映為子元素，如
point
類中的x和y
。應答元素的名字預設為請求元素的名字後面附加上「
response」,
應答元素也包含乙個子元素，是請求元素名字後面附加「
result
」。也有可能使用一些固定的對映屬性來打破標準的
xml對映。比如，你可以使用
[xmltype]
屬性來定製型別的名字和命名空間，使用
[xmlelement]
和[xmlattribute]
屬性來控制如何將引數或類成員分別對映為元素或屬性，也可以使用
[soapdocumentmethod]
屬性控制怎樣把方法本身對映為請求
/響應訊息中的元素名。比如，檢查下面重新定義的
distance
。它所期望的
soap
請求訊息如下：
並將產生下面的應答訊息：
.asmx控制代碼使用soap document/literal風格來實現和描述上面顯示的預設對映。意思上說wsdl定義將包含literal xml schema定義，它描述了soap訊息中用到的請求和響應元素。
.asmx控制代碼也能使用soap rpc/encoded風格。這意味著soap體中包含乙個rpc呼叫的xml代表（representation），引數用soap編碼規則來序列化。實現這些僅需將[soapdocumentservice] and [soapdocumentmethod]替換為[soaprpcservice] and [soaprpcmethod]屬性。
正如你所看到的，我們可能完全定製乙個從給定方法到soap訊息的對映。xmlserializer提供了乙個強大的序列化引擎。
除了處理引數的反序列化，.asmx控制代碼也能序列化/反序列化soap頭。soap頭的處理不同於引數，因為它們被認為是典型的無法控制的資訊，和具體的方法沒有直接的聯絡。由於這些，頭處理主要是通過中間層（interception layers），完全為webmethods遮蔽了頭處理。
然而如果想涉足於webmethod中的頭資訊，你必須提供乙個.net類，從soapheader派生而來，它代表了頭的xml schema型別。然後定義乙個此型別的成員變數作為每乙個頭例項的佔位符。最後標記每個要訪問頭的webmethod，指定你想要到達的網域名稱。
比如，下面的soap請求包括乙個用來進行身份驗證的usernametoken頭。
Web service 原理和 開發
服務端 生成服務描述檔案，以供客戶端獲取。接收客戶端發來的soap請求訊息，解析其中的方法呼叫和引數格式。根據wsdl和wsml的描述，呼叫相應的com物件來完成指定功能，並把返回值放入soap回應訊息返回給使用者。高層介面 使用高層介面，不需要知道soap和xml的任何資訊，就可以生成和使用乙個w...
webservice的原理及概念
webservice的原理及概念 1 webservice 所謂webservice就是定義了一套標準的呼叫過程 a 伺服器首先用一套標準的方法向外界描述它所提供的服務的內容，就屬於wsdl b 客戶端需要以一種標準的協議來呼叫此服務，這屬於soap.c 服務提供者將服務內容放在乙個公共的 讓大家查...
Web Service高階 一 執行原理
在web服務中，存在三個角色 服務提供者 服務請求者和服務中介，三者之間的關係如圖1 1所示 摘錄自 實現乙個完整的web服務包括以下步驟 web服務提供者設計實現web服務，並將除錯正確後的web服務通過web服務中介者發布，並在uddi註冊中心註冊 發布 web服務請求者向web服務中介者請求特...