From: Eric Bresie <ebresie@us...> - 2001-03-02 17:15:53
Hey guys...since I mentioned SOAP recently...thought I would mention this
little item off of slashdot.
"The Opportunity of SOAP"
Checkout the comments also...it actually has a lot of useful information.
(filtering any noise)
From: Eric Bresie <ebresie@us...> - 2001-03-02 17:20:08
> From: Eric Bresie [mailto:ebresie@...]
> Sent: Friday, March 02, 2001 11:17 AM
> To: threedsia-dev@...
> Subject: SOAP on slashdot
> "The Opportunity of SOAP"
Going through it again...I found this comment very informative..for those
not wanting to
go through all the comments and article.
"SOAP's real technical benefits (Score:1)
by Stu Charlton (stuartcharlton@...) on Friday March 02, @10:54AM
(User #1311 Info)
Taking away the hype, here's a simple look at: "Why SOAP for RPC?"
The real value comes from XML.
XML as a data representation has 2 major differences between it and the
other more popular RPC protocols:
It ships semantics with the data (i.e. it's a semantic data stream)
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.
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.
HTTP provides the final value-add in that it's ubquitious,
firewall-friendly, and clear-text.
Different quality of service needs do exist, so SOAP isn't dependent on