Re: Misunderstanding of SOAP message and protocol binding

[Andy Bierman <abierman@cisco.com>]

At 11:33 AM 5/9/2003, Chen, Weijing wrote:
>I think in this mailing list there is a lot of confusion and
>misunderstanding about SOAP.  SOAP specification from W3C clearly separates
>the specification into Message Construct and Underlying Protocol Binding
>part.  So far there is not solid evidence that why SOAP Message Construct
>cannot be used for XMLCONF.  Let's look a simple example using SOAP Message
>Construct for "get-config":

Thanks for this email and the examples. This is the first attempt
to show the group a specific usage of SOAP in the protocol.
In your example, the overhead is not bad at all and I wouldn't
object to this usage of SOAP. The error response encoding is 
also quite reasonable.

The main argument for using SOAP seems to be that there are
application development tools available which will hide the 
XML, RPC, and transport details from the application.  This is 
a valid argument, and people need to speak up if they approve
or disapprove.  I don't think this argument applies to embedded
systems as much, but the overhead of parsing a SOAP envelope is
not enough to worry about on an embedded platform.

I have a few questions (2 general and 1 inline):

How would the capabilities exchange in the session startup be
handled?  This is an important aspect of the protocol, and
it affects which protocol operation features the NMS can
use during the session. Would this just be another protocol
operation, which would be required to be the first operation
requested by the NMS?  

The protocol operations supported by a given device will be 
different, based on the capabilities exchange.  Is this
supported by SOAP tools?



><?xml version="1.0" ?>
><env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelop";>
>   <env:Body>
>      <get-config
>          env:encodingStyle="http://www.w3.org/2001/09/soap-encoding";

What is the purpose of this attribute declaration above?
SOAP data types are not used in the rest of the Body
(which is why I like it).

>          xmlns="http://www.ietf.org/xmlconf";>
>      <target>
>         <running></running>
>      </target>
>      <test-option>test-then-set</test-option>
>      <write-option>replace</write-option>
>      <error-option>stop-on-error</error-option>
>      <config xmlns="http://example.com/schema/1.2/config";>
>         <interface name="Ethernet0/0">

Note that in this example (which I wrote for the xmlconf spec)
the attribute vs. element XML convention was not followed.
I agree with Larry that identification (naming) parameters
tend to work better as an attribute instead of the first 
child element.

>            <address>
>               <ipv4>1.2.3.4</ipv4>
>               <ipv4-mask>255.0.0.0</ipv4-mask>
>            </address>
>         </interface>
>      </config>
>      </get-config>
>   </env:Body>
></env:Envelope>
>
>
>Now if someone wants put the above "get-config" message into said HTTP
>binding, he can use HTTP POST:
>
>POST /Reservations HTTP/1.1
>HOST: noc1.serviceproviderA.com
>Content-Type: application/soap+xml; charset="utf-8"
>Content-length: nnnn
>
><and above message>
>
>
>Or someone wants to use BEEP binding, he can use BEEP protocol, but with the
>same SOAP Message Construct.
>
>The SOAP Message Construct allows the about a dozen usage:  fire-and-forget
>to single reciever, fire-and-forget to multiple receivers, request/response,
>rpc, request with acknowledgement, request with encrypted payload, third
>party intermediary, conversational message exchange, message header and
>payload encryption, communication via multiple intermediaries, asynchronous
>messageing, send non-XML data, multiple asynchronous responses, incremental
>parsing/processing of SOAP messages, event notification, caching, routing,
>tracking, caching with expiration, quality of service, etc.  Also the SOAP
>fault and error processing is fairly comprehensive.  An error code exmaple
>is:
>
><?xml version='1.0' ?>
><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope";
>            xmlns:xmlconf="http://www.ietf.org/2003/05/xmlconf";>
>  <env:Body>
>   <env:Fault>
>     <env:Code>
>       <env:Value>env:Sender</env:Value>
>       <env:Subcode>
>        <env:Value>xmlconf:BadArguments</env:Value>
>       </env:Subcode>
>     </env:Code>
>     <env:Reason>
>      <env:Text xml:lang="en-US">Processing error</env:Text>
>      <env:Text xml:lang="cs">Chyba zpracování</env:Text>
>     </env:Reason>
>     <env:Detail>
>      <e:myFaultDetails 
>        xmlns:e="http://example.org/faults";>
>        <e:message>Name does not match card id</e:message>
>        <e:errorcode>999</e:errorcode>
>      </e:myFaultDetails>
>     </env:Detail>
>   </env:Fault>
> </env:Body>
></env:Envelope>
>
>
>So someone please tell me why SOAP Message Construct can be not reused
>beside the reason of NIH syndrome.
>
>
>
>--
>Weijing Chen
>SBC Technology Resources
>9505 Arboretum Blvd.
>Austin, TX 78759
>512 372 5710
>wchen@tri.sbc.com
>
>--

Andy


--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>