ietf
[Top] [All Lists]

Re: Comparison of ICAP and SOAP

2001-06-27 16:40:03
On Wed, Jun 27, 2001 at 08:41:06AM -0400, Lee Rafalow wrote:

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.

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



<Prev in Thread] Current Thread [Next in Thread>