Hi Reinaldo,
IMO you have an external callout server for the some of the same
reason we have caches in the first places: offload processing,
reliability issues, technologic specialization issues, etc...
In the technologic specialization front, for instance, if you want
Virus Scanning you will need to process periodic updates, port
somebody's else code in to your box, etc, etc. Are you going to put
this on the OPES box per se or let somebody that knows how to do it
best take care of that for you? You can extend this to a lot of
other services: content adaptation, geographic services, Content
Filtering, and so forth.
True; I wasn't saying that there isn't a need for callouts, just an
exploration of how they're used. Perhaps because of OPES' early
history with ICAP, I get the feeling that some people think that
OPES = callouts, which isn't true.
There are a few costs to using a callout protocol; the most obvious
are overhead (both in packaging the messages and in delivering them
over the network) and security, but also there are issues in the
failure modes, etc. that the network introduces. Also, it's difficult
to make all of the information that's available to the local
environment available to the remote environment. [1] has some
interesting things to say in this regard.
The benefits seem to be centred around flexibility and segmentation;
you are able to deploy services and have them effected in different
places on the network, and you're able to rigidly separate services
from each other and other messages, and have services provided from
administrative domains which are different than the intermediaries'.
I think that most scenarios will preclude deploying services far away
from the intermediaries; unless they provide exceptional value, and
are sparingly applied, the latency cost is too great, and the added
network traffic is undesireable. OTOH, deploying them in close
proximity to intermediaries gives nice segmentation, as you point
out. These deployments will have to overcome the cost of running two
boxes to provide a service, though (especially considering the
advances in JVMs and virtualisation in general).
Perhaps part of the decision will be the nature of the service. Your
arguments for third-party proprietary services support the need for a
callout protocol. One of the things that I'd like to see more of is
the standardisation of common service definitions for things like
caching, transcoding, etc., so that they can be run on an
intermediary without moving code around; these kinds of services lend
themselves more to running locally.
Just my .02. Am I missing other benefits (or costs) of using
callouts?
1. http://research.sun.com/techrep/1994/abstract-29.html
--
Mark Nottingham
http://www.mnot.net/