The Opportunity of SOAP

A reader writes: "There's an interesting piece on DaveNet concerning SOAP and some of Dave's predictions for it. He also talks about SOAP being in a flexible phrase, and the potentials for it, if it is used correctly. The point about the multiplicity of Dot.Nets is a good mental exercise too. Will development happen that way?"

Comments

SOAP's real technical benefits

[Stu Charlton]

Taking away the hype, here's a simple look at: "Why SOAP for RPC?"

1. The real value comes from XML.

   XML as a data representation has 2 major differences between it and the other more popular RPC protocols:

   1. It ships semantics with the data (i.e. it's a semantic data stream)
   2. It does not require static interface for 2 endpoints to communicate.
   Let me elaborate:
   • Traditional RPC protocols require one to know that a method is of the form:

     foobar(int a, int b, char[] c)

     I.e., you need to know the positions of the parameters, and their types.

     With XML, each parameter is defined by a "tag". This allows position independence -- one only has to state the name of the parameter that the piece of data is for. (Insert analogy to Smalltalk method parameters here.)

   • Traditional RPC protocols also require you to statically bind to an interface (.h file, .java file, IDL file). This means that when an interface changes, you need to recompile. This sucks.

     With XML, the interface for an RPC is defined by an XML Schema Definition, which is just a type/structural description of an XML document. No binding. No recompiling. No registry hell due to immutable COM interfaces.

   • Traditional RPC's were "static first, dynamic second". One could call COM components dynamically through Automation -- but this was an afterthought, and was crufty. Similarily, CORBA had the DII -- but it too was way of "tacking on" dynamic method invocations on top of what was a static model.

     XML RPC frees you from having to use a standard object model, or a standard language. You can implement an XML RPC endpoint in ANYTHING you want -- there's no model to bind to. Every call is dynamic.

2. SOAP's actual value (besides XML) is limited:
   • It's an envelope for an XML document (which can be used as an RPC call) that says "you should know these schemas in order to understand this message".
   • It defines a standard type encoding (for arrays, structs, etc)
   • Can target to specific proxies (actors) application extensions (XML namespaces & schemas)
   • SOAP runtimes will ease development for particular languages. Runtimes already exist for Java, .NET, and other languages.
3. HTTP provides the final value-add in that it's ubquitious, firewall-friendly, and clear-text.
4. Different quality of service needs do exist, so SOAP isn't dependent on HTTP.