ietf
[Top] [All Lists]

Re: Comparison of ICAP and SOAP

2001-06-28 07:40:06
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
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: rafalow(_at_)us(_dot_)ibm(_dot_)com
Personal email: lrafalow(_at_)mindspring(_dot_)com

----- Original Message -----
From: "Roy T. Fielding" <fielding(_at_)ebuilt(_dot_)com>
To: "Lee Rafalow" <rafalow(_at_)raleigh(_dot_)ibm(_dot_)com>
Cc: <ietf-openproxy(_at_)imc(_dot_)org>; <ietf(_at_)ietf(_dot_)org>
Sent: Wednesday, June 27, 2001 7:27 PM
Subject: Re: Comparison of ICAP and SOAP


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>