轉載地址：http://hi.baidu.com/mytaihu/blog/item/d1dcc0078f513ecd7a8947c7.html
1. SOAP: 與 Web Service 無關
雖然SOAP可能是為了實現(xiàn)Web Service而被發(fā)明的，但實際上它可以被用在任何需要交換數(shù)據(jù)的場合（SOAP is an XML-based communication protocol and encoding format for inter-application communication）
讓我們比較一下SOAP和現(xiàn)實生活中的信封：
-
信封只是一個殼，但必不可少，其作用就是讓接收者一看就知道是一封信，而不是一束花.(SOAP Envelop元素必不可少)
-
信封對里面的信件內容一無所知，它也沒規(guī)定里面必須是情書或者工資單. (SOAP 可以包裹任何內容)
-
信件可以由信封包著，交給郵局送達，也可以由熟人順路帶過去. (SOAP 與傳輸方式無關，HTTP, JMS, SMTP...)
-
信件接收者可以選擇回信，也可以不回. (SOAP 是單向的)
是的，就像<<Web Service Security>>作者的比喻，SOAP是應用程序間的電子郵件
正是由于SOAP的這種靈活性，許多新的規(guī)范都在SOAP的基礎上進行擴展和定制，像WS-Security, WS-Addressing等，無非就是定義了幾個標準化的SOAP Header或SOAP Body元素
2. WSDL: 與 Runtime 無關
WSDL是Web Service的靜態(tài)描述信息，主要是用于在客戶程序的編碼設計階段告訴客戶程序Web Service的信息，一旦客戶程序在設計階段獲得了足夠的信息，運行時根本不需要什么WSDL
或許某種情況下運行時需要WSDL的幫助吧，但我沒有遇到過，如果你知道，請告訴我
portType其實就是Web服務的接口，但這個名字實在不直觀，尤其對非英語國家的人來說，新版本的WSDL規(guī)范已經將portType改名為了 “Interface”
3. WSDL-SOAP Binding Style
就是所謂RPC與Document或者Wrapped，Literal與Encoding
先說Literal與Encoding
-
Literal 就是不在SOAP消息中表明數(shù)據(jù)類型，而通過其它方式獲知數(shù)據(jù)類型，這種方式是開發(fā)包相關的，沒有什么標準；如<x>50< /x>，單從SOAP消息，你無法判斷50是數(shù)字還是字符串，而具體的類型可以在開發(fā)包將SOAP請求映射到具體的Service類時來確定并完成 轉換，對于返回值也一樣，客戶端可已通過SetReturnValueType(...)之類的方法告知開發(fā)包自己期待什么類型
-
Encoding就是在SOAP消息中攜帶類型信息，并且依據(jù)某種規(guī)則將數(shù)據(jù)編碼傳遞，接收端可以根據(jù)類型信息和編碼規(guī)則完成解碼，獲得原始數(shù)據(jù)；如<x xsi:type="xsd:string">50</x>
再看看RPC與Document
|
<envelope><body><myMethod><x>5</x><y>8</y></myMethod></body></envelope> (RPC/Literal)
<envelope><body><myMethod><x type=string>5</x><y type=int>8</y></myMethod></body></envelope> (RPC/Encoded)
|
|
<types>
<schema>
<element name="xElement" type="xsd:int"/>
</schema>
</types>
<message name="myMethodRequest">
<part name="x" element="xElement"/>
</message>
<message name="empty"/>
<portType name="PT">
<operation name="myMethod">
<input message="myMethodRequest"/>
<output message="empty"/>
</operation>
</portType>
<soap:envelope>
<soap:body>
<xElement>5</xElement>
</soap:body>
</soap:envelope>
然 而這種方式沒有在SOAP消息中包含操作名，所以如果兩個不同的操作具有相同的輸入，開發(fā)包有可能無法決定把請求轉發(fā)到哪個函數(shù)，為避免這種情況，開發(fā)包 一般為每個操作的輸入輸出都產生具有唯一名稱的Element，不管它們是否內容相同；或者作為開發(fā)者，你可以選擇 Wrapped 風格
|
|
<types>
<schema>
<element name="myMethod"/>
<complexType>
<sequence>
<element name="x" type="xsd:int"/>
</sequence>
</complexType>
</element>
</schema>
</types>
<message name="myMethodRequest">
<part name="parameters" element="myMethod"/>
</message>
<message name="empty"/>
<portType name="PT">
<operation name="myMethod">
<input message="myMethodRequest"/>
<output message="empty"/>
</operation>
</portType>
<soap:envelope>
<soap:body>
<myMethod> <x>5</x> </myMethod>
</soap:body>
</soap:envelope>
這種方式也具有明顯的弱點：無法方便的處理重載，因為XML Schema不允許定義相同名稱的元素；這樣，即使你的后臺編程語言支持函數(shù)重載，你也應該盡量避免使用
|
Document services and wrapped services are similar in that neither uses the SOAP encoding for data; it's just plain old XML schema.
4. UDDI：與 WSDL 無關
雖 然都是描述Web Service的，但UDDI與WSDL各司其責；事實上，UDDI野心太大，定義了很多社會性的Attribute，而不局限于技術性的Web服務，如 人工電話服務信息和傳真服務信息都可以注冊到UDDI中，描述性的東西很多（descriptive information ）一些overviewURL 也都推薦指向文檔，關于這點，參照目前UDDI的應用情況，我認為UDDI是過度設計了
UDDI 注冊表其實是一堆元數(shù)據(jù)的集合，元元數(shù)據(jù)...，元數(shù)據(jù)用tModel來表達，可以有不同的分類，通過tModel key來引用；當你試圖用字符串表達什么東西時，你最好看看是否已經有了對應的tModel，有的話你就需要用對該tModel的引用來代替字符串，如在 UDDI中表達一個Web Service的PortType時，你不應該在某處用字符串“PortType”來表明這是一個Port Type，你應該引用預定義的PortType tModel來表明：
<tModel tModelKey="uuid:e8cf1163-8234-4b35-865f-94a7322e40c3" >
<name> StockQuotePortType </name>
<overviewDoc> <overviewURL> http://location/sample.wsdl <overviewURL> <overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:d01987d1-ab2e-3013-9be2-2a66eb99d824" keyName="namespace" keyValue="http://example.com/stockquote/" />
<keyedReference tModelKey="uuid:6e090afa-33e5-36eb-81b7-1ca18373f457" keyName="WSDL type" keyValue="portType" />
</categoryBag>
</tModel>
Web Service與UDDI的關系類似于COM組件服務與Windows注冊表的關系，其實它們可以看作是同一個概念的不同發(fā)展階段或不同實現(xiàn)
而UDDI直觀的比喻可以是圖書館卡片索引，在我上中學的時候，圖書館沒有計算機供讀者查詢圖書信息，只有一柜一柜一櫥一櫥的索引卡片，記錄了圖書信息，如作者出版社等，當然最重要的是它在書庫里的位置，第幾排第幾格
分 類體系在UDDI中占很大比重，不同的Category如傳輸協(xié)議，命名空間，WSDL Type等，每一個Entity或tModel都可以具有多個分類屬性，比如上面的StockQuotePortType tModel,按名稱空間來分，它屬于http://example.com/stockquote/，按WSDL Type來分，它屬于portType；BindingTemplate Entity還具有傳輸協(xié)議的分類，值可以是HTTP或SMTP之類
分類體系在現(xiàn)實生活中隨處可見，比如說同一個人，按性別分是mm，按婚否分是未婚，按政治面貌分是刁民；圖書館的索引卡片上也隨處可見，按出版社分是三聯(lián)，按題材分是小說，按風格分是后現(xiàn)代等等
5. UDDI：與WSDL 有關
畢竟都是描述WebService的，還是有部分內容有關系的，于是有了WSDL到UDDI的映射，這樣某些工具就可以自動將WebService注冊到UDDI中
大 體上就是<portType>和<binding>作為tModel映射到UDDI中，<service>映射為 <businessService>, <port>映射為<bindingTemplate>
6. JAX-RPC: 首先是Java,其次才是RPC
雖 然JAX-RPC不厭其煩的表達自己支持但不依賴SOAP的特性，但支持SOAP之外的消息交換機制究竟目前有沒有具體應用，我不知道，每個開發(fā)包也從框 架上支持任意的消息交換機制，但我見過的應用都是把它們作為SOAP引擎，如果你知道SOAP之外的消息交換機制的具體應用，請告訴我
posted on 2008-09-26 11:10
阿蜜果 閱讀(1194)
評論(0) 編輯 收藏 所屬分類:
網絡通信相關