developer:rpc_literal

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

developer:rpc_literal [2011/03/02 13:34]
irina created
developer:rpc_literal [2011/03/02 13:37] (current)
irina
Line 5: Line 5:
     <​soap:​body>​     <​soap:​body>​
         <​myMethod>​         <​myMethod>​
-            <x xsi:​type="​xsd:​int"​>​5</​x>​ +            <​x>​5</​x>​ 
-            <y xsi:​type="​xsd:​float"​>​5.0</​y>​+            <​y>​5.0</​y>​
         </​myMethod>​         </​myMethod>​
     </​soap:​body>​     </​soap:​body>​
Line 12: Line 12:
 </​code>​ </​code>​
  
-There are a number of things to notice about the WSDL and SOAP message for this RPC/encoded example:+Here are the strengths ​and weaknesses of this approach:
  
 ===== Strengths ===== ===== Strengths =====
  
-  ​- The WSDL is about as straightforward as it'​s ​possible for WSDL to be. +    ​- The WSDL is still about as straightforward as it is possible for WSDL to be. 
-  - The operation name appears in the message, so the receiver has an easy time dispatching this message to the implementation of the operation+    - The operation name still appears in the message
 +    - The type encoding info is eliminated. 
 +    - RPC/literal is WS-I compliant.
  
 ===== Weaknesses ===== ===== Weaknesses =====
  
-  - The type encoding info (such as xsi:​type="​xsd:​int"​) is usually just overhead which degrades throughput performance. +    ​- You still cannot easily validate this message since only the <x ...>​5</​x>​ and <y ...>​5.0</​y>​ lines contain things defined in a schema; the rest of the soap:body contents comes from WSDL definitions.
-  ​- You cannot easily validate this message since only the <x ...>​5</​x>​ and <y ...>​5.0</​y>​ lines contain things defined in a schema; the rest of the soap:body contents comes from WSDL definitions+
-  - Although it is legal WSDL, RPC/encoded is not WS-I compliant.+
  
developer/rpc_literal.txt · Last modified: 2011/03/02 13:37 by irina

Page Tools