well, as I said I think it's powerful but as you put it, before we pursue
that from a WG perspective we should look at pros and cons. Some of them:
Pros:
- service execution time can be improved significantly (there would be no
more "weakest link", or should a say slowest link)
- Failover/Reliability - If one call out server goes down it wouldn't affect
other services
- Alternative method - have the services sequentially also has its own
problems anyway (e.g., ordering and one of the servers on the sequence is
down or too slow)
- Inline with future deployments - Whether or not we have parallel requests
IMO there will be different call-out servers for different specialized
services anyway
- Some optimizations are possible, a quick example is that if you know that
the content filtering service already told you that the page will be
blocked, there is no need to go/wait for the other services/servers (as
opposed to a sequential services chain).
Cons:
- You have to make N copies of the same message (you might use multicast and
other techniques though...)
- You have to have a timeout policy to deal with slow/down call out servers
- You need to able to reconstruct the whole message again based on all the
decoupled modifications (this might be tricky..)
- More complex in the sense that the OPES local env. would need to be the
arbiter of possible conflicting services, ie, services that modify a common
parts of the same message. You can argue that this is already included in
the item immediately above.
thanks,
Reinaldo
-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Wednesday, March 06, 2002 12:34 PM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: The Purple Streak (Hilarie Orman); ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: comments on
draft-dracinschi-opes-callout-requirements-00.txt
Hi,
I agree that parallel service requests (actually to totally
different
call-out server) are very powerful, but the callout server
would never
known by its own whether its modifications on the message
are going to
affect other services or not. [...]
I agree, and it seems there might be several different approaches to
solve this problem, but each of them would add some complexity to the
system.
So, a general first question is whether we would like to allow
parallel service requests on the same message or not. What are the
expected benefits and do they justify added complexity? Any opinions?
-Markus