1. SOAP: 與 Web Service 無關
雖然SOAP可能是為了實現Web Service而被發明的，但實際上它可以被用在任何需要交換數據的場合（SOAP is an XML-based communication protocol and encoding format for inter-application communication）
讓我們比較一下SOAP和現實生活中的信封：
-
信封只是一個殼，但必不可少，其作用就是讓接收者一看就知道是一封信，而不是一束花.(SOAP Envelop元素必不可少)
-
信封對里面的信件內容一無所知，它也沒規定里面必須是情書或者工資單. (SOAP 可以包裹任何內容)
-
信件可以由信封包著，交給郵局送達，也可以由熟人順路帶過去. (SOAP 與傳輸方式無關，HTTP, JMS, SMTP...)
-
信件接收者可以選擇回信，也可以不回. (SOAP 是單向的)
是的，就像<<Web Service Security>>作者的比喻，SOAP是應用程序間的電子郵件
正是由于SOAP的這種靈活性，許多新的規范都在SOAP的基礎上進行擴展和定制，像WS-Security, WS-Addressing等，無非就是定義了幾個標準化的SOAP Header或SOAP Body元素
?
2. WSDL: 與 Runtime 無關
WSDL是Web Service的靜態描述信息，主要是用于在客戶程序的編碼設計階段告訴客戶程序Web Service的信息，一旦客戶程序在設計階段獲得了足夠的信息，運行時根本不需要什么WSDL
或許某種情況下運行時需要WSDL的幫助吧，但我沒有遇到過，如果你知道，請告訴我
portType其實就是Web服務的接口，但這個名字實在不直觀，尤其對非英語國家的人來說，新版本的WSDL規范已經將portType改名為了 “Interface”
?
3. WSDL-SOAP Binding Style
就是所謂RPC與Document或者Wrapped，Literal與Encoding
先說Literal與Encoding
-
Literal就是不在SOAP消息中表明數據類型，而通過其它方式獲知數據類型，這種方式是開發包相關的，沒有什么標準；如<x>50</x>，單從SOAP消息，你無法判斷50是數字還是字符串，而具體的類型可以在開發包將SOAP請求映射到具體的Service類時來確定并完成轉換，對于返回值也一樣，客戶端可已通過SetReturnValueType(...)之類的方法告知開發包自己期待什么類型
-
Encoding就是在SOAP消息中攜帶類型信息，并且依據某種規則將數據編碼傳遞，接收端可以根據類型信息和編碼規則完成解碼，獲得原始數據；如<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消息如下：
<soap:envelope>
??? <soap:body>
??????? <xElement>5</xElement>
??? </soap:body>
</soap:envelope>
然而這種方式沒有在SOAP消息中包含操作名，所以如果兩個不同的操作具有相同的輸入，開發包有可能無法決定把請求轉發到哪個函數，為避免這種情況，開發包一般為每個操作的輸入輸出都產生具有唯一名稱的Element，不管它們是否內容相同；或者作為開發者，你可以選擇 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消息：
<soap:envelope>
??? <soap:body>
??????? <myMethod>? <x>5</x>?? </myMethod>
??? </soap:body>
</soap:envelope>
這種方式也具有明顯的弱點：無法方便的處理重載，因為XML Schema不允許定義相同名稱的元素；這樣，即使你的后臺編程語言支持函數重載，你也應該盡量避免使用
|
?
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注冊表其實是一堆元數據的集合，元元數據...，元數據用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注冊表的關系，其實它們可以看作是同一個概念的不同發展階段或不同實現
而UDDI直觀的比喻可以是圖書館卡片索引，在我上中學的時候，圖書館沒有計算機供讀者查詢圖書信息，只有一柜一柜一櫥一櫥的索引卡片，記錄了圖書信息，如作者出版社等，當然最重要的是它在書庫里的位置，第幾排第幾格
分類體系在UDDI中占很大比重，不同的Category如傳輸協議，命名空間，WSDL Type等，每一個Entity或tModel都可以具有多個分類屬性，比如上面的StockQuotePortType tModel,按名稱空間來分，它屬于http://example.com/stockquote/，按WSDL Type來分，它屬于portType；BindingTemplate Entity還具有傳輸協議的分類，值可以是HTTP或SMTP之類
分類體系在現實生活中隨處可見，比如說同一個人，按性別分是mm，按婚否分是未婚，按政治面貌分是刁民；圖書館的索引卡片上也隨處可見，按出版社分是三聯，按題材分是小說，按風格分是后現代等等
?
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之外的消息交換機制究竟目前有沒有具體應用，我不知道，每個開發包也從框架上支持任意的消息交換機制，但我見過的應用都是把它們作為SOAP引擎，如果你知道SOAP之外的消息交換機制的具體應用，請告訴我
?