[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