RE: [soa-rm-ra] Policy Types

[Danny Thornton <danny.thornton@scalablearchitectures.com>]

Looking at the constraint:

> A company has a policy that states; if the order flow is greater than 
> some number, orders MUST go to warehouse B else they MUST go to 
> warehouse A.

The following is an example yes/no policy constraint to point out the
difference between a grant/deny and the order flow example:

If a participant is authenticated and has a role of admin, then they
have access to administrative functions.
 
Where the orders must go is a statement about the future which fits into
the definition of an obligation for the RA.  There could be two
interpretations about how to handle the obligation in Figure 48.  The
obligation could be handled by the Enforcement Point or the Measurement
Point.  I would argue that the programming logic to handle the order
flow example would be classified as part of the Enforcement Point rather
than Measurement Point because the order policy statement is more about
enforcing the obligation than about measuring and monitoring the
obligation.  

If I were to implement the order flow example, the programming logic
would have to be coded such that a change in policy could determine
which warehouse the order goes to.  As a programmer, if I am going to
allow a policy to determine the destination warehouse then I would
program a call to the decision point where order number is a variable
for the decision point.  I would then have to program something to
handle the behavior based on what could be returned as an obligation. 
As a policy writer, I could list obligations for warehouse A and
warehouse B based on order number.  The ability to do this is dependent
on the expression of the policy language.

In the implementation of a system with policy guided behavior, the
software developers and policy writers have to make discretionary
decisions about what business logic will be handled by the developers
and what business logic will be handled in policy.  

Danny

-------- Original Message --------
Subject: [soa-rm-ra] Policy Types
From: Don Flinn <flinn@alum.mit.edu>
Date: Sun, June 01, 2008 4:22 am
To: soa-rm-ra <soa-rm-ra@lists.oasis-open.org>


As defined in Fig 46 pp 74 - Policy is either a permission or an
obligation

I believe that certain business policies do not fit within either policy

class. There are machine readable policies that mandate that a computer 
follow a specific course of action depending on the state of the 
ecosystem. While there may be an obligation on the policy writer to 
write a policy to follow certain criteria, the policy writen for the 
machine has no such abiguity. An obligation is the act of binding 
oneself (in the service case, itself) to follow a particular course of 
action, which the service may or may not do. Given a particular state 
of the ecosystem the machine MUST follow the course of action dictated 
by the policy.

For example:
A company has a policy that states; if the order flow is greater than 
some number, orders MUST go to warehouse B else they MUST go to 
warehouse A. This is not a permission and I have a hard time conceiving 
this as an obligation. In my example the service has no choice but to 
use the given address / endpoint depending on the state of the 
ecosystem. So it seems to me that the positive & negative policy 
constraints are aggregates of permissions, obligations and what I'll 
tentively call - instructions.

One of the purposes of SOA is to facilitate the replacement of humans by

machines. In order to do this, the machines must be made more 
"intelligent", i.e. they must be able to autonomously handle variations 
in the ecosystem, as far as possible. Properly written business 
policies support this.

I believe that the number of business policies giving direction and 
instructions to the machines to cope with varying circumstances will be 
in the majority. 

Don

-- 
Don Flinn
President
Mansurus LLC
e-mail: flinn@alum.mit.edu
Tel: 781-856-7230
http://mansurus.com


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php