Differences between Ice and SOAP/Web Services

In general, SOAP and Web Services cannot be easily compared to Ice. SOAP is a very basic protocol, with no support for object-oriented development of distributed applications. Don’t let buzzwords such as "service-oriented architecture" (SOA) fool you—SOA is not a replacement for an object-oriented architecture. You can just as easily implement a service-oriented architecture with Ice or CORBA while taking advantage of object-orientation as well (which is something you cannot do with Web Services).

In general, Web Services do not offer functionality that even gets close to what Ice (or CORBA) provide. There is no programming model, there are no defined language mappings, and each vendor uses its own proprietary API and tools. Nevertheless, let’s compare just two important properties: performance and simplicity.


SOAP is appallingly slow. The required XML parsing puts heavy load on the CPU, increases latency, and lowers throughput. Even a slow CORBA ORB has typically 10-100 times better latency and throughput than the best SOAP products; Ice has performance figures that are typically hundreds of times better than SOAP products. SOAP is also extremely wasteful of bandwidth due to its XML encoding, with SOAP messages typically being twenty or more times larger than equivalent Ice messages.


One of the main arguments for using XML for Web Services was that XML is human-readable. Well, let's see how WSDL, the XML-based interface definition language for Web Services, compares to Slice:

// My first service
interface StockQuoteService
    float GetLastTradePrice(string tickerSymbol);

The equivalent WSDL code is as follows:

<?xml version="1.0"?>
<definitions name="StockQuote"
<schema targetNamespace=
<element name="TradePriceRequest">
<element name="tickerSymbol"
<element name="TradePrice">
<element name="price" type="float"/>
<message name="GetLastTradePriceInput">
<part name="body" element=
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
<binding name="StockQuoteSoapBinding"
<soap:binding style="document"
<operation name="GetLastTradePrice">
<soap:body use="literal"/>
<soap:body use="literal"/>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort"
<soap:address location=

This is not an example that we made up, but is taken from an article about WSDL. We leave it to you to judge which is easier to read, WSDL or Slice. (It didn't take us very long to make up our minds.)

But the complexity does not end here. WSDL definitions are typically not stored in a separate file (even assuming that you could easily create them without tool support), but are taken from annotations inside comments in source code. This means that there is no longer a single place where you can find a type definition for an application. Instead, the type definitions are strewn over possibly dozens of source files where they are hard to find. This makes it difficult to form a coherent view of and application's interfaces and how they interact with each other.

Terms of Use | Privacy © 2014 ZeroC, Inc.