at a first cut, chaining gets second priority.
however, the architetcture does not preclude it. chaining can be addressed
later once the main issues are resolved.
abbie
-----Original Message-----
From: Andre Beck [mailto:abeck(_at_)bell-labs(_dot_)com]
Sent: Friday, May 31, 2002 10:29 AM
To: Rochberger, Haim
Cc: Markus Hofmann; OPES Group
Subject: Re:
http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re
qs-00.txt
Rochberger, Haim wrote:
Is it still possible to add this requirement ? I mean
chaining callout
servers ?
This may improve the performance in case you have a few
callout servers
that need to handle a specific message in order.
Callout server chaining would add a lot of complexity to callout
transactions and callout servers, e.g. in terms of error handling,
fail-over, tracing, trust relationships etc. I can only see
performance
benefits in cases where the distance between the callout servers is
shorter than the distance between the OPES processor and the callout
servers. However, I think whenever the performance of callout
transactions is critical, it is much more likely that the callout
servers will be co-located with the OPES processor, i.e. in the same
domain. Hence the distance between the OPES processor and callout
servers would be similar to the distance between the callout
servers and
there wouldn't be much of a performance benefit any more with callout
chaining.
-Andre