Re: Chaining of Callout Servers

Hilarie Orman, Purple Streak Development wrote:

> 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.
What about the impact on policy enforcement and authorization and on 
the underlying "trust assumptions"? For example, would you assume that 
the servers in the chain are explcicitly identified, or that the first 
callout server can freely decide to which other servers to chain? If 
the callout servers are explicitely identified, who decides whether to 
do chaining or not?
Example: After rule evaluation, the OPES processor determines that 
Service A on Server 1 has to be performed as well as Service B on 
Server 2. Does the OPES processor decide to chain Server 1 and Server 
2, or does the OPES processor leave this decision to Server 1? What 
metric is used to decide whether Server 1 and 2 should be chained or 
whether it would be beneficial to first callout to server 1 and then 
to server 2? Is this a static configuration? If Server 1 decides, can 
we assume that the user is fine with his decision to chain out to 
server 2, i.e. is there an implicit trust relationship?
> > 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
I was also thinking in terms of implementation complexity. Wouldn't it 
be necessary that callout servers now also temporarily store messages 
until they come back from the chained callout server, for example in 
order to avoid data loss in case the chained callout server fails 
(just as the OPES processor does). What about handling failure of 
chained allout servers in general, wouldn't that add complexity? 
Somehow, a callout server chaining to another callout server reminds 
me a little bit of an OPES processor (towards the chained callout 
server)...
> > reliability, 
> might have more delays, more opportunity for broken connections
... and requires callout servers to temporarily store messages (until 
they come back from chained callout ervers). As a result, a single 
message might end up being stored in a chain of OPES processor and 
callout servers (rather than just in a single OPES processor).
What about if a chaining callout server fails? Example: OPES processor 
does callout to Server A, and Server A chains to Server B
  OPES processor --> Server A --> Server B

What happens when Server A has forwarded the message to Server B, and 
suddenly Server A fails. What does Server B do with the message? Does 
it know that it would have to be sent back to the OPES processor? 
Would the OPES processor be able to handle a message coming from 
Server B rather than from Server A? What about similar scenarios with 
much longer chains? Seems like its getting more and more complex...
> > fault-tolerance, 
> slight increase in most cases, due to more machines being available
> for processing
Hm, or vice versa, see above.

> > data integrity, 
> no change
Yup, also don't see an issue here.

> > 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
Hm, yup, agreed.

> > 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.
Ah, OK, this might answer my very first question. You seem to assume 
that the OPES processor only knows the first callout server, and that 
it is up to the first callout server to decide whether and how to 
chain to other callout servers. Is this correct?
If so, does this have any impact on the policy enforcement framework? 
Because now the overall control is no longer solely in the OPES 
processor, but we've sort of a second "decision point" in the first 
callout server.
> > And would the expected 
> > benefits outweigh the additional complexity?
> There's little complexity added to the protocol.
Well, maybe little to the protocol, but I'm not yet completely 
convinced that there would also be little additional complexity to 
implementations and also with respect to falure handling.
-Markus