Re: how bad is soap?

[Andy Bierman <abierman@cisco.com>]

At 12:40 AM 4/25/2003, Frank Strauss wrote:
>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.

I agree with your reasoning. I think a detailed technical
proposal using SOAP/WSDL should be written by a proponent of this
approach so it can be evaluated by the WG.

I think the cost/benefit ratio depends mostly on the tool
environment of the user.  I don't want to be the one to
tell operators they are using the wrong tools and need
to abandon their scripting environment and use something
else instead -- such as a WSDL compiler.  

I don't know the size of the different netconf camps, but
I am very concerned about network operators who currently
rely on the CLI as a programmatic interface for configuration.
Based on all the data the OPS-NM Roadshow has collected over
the last 2+ years, this is a large group.


> -frank

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