That being said, both SOAP and CORBA services are services--applications that expose their functionality to other applications through an API. The differences between SOAP and CORBA services are:
- the specifications define different levels of the programming model. CORBA defines the entire programming model--from language bindings to the object model to the service container model to the message format to the network protocol. SOAP only defines the message format. It does not define language bindings, an object model, a container model or a network protocol.
- they use different formats and protocols to encode messages. SOAP encodes messages in XML. CORBA encodes messages in a binary format called CDR (Common Data Representation). CORBA messages are much more efficient than SOAP messages.
- they describe their interfaces differently. SOAP uses WSDL. CORBA uses CORBA IDL. WSDL is a modular description language that lets you describe a set of abstract operations (portTypes), any number of supported bindings for each set of operations (bindings) and specific implementations of those bindings (services). IDL only permits you to describe a concrete set of operations (the service signature).
- they perform binding differently. SOAP supports dynamic binding. A SOAP client can read the WSDL at runtime and dynamically select the proper data encoding scheme and transfer protocol based on binding information specified in the WSDL binding description. CORBA doesn't specify binding information in the IDL. The binding is predetermined and is implemented within the CORBA runtime.
- they use different transport protocols. A SOAP message can be transferred using almost any application or transport protocol, (HTTP, HTTPS, SMTP, JMS, Jabber, Freenet, TCP/IP, etc.) The specific protocol being used is specified in the binding information in the WSDL description. CORBA requires that you use a protocol conforming to the CORBA GIOP specification. The most common GIOP implementation is IIOP (which uses TCP/IP). CORBA IIOP messages can be tunneled through HTTP, but CORBA doesn't natively support HTTP.
- they have different supporters. SOAP has been embraced by nearly every vendor in the world. There are more than 80 different SOAP implementations. Many are open source implementations. CORBA lacks support from Microsoft. There are less than a dozen implementations. I don't know of any open source implementations (but I haven't checked).
- they have different status in terms of standardization. CORBA is a standard defined by OMG. It is quite mature. SOAP has not yet been standardized. (W3C is in the process of defining the SOAP 1.2 and WSDL 1.2 standards).
- they have different levels of supporting infrastructure. OMG has defined a standard set of CORBAservices that supply capabilities such as naming, security, transactions, lifecycle, and more. Most of the SOAP supporting infrastructure has not yet been defined (OASIS WSS is defining security services for SOAP).
But here's an interesting twist: The first point I made is that SOAP doesn't define its object or container model. You can implement your SOAP service using any object model you like, including CORBA. You can take a CORBA service and add a SOAP interface to it, and then it becomes a Web service. Cape Clear CapeConnect (www.capeclear.com) and IONA XMLbus (www.xmlbus.com) provide SOAP implementations that are nicely integrated with CORBA. These environments provide automatic tools that will convert any CORBA service into a Web service.
This was first published in December 2002