Re: diffs between Austin IDL and current draft

[Carol Burt <cburt@2ab.com>]

Hi,

>1. In the current draft, struct DecisionResult{} contains PolicyName as
>opposed to PolicyEvaluator.
>
Actually DecisionResult is the Ternary enum now... see latest draft.  After
a short conversation with Bob Blakley today... the DecisionResult became
the Ternary(Trinary).  There are no methods on PolicyEvaluator that made
sense for calling at that point so it was PolicyName or nothing... Bob and
I decided today to take out any reference to the policy and see what
comments we get.  

>2. In the current draft, PolicyEvaluator::evaluate() returns DecisionResult
>as opposed to Ternary (defined as Trinary in Austin IDL)
>
DecisionResult is now the Ternary... so essentially it goes back to the
same thing.

>I just want to be clear if this is intentional or an oversight. Is this part
>of the PolicyEvaluatorAdmin discussion?
>
It's intentional and "yes & no"... :-)

>With regard to PolicyName and what it means, I recall that PolicyName is
>just something that Identified either just an evaluator, in the case where
>the evaluator is implemented as a process which is the policy, e.g., some
>Java Classes, or a pair (interpreter, script), in the case where the
>evaluator is implemented as an interpreter of some script that represents
>the policy, e.g., SQL. 

Could you diagram that sentence? :-)   As I understand it, a PolicyName
identifies a "policy" which might manifest itself at runtime in any of the
ways you mention above but is out of the scope of our submission to define
(or name).  We can, however, apply a policy by name to a resource (by name).  

>Am I remembering incorrectly?
>
Yes... it just raises a number of interesting questions about the expected
behavior of PolicyEvaluator whose Admin interface has been called with
multiple policies assigned to a ResourceName and whether different
implementations are expected to behave consistently.

We can apparently apply multiple policies by name to a single resource (by
name).  We do this with the PolicyEvaluatorAdmin interface.  Since this is
a "PolicyEvaluatorAdmin", it would stand to reason that we expect the
PolicyEvaluator we administered to be able to evaluate potentially multiple
encapsulated policies.   When I have to define what a method does with
if-then-else logic, I start to suspect we've made a mistake - either in the
model or the methods.  PolicyEvaluatorAdmin::apply_policy() imho has this
problem at the moment.  

Carol

_________________________________________________________
Carol Burt                                             2AB, Inc.
cburt@2ab.com                                     Integration Architects
205-621-7455                                        www.2ab.com
Member, OMG Architecture Board          OMG Domain Member

   --  integrating yesterday's systems with today's technology --
----------------
Broadcast message to hrac-rfp from Carol Burt <cburt@2ab.com>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.