Subject: RE: Comparison of ICAP and SOAP

From: "Tomlinson, Gary" <[email-masked]>
Date: Thu, 28 Jun 2001 11:17:18 -0700

On Wed, Jun 27, 2001 at 04:27PM, Roy T. Fielding wrote:

>
>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.

I disagree with the characterization that RPC callouts don't belong in the
OPES framework.  Operationally, the proxy/gateways processing of the
in-stream data can be broken into fast-path and slow-path operations.  I
characterize fast-path as deterministic operations that can be done in
real-time without interfering with the provisioned performance and scale of
the device. 

Proxying of the data without any additional services clearly falls into the
fast-path.  Additional services such as the proposed Edge Side Includes
(ESI)look so far to me to also fit into fast-path, since they have
predictable behavior and thus can be optimized for real time processing.  

Other services such as virus detection have unpredictable processing times
and stall the pipeline process of the proxy.  This is clearly a slow-path
operation.  Experience has shown that slow-path operations can adversely
affect the performance and scaling proxies.  Having a OPES callout RPC to a
buddy server for these operations makes sense, since the operation itself is
much more expensive to perform than the latency tax of the callout RPC
protocol.  The strategy being to have a separate cooperating system handle
these expensive operations and keep the precious proxy resources applied
fast-path operations.

I also don't think one size fits all for OPES callout RPC protocols,
something I pointed out at the recent OPES workshop.  Operations that work
on headers (URL rewrite comes to mind) or small objects are well suited to
fine grain RPCs, while operations that work on entire objects (virus
scanners come to mind) are well suited to complete stream vectoring RPCs.
This leads me to believe the OPES framework needs to specify callout
protocol requirements that allow for the possibility of multiple callout
protocols in order to optimally address these differences.

Remote callouts also provide an extensible services model for proxies as
well.  Many of the  proxies are appliance based and don't allow general
services to be hosted on them in order to maintain highly reliable and
deterministic service.  OPES remote callouts provide a mechanism to deploy
new services that may eventually be implemented in the fast-path should
their service demands warrant it.

ICAP provides a means today for handling the complete stream vectoring
applications like virus scanning reasonably well.  SOAP on the other hand
(yes it really is implemented) for granular RPC applications and is showing
some promise for large objects via its attachments.  IMHO, this biggest
missing link is a standardized framework and policy model to invoke the
services, both fast-path and slow-path, including the remote callouts.  

My .02
Gary