SOAP roughly corresponds to DCOM, CORBA's IIOP, or Java's RMI.
How do SOAP and XML-RPC compare? XML-RPC is like RPC; it has conventional procedural programming-language calling conventions. SOAP communicates with named parameters, and is, as St. Laurent, Jonston, and Dumbill express it, "firmly rooted in the object-oriented paradigm." XML-RPC is seriously stateless, while SOAP is handier for managing state. Still, many SOAP-based projects in 2001 are using it procedurally. SOAP is harder to implement. There are dozens of XML-RPC language bindings, and experienced folks turn out new ones in a day. SOAP coders talk about "interoperability" problems; in my experience, this means, "a binding that doesn't conform to the standard, but the developer didn't notice it until someone outside tried to use it." So far, I've found XML-RPC and SOAP essentially indistinguishable in processing efficiency and memory use. SOAP supports namespaces, which are as beneficial as always. SOAP is extensible, mostly in regard to datatypes. In principle, SOAP supports XML Schema (is this real yet?). XML-RPC fans see SOAP as bloated. SOAP fans like the commitment IBM, Microsoft, Oracle, ... have made to the protocol.
SOAP (and XML-RPC) have plenty of failings. A particular one is big payloads. SOAP-based systems often stumble when trying to communicate, say, 30 megabytes of image data, 'cause they don't know how to stream it.
The SOAP (and ...) deficiency which first attracts attention has to do with security: authentication and authorization. . . .
SOAP2CORBA is a SOAP-CORBA gateway.