In a nutshell:
ICAP is a means of encapsulating HTTP inside of HTTP, to allow
messages to be 'vectored' from an intermediary to an ICAP server for
processing, and then sent on their way. It also defines where those
messages may be vectored from the intermediary. I believe that its
primary design goal is efficiency, but that's different depending on
who you talk to.
SOAP can IMHO best be thought of as an XML messaging convention, with
some protocol-like attributes (such as the RPC convention). SOAP is
designed to be transport-dependant; while its most common use is
across HTTP, it can be used with other underlying protocols like SMTP
or raw TCP. SOAP is designed to allow targetting of blocks of the XML
to be processed by specific intermediaries. Its primary use cases are
'Web Services', i.e., the machine->machine Web, e.g., stock quote
services, order queuing, etc.
So, SOAP could be used to implement ICAP, but then again so could
BEEP. Not too many of the ICAP people are interested in using SOAP,
though, as their requirement is to allow 'wire-speed' vectoring and
processing, and they find the overhead of XML unacceptable.
Cheers,
On Mon, Jun 25, 2001 at 04:11:01PM +0800, Wanghong Yuan wrote:
> HI, All
>
> Where can I find some materials or dicussion on ICAP and SOAP? I think
> both of them address somewhat the content adapation problem in Internet.
> Thanks.
>
> Wanghong
>
Speaking for myself,
--
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)
