[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Chaining of Callout Servers
I'll take a stab at this, based on the assumption that all we
need is one new header ...
> Question to the group: What's the consensus - should we explicitly
> allow/support callout server chaining?
It's impossible to prevent it, it would be good to support it. I don't
think there's any impact on the protocol beyond adding a "This is part
of a callout chain" header.
> If yes, what are the impacts
> with respect to complexity,
local configuration must show which servers are available for OPES
processing, but that's not part of the protocol we are developing
> reliability,
might have more delays, more opportunity for broken connections
> fault-tolerance,
slight increase in most cases, due to more machines being available
for processing
> data integrity,
no change
> privacy, security,
if machines are in the same admin domain, no change; would recommend
strongly that machines be restricted from communicating outside the
admin domain, but there's no way to enforce this
> etc?
Don't know of any.
> What are the specific scenarios in
> which such a mechanism would be beneficial?
Anytime the communication overhead is much less than the processing time
one will find that pipelining is a good idea. This also relieves the
OPES data processor from having to maintain a map of the services points
within the local infrastructure - the first service processor can plan
the processing pathway, handle failure detection and failover, etc.
> And would the expected
> benefits outweigh the additional complexity?
There's little complexity added to the protocol.
Hilarie