With respect to scale, I still need some more thoughtful
insight to
justify your claim.
Having each of the clients (e.g.
1000 PEPs each making 10 calls on a
single PDP a second) get and supply the
information to a PDP that has to
do 10,000 decisions a second, scales far
better than putting all the work
on the PDP and making it perform remote
calls to a data repository for
each access decision.
Sorry
for getting back on this discussion, I should
probably just give up : but that example is wrong. Once you
have any single master data repository - RDBMS most likely, or some local
image of it, having as close consumer as possible is
preferrable. And PDP is much more likely to be "local" - same
machine/subnet - even running on top of a database in some cases then
multitude of distributed clients. I am suggesting scaling/clustering
PDPs as needed, and cutting down on remote queries and
traffic. That's why people have stored procedures, is not
it?
Other example would be a PDP
running alongside a directory server. Should clients access
relevant data indepently, then resend it along with the request to PDP -
or is it faster to access it locally?
Also - client may not know what
information is relevant. If you have 100 different actions. For
each action some information is needed to evaluated - as described in the rule
- should PEP prepare and send ALL potentially avalaible data along with the
request - or PDP will retrive just the relevant one during the rule
evaluation? I think the second case is far more preferrable - PEP has no
information about rules, and can not optimise it. Thus supplying information
along with the request may scale O(N), as you add actions, and O(1), if data
is retrieved locally..
And to
effectively cluster PDPs, provisions for
error handling in protocol seem to be essential.
Daniel.
