I (with feedback from other team members) have tried to enumerate some of
the advantages and disadvantages of ICAP and "SOAP over HTTP" as a callout
protocol. Please add your comments or more comparisons to it. It will let us
evaluate the protocols at hand.
ICAP vs SOAP as Callout protocol
----------------------------------
1. Implementation effort:
ICAP: Needs handling of new ICAP server and ICAP client messages.
Implementers of ICAP system have claimed it to be simple with minimal
changes to existing http stack. Also ICAP because of its close relationship
to HTTP is easier for many to implement.
SOAP: SOAP over HTTP can be run over existing proxies and intermediaries.
SOAP Will need new applications to process SOAP messages. Need for XML
processing support on the server and client.
2. Processing Overhead:
ICAP: avoids parsing XML and could be much less verbose hence low message
overhead. Which also implies lower latency compared to SOAP.
SOAP: messages will be formulated in XML and hence implies a more message
overhead. Note that, not all the data in a SOAP message needs to be
converted to XML, it is only the message part that needs to do that. The
body part does not need to be wholly encoded in an XML. For example, an HTTP
header from a client (for modification by a call out server) may be enclosed
in a CDATA section.
3. Rich semantics:
ICAP: is used for simple messaging and lacks the power of XML to describe a
method and it's parameters. For example, it will not be able to use complex
data type as its parameter to its method call. (Could complex data type be
passed in a message body ?)
SOAP: Because of XML and rich data types supported by XML Schema, SOAP will
be able to convey complex messages that might aid in defining better and
easier to maintain messaging mechanism.
3. Extensibility:
ICAP: ICAP ties the method invocation semantic and with the protocol.
Although that makes it light weight, it makes it pretty stringent.
SOAP: On the other hand separates the remote method invocation semantics
from the protocol. So if new protocol stack shows up which provides say
better security it will be easy to port.
4. Security
ICAP: The ICAP uri needs to be in the clear to be able to reach the service,
which can easily be snooped by a third party. One needs to provide secure
tunneling mechanism.
SOAP: carries the request in the message body it can be encrypted and could
be sent with existing http protocol.
The body can be encrypted in both the cases of for TLS; it is the same for
both cases.
5. Support for asynchronous operation.
ICAP: Does not support asynchronous operation.
SOAP: semantic is not tied to the protocol and hence could provide
asynchronous operation.
-regards
Rezaur Rahman
Intel Architecture Labs