>From: Mark Nottingham [mailto:mnot@xxxxxxxx]
>Sent: Friday, March 01, 2002 9:42 PM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: OPES list
>Subject: Re: comments on draft-dracinschi-opes-callout-requirements-00
>> 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.
yes, that's true. Altough failure problems would also apply in the case everything in bundled in the "local" device. If the local device goes down you stop offering any OPES services. If the remote callout goes down you stop offering that specific service...so, it's always a tradeoff
As for the overhead of packaging, thre is no way around it.
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.  has some
>interesting things to say in this regard.
I agree, altough IMHO the "local" environment wouldn't have access to all information either. In a network with possible thousands of subscribers where different OPES services are selective applied depending on time of day, geographic location, accessed file, bandwidth, etc the most scalable form would a distributed databased where the remote callout server and also the OPES local environment could query whatever information they needed.
In this way they could query whatever information they needed separately, not depending on each other for this specific purpose.
>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).
agreed, deploying callouts "away" from the local env wouldn't be common, but it's very possible. Which brings the question that if the callout is crossing a possible large network, should it be congestion aware and reliable? Possibly yes, otherwise it would restrict network deployments or we would need to put this functionality on the callout protocol itself.
>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.
I would also like to see that.
>Just my .02. Am I missing other benefits (or costs) of using
see above, I added some text. Summarizing everything I think the pros and cons reside on fail-over, packaging overhead, segmentation, information distribution and flexibility.
Is there anything else?
> 1. http://research.sun.com/techrep/1994/abstract-29.html
just downloaded. Will read it.