Subject: Comparison of ICAP and SOAP

From: "Wanghong Yuan" <[email-masked]>
Date: Mon, 25 Jun 2001 16:11:01 +0800

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 25 Jun 2001 16:15:35 -0700

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,

> both of them address somewhat the content adapation problem in Internet.

Speaking for myself,

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

---

From: "Lee Rafalow" <[email-masked]>
Date: Wed, 27 Jun 2001 08:41:06 -0400

I'm not sure why we're doing this on the ietf discussion list, but it's
clear they have nothing better to do....even so, I suggest we move this to
the OPES list.

> BEEP.

There is a SOAP over BEEP proposal.  SOAP provides the RPC binding semantic
and BEEP provides the transport.  We may need to make sure our requirements
are properly addressed, but that's business as usual.

> Not too many of the ICAP people are interested in using SOAP,

I haven't taken a poll so I can't comment on how many of the icap
implementers are rethinking their implementations.  When we polled people at
the last OPES workshop, there were only a few people who knew anything about
SOAP.  Thus my previous assertion that icap was created in isolation (and is
a flash in the pan).  I assume that as rational IETF participants, when we
do a careful comparison and as people learn more about it, we'll see some
movement of opinion.

But, I can state that there is very significant support for SOAP-based
solutions in the industry.  SOAP applies when a web service (e.g., an web
intermediary) needs to call on another for services (e.g., content
adaptation).  For example, a service that provides language translation
could be called from an origin server or from an intermediary or, for that
matter, directly from a client.  We should have two (or more) bindings for
that service?  Seems silly to me.  And if you really want edge services to
be a thriving part of the enterprise or ISP market places, seems like you
should use the service bindings that other web services are using.

As for XML overhead, I'm not sure what overhead there is?  One can build
syntactic routines that optimize for the supported functions if there are
concerns about the soap envelope structure.  However, from what I've heard
and from my observations of the icap formats and protocol the real concern
was code reuse.  They wanted to be able to use existing (or nearly
unmodified) web servers.  Well, that may have been fine for a tactical
solution, but the industry is using the web services infrastructure
(SOAP/XMLP, UDDI, WSDL).  OPES should do so as well.

BTW, since the icap forum has found another standards body to rubber stamp
their work, I think we can move on (except for whatever useful development
experience might have been gained in the process).  They get their marketing
literature and we get to do something useful for the industry.

P.S.  I normally work in pairs, I play the bad cop...someone want to pick up
the good cop role?  Cheers.

Lee M. Rafalow
Voice: (919) 254-4455, Fax: (919) 254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/502
RTP, NC 27709 USA
Alternate email: [email-masked]
Personal email: [email-masked]

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 27 Jun 2001 16:27:13 -0700

> do a careful comparison and as people learn more about it, we'll see some

Excuse me, Lee, but I am getting tired of the marketing bull associated
with SOAP.  The fact of the matter is that SOAP was defined by a far
smaller group of people with no open industry involvement and then moved
to a pay-per-view pseudo-standards body for ratification.  It is not and
never has been implemented in real Web services, in spite of the marketing
splash of "Web Services".  This doesn't mean it is better or worse than
iCAP, but it is completely foolish to disparage iCAP for being developed
outside the normal IETF process when SOAP didn't even come close to that.

My view on OPES is that if nobody has implemented it, there is no point
in standardizing it.  There is no reason why people can't implement an
iCAP-like RPC mechanism in the form of SOAP over BEEP (or whatever),
but until someone does it and actually deploys it for a real application,
any claims about its suitability for this purpose are just marketing bull.

Just to be clear, I don't like iCAP as a protocol (I have implemented an
earlier version) and I don't like SOAP as a protocol (even though the
only real implementation of SOAP is now an Apache project), but more
importantly the problem with them related to OPES is that an RPC callout
mechanism has no business being inserted into the Web architecture (which
was designed for pipe-and-filter style processing of streams).  There is
no way that an RPC mechanism will ever be as efficient for this task
as a proxy/gateway mechanism that operates on the data in-stream.

....Roy

---

From: "Lee Rafalow" <[email-masked]>
Date: Thu, 28 Jun 2001 10:38:26 -0400

Roy, I feel compelled to respond out of self defense but will not engage in
a lengthy discussion about personal motivations or other meta-issues.

Suffice it to say that I think a certain amount of skepticism in this line
of work is healthy but, like it or not, engineering is an economic
discipline.  I'm getting paid to produce a standard that is consistent with
other things the industry is doing (and, yes, my employer too).  No
marketing bull, just market realities: SOAP is real.  (Please note the
semantic difference an "ing" suffix makes not to mention the word "bull.")

If, at the end of the process, we agree that SOAP is not a technically sound
foundation for our solution, fine;  let's just make sure that there IS a
process that isn't a foregone conclusion for ICAP.  I believe we'll find
that SOAP is a reasonable foundation; it's being offered as an alternative
working hypothesis.  I stand by my comments about ICAP:  it was developed in
isolation without considering the larger picture of what's happening in the
industry for calling remote web services and I do think, therefore, that
it's a flash in the pan.  Time may tell otherwise and may even tell that
SOAP will have been a flash in the pan, but I doubt it...too much money
being invested by MANY companies to make it work from both a code and, yes,
a market perspective.  And engineering is an economic discipline.

I suggest we get on with the work at hand.

Lee M. Rafalow

---

From: "Manoj Dhooria" <[email-masked]>
Date: Fri, 29 Jun 2001 18:02:47 +0530

Just to stir-up this soup some more, why is there no "web services" standard
protocol that lets my client submit "API" requests via HTML forms
programmatically. I can understand some framing standard for returned data
but I find it just plain stupid that I should have some code running at
*both* client & server end before I can even begin testing my application!
If only I could submit my "API" request via an HTML form, I could begin
testing server code without writing a line of client code. Sole reason I
personally have junked all so called web service "API call" protocols for my
application.

Would welcome any comments.

Manoj Dhooria
Geometric Software [www.geometricsoftware.com]
Bombay

-----Original Message-----
From: Lee Rafalow [mailto:[email-masked]]
Sent: Thursday, June 28, 2001 8:08 PM
To: Roy T. Fielding
Cc: [email-masked]; [email-masked]
Subject: Re: Comparison of ICAP and SOAP

Lee M. Rafalow