Re: how bad is soap?

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!

Andy> Until somebody publishes an I-D that explains exactly what
Andy> problems the as-yet-unspecified subset of SOAP is attempting to solve,
Andy> we cannot take this non-proposal seriously.  Cliches like
Andy> "reinventing the wheel" are meaningless. You have to precisely
Andy> explain what problems in the netconf charter are being addressed.
Andy> Examples of protocol message exchanges are also helpful to
Andy> vendors and operators in determining the cost/benefit ratio
Andy> of the proposal. 

Your reasoning is based on the obvious technical low-level costs as
"bytes in the message per netconf operation" or "kbytes for a netconf
implementation" or "cpu cycles to process a message". This is a good
reasoning, that I acknowledge. To this reasoning SOAP (as well as XML)
would not be a wise solution.

On the other hand, there are costs to implement a specification.  To
be more precise: (a) to implement the part of the specification that
supplies the service, and (b) to implement the many parts that build
on top of the specification and make use of it.  A reasonable approach
to reduce these two-fold kinds of costs is to get the specification
based on existing standard technologies. The advantages are: more
developers are familiar with the technologies, existing
implementations of these underlying standards can be used, and thus
development time can be reduced and implementations are less
error-prone.

The decision to get netconf based on XML was based on this idea.
People can use existing XML parsers, they can write XML Schema
definitions for grammars, they can use XSL transformations to compile
configurations, etc. Good!

Now people have to transfer configurations and call remote procedures.
The obvious approach is to look which RPC technologies that fit in the
XML world can be used. And thus XMLRPC and SOAP are being
discussed. You asked for the problems that are addressed by SOAP. This
is my thinking: There are many implementations of the SOAP protocol
and WSDL stub compilers in many programming languages so that all
operators would already have a big part of what's needed to make their
individual use of netconf operations. People can concentrate on their
real problems. They just run the netconf WSDL spec through their WSDL
compiler and simply make use of the automatically generated stub
functions in their individual code. They don't have to wait for a
Python or Tcl or Perl netconf implementation. They don't have to
fiddle with the RPC sementics from the specs. They don't have to
handle timeouts and unexpected protocol messages on their own. They
have less chances to make mistakes. 

This is my reason why SOAP/WSDL should be considered more carefully.

 -frank

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