Hi,
I for one, who was in favor of the chaining "feature", gave it some thought
and realized
that it is going to make things more complicated. It will add more massages,
and will
require the OPES engine to act as server (B needs to notify the results,
etc).
So I suggest to remove this requirement (at least from this stage).
Yours,
Haim Rochberger
Comverse.
-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Tuesday, July 23, 2002 5:29 AM
To: OPES Group
Subject: Chaining of Callout Servers
Hi,
we want to wrap up the existing three OPES WG documents and issue a WG
last call as soon as possible!! In order to do so, we need to find
consensus on the few remaining open issues that came up during the
meeting last week!
One issue that affects all three documents is the question whether we
should allow/support chaining of OPES callout servers. Chaining of
OPES callout servers refers to a scenario in which an OPES processor
forwards a message to callout server A, and callout server A forwards
the same message for (additional) servicing to callout server B.
We had a brief discussion on this issue on the general OPES mailing
list before, in the context of OPES callout protocol requirements, and
the feeling somehow was to *not* require protocol support for callout
server chaining. However, the scenarios doc (and the architecture
doc???) still have the notion of server chaining in.
Question to the group: What's the consensus - should we explicitly
allow/support callout server chaining? If yes, what are the impacts
with respect to complexity, reliability, fault-tolerance, data
integrity, privacy, security, etc? What are the specific scenarios in
which such a mechanism would be beneficial? And would the expected
benefits outweigh the additional complexity?
Any opinions on that?
Cheers,
Markus