posts - 297,  comments - 1618,  trackbacks - 0

                 轉載地址:http://hi.baidu.com/mytaihu/blog/item/d1dcc0078f513ecd7a8947c7.html

          1. SOAP: 與 Web Service 無關

          雖然SOAP可能是為了實現Web Service而被發明的,但實際上它可以被用在任何需要交換數據的場合(SOAP is an XML-based communication protocol and encoding format for inter-application communication)

          • SOAP本身是語義獨立的,基本上只是一個信封,你可以往SOAP Header和SOAP Body里塞任何東西,也沒有什么Header元素和Body元素是SOAP本身定義的,除了SOAP Fault

          • SOAP也是與數據交換方式,或者說傳輸方式無關的,HTTP,TCP...;

          • SOAP本身也是無狀態,單向的;

          讓我們比較一下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

          • RPC就是按照類似函數調用時所需的信息來組裝SOAP消息:操作名作為根元素,參數組成子元素,如:

          <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)

           

          • Document 就是將SOAP請求和響應,或者說輸入輸出定義為XML元素,有嚴格的Schema("document" style means the messages in and out of the service are exactly as they are describe by the XML Schema in the WSDL).如某個Web Service的WSDL片斷:

          <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 風格

           

          • Wrapped 風格就是定義與操作同名的Element,將參數作為 Child Element;這樣操作名又重新回到了SOAP消息中,如WSDL片斷:

          <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之外的消息交換機制的具體應用,請告訴我

          posted on 2008-09-26 11:10 阿蜜果 閱讀(1213) 評論(0)  編輯  收藏 所屬分類: 網絡通信相關
          <2008年9月>
          31123456
          78910111213
          14151617181920
          21222324252627
          2829301234
          567891011

                生活將我們磨圓,是為了讓我們滾得更遠——“圓”來如此。
                我的作品:
                玩轉Axure RP  (2015年12月出版)
                

                Power Designer系統分析與建模實戰  (2015年7月出版)
                
               Struts2+Hibernate3+Spring2   (2010年5月出版)
               

          留言簿(263)

          隨筆分類

          隨筆檔案

          文章分類

          相冊

          關注blog

          積分與排名

          • 積分 - 2299173
          • 排名 - 3

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 兴城市| 富宁县| 黑山县| 乳山市| 景泰县| 房产| 藁城市| 綦江县| 上杭县| 雅江县| 永靖县| 石屏县| 天峨县| 松潘县| 新竹县| 连南| 东明县| 逊克县| 黑河市| 平安县| 云南省| 咸丰县| 柳河县| 天津市| 商洛市| 肥东县| 称多县| 万安县| 淳化县| 金坛市| 永昌县| 宁德市| 乐昌市| 托克逊县| 浠水县| 红原县| 丹巴县| 应用必备| 南通市| 平舆县| 开平市|