On Wed, 12 Mar 2003, Oskar Batuner wrote:
For that matter I'd suggest that callout processor should not be
able to communicate with OPES participant directly, only through
OPES server. This will provide the required level of isolation. OPES
processor may use callout protocol to communicate certain requests
to callout processor and send responses back to the user/server.
On the other hand, callout servers already communicate with ends, by
modifying application messages (which is their primary purpose)!
And they send these messages ONLY through the OPES processor. My point
is that as OPES processor is the principal point of contact between
OPES flow ends and the OPES application it should be the only
point exposed to the end user/server.
Two problems:
- It looks like Markus (and others?) want callout servers and
even services be traceable and, hence, exposed to the ends to a
certain degree. We will need to get some consensus here. What
is exposed to ends? If something is exposed, does it communicate
with ends? If it does, what "band" is used?
As far as I understand we have two-layered architecture: one layer is
present in the OPES flow, another supports all out-of-band functionality
prescribed by the OPES spec but specifically excluded from the OPES
flow (like rules distribution).
For the OPES flow (in-band is just another name for that) the only point
exposed is OPES server IP (that MUST be exposed by the IAB requirements).
The only way to communicate at that level is the application protocol
(original or extended). In the second layer any point may be exposed,
e.g. privacy policy server. It may even be unreachable to the OPES
server by callout protocol: OPES entities are not required to use
the callout protocol as the only method of communication.
And if something is exposed - it is exposed exactly to enable the ends to
communicate with it. Method of communication is determined by the role of
the exposed component and the method of exposure.
Does this make sense?
- If callout servers communicate with ends via application
protocol (by modifying application messages), then
"communication through OPES processor" does not mean that the
OPES processor actually understands what is going on. The OPES
processor, in this case, may be a dumb relay. I think that
contradicts your intention to have "required level of
isolation". Dumb relay is a poor "isolator".
Let me disagree. To some degree a medical office receptionist arranging
an urgent visit to any available doctor may be a good example: he/she
acts as a dumb relay (does not attempt to evaluate patient's medical
problem details) but still pretty well isolates patient from dealing
with multiple doctors' schedules and doctors from interruptions from
all the patients trying to arrange a visit.
Even a dumb relay MUST understand what is going on: it MUST know that
specific callout server supports all OPES requirements and just passing
messages through will not result in violation of these requirements.
Depending on the OPES application architecture OPES processor may
or may not perform certain checks and insert certain information.
But as a policy enforcement point it is responsible for implementing
the policy - in cooperation with callout servers.
If we do want to make OPES processor the only point of contact
and truly remove callout servers from the end-visible picture,
we need to do the following, at least:
~ adjust processor->callout server interface from current
"do whatever you want with this message, I will just
forward the result; and please obey OPES rules
(e.g., add tracing)"
to
"do whatever you want, tell me what
you did, I may apply more processor-specific modifications
based on what you did (e.g., add tracing), and I will
build and forward the final result"
I'm not sure we have well defined notion of what the current interface is.
Here you are looking at another dimension of the problem: should the
distribution of functions between OPES processor and callout server
be completely deterministic (predefined for a particular application)
or we provide greater flexibility by allowing some level of
negotiation, as in your second option.
I think it can be both ways. If function distribution is deterministic
no additional support is need at the callout protocol level. Each
component knows what functions it has to perform and what functions
will be performed by another component. For example some tracing
information can be added by any of them, component just
should know in advance that it is his function, while some
tracing information may be available only at the point where
the transformation is actually performed.
To implement your second option callout protocol should provide
some support for negotiations. These additional functions may be
grouped together and specified as a different level of protocol
implementation.
~ prohibit delegation of callout services from
callout servers; support such delegation from OPES processor
only (the callout server would have to tell OPES processor
to delegate)
I don't see the reason for such limitation. OPES processor is not
interested in callout server architecture - is this one box, farm,
grid, or hierarchy connected by callout protocol. As long as all
OPES requirements are met any internal delegation is irrelevant.
I think when we abandoned special requirements for cascading
we in fact accepted this "black box" approach.
Is that something you are after? Do you want to limit
callout server role to message adaptation only and have
_all_ OPES-related features to be enforced by the OPES
processor?
Again, my approach is that specific distribution of functions may be
left to the specific application implementation. The only important
thing is to guarantee that all OPES requirements are met. Is this
guarantee achieved by deterministic function distribution, what
specific distribution is used in each particular case or a
reliable negotiation protocol is used to establish such
distribution dynamically - is irrelevant.
Distribution of OPES application functions between components may
even change dynamically as adaptation to the load conditions.
Yes, of course.
If you have a single user contact point this may scale pretty well,
otherwise the user has to be involved in the process in which he/she
is not interested at all - function distribution between OPES
components.
The user does not have to be involved in the process if her
preferences remain constant. It is the role of the OPES system to
correctly react to dynamic changes within the OPES system. Are you
implying that the user may have different preferences depending
on the actual OPES system in use?
I imply exactly the opposite - user should have a guarantee that as
soon as his/her preferences are made known to OPES they will remain
in force even if system makes dynamic configuration changes. And the
best way to guarantee this is to provide the user with the single
communication point. In fact there may multiple communication points,
but for each function there should be exactly one. If a callout
processor is exposed as such point no dynamic reconfiguration is
possible unless this processor is able to distribute information
communicated by the user to all new system participants. Add to this
redundancy and (transparent) fallback requirements and you'll see the
picture behind my reasoning.
Oskar