The document discusses policy driven development for large scale systems. It describes the problem of requirements changing over time which can lead to buggy and obsolete code. The proposed solution is to use policy languages to allow flexible insertion of policies at runtime. This avoids hardcoding requirements and allows systems to adapt over time. Examples of using policy languages in the real-world PALMS system are provided to control access and perform auditing. The benefits of the policy approach include injecting control, filtering and adding new features via policy without changing code. This enables policy-driven composition of applications at runtime.
2. Developer The Problem
2
Stakeholder
Code
Run
Implement
Buggy code
Misinterpretation
Misimplementation
Misspecification
Obsolete-on-arrival
Impedance mismatch
Need
Refinement
Clutter and overgrowth
Requirements
Long development
Long release
Source unavailable
Personnel attrition
Consequences
• Stakeholders disaffected
and disenfranchised
• Lost productivity
and opportunity
Observation
• Agile doesn’t scale well
3. Roadmap
• Problem description
• Solution outline
• Examples in real world PALMS system
• Policy languages – a Domain Specific Language (DSL) approach
• System of Systems composition
• Evaluation
• Conclusions
• Future work
3
4. The Problem (cont’d)
signOn()
amount = keyWithdrawalAmount()
dispenseCash(amount)
4
New requirements
1. Error if out-of-state
2. Max withdrawal $100if user.outOfState then
error “out of state”
return
amount = min(100, amount)
if not verifyNewAmount(amount)
error “cancelled”
return
Approaches
• Explicit coding
• Property files
• Active Directory, et al
• ABAC/RBAC
• Policy engine (PDP/PEP)
• Aspects (AOP/AOSD)
5. PALMS ListDevices
Device
Repository
Client
❸❶ ❷
❽ ❺❻❼
Storage
❹
PALMS ListDevices
Device
Repository
Client
❸❶ ❷
❽ ❺❻❼
Storage
❹
Return
ErrorIf User ≠ “Bob”
PALMS ListDevices
Device
Repository
Client
❸❶ ❷
❽ ❺❻❼
Storage
❹
Return
Error
Remove Unauthorized Devices
If User ≠ “Bob”
Insight
5
• Applications as workflows (workflow activity = service = function)
• activities exchange messages
• activities perform work
• Workflows composed at runtime
• Interactions must be identifiable at runtime
• Messages must be interceptable
• Policy as decision that selects amongst workflow alternatives
• Policy programming: upgraded activity that compliments existing processes
Consequences
• Inject control, filter, and feature
via policy
• Stateful policy = application
Policy-driven runtime
composition of applications (SoS)
6. Mechanics
6
I0 O0
I1
I...
O1
O...
S
S
D
C
S
D
C
I O P
IP
OP
OP, IQ
IP,OQ Q
OQ
IQ
P⨂Q S
OP
RPQ
P QIQ
OQ
IP
I,O
❻
Router
Messenger
Service/Data
Connector
Service/Data
Connector
{
{
Rich
« Infrastructure »
Services
Rich
« Application »
Services
Service/Data
Connector« PALMS Rich Service »
❶
❷
❸
❹
❺
❻
Device
Repository
Data
Repository
Service/Data
Connector
Context
Manager
Service/Data
Connector
Event
Logging
Service/Data
Connector
Policy
Evaluation
7. Mechanics (cont’d)
• Control Policy on <P,Q>
– RPQ calls Policy Evaluation RIS {IQ, P, Q}
– Fetch policy πcp for <P,Q>
– Evaluate policy πcp(IQ, P, Q) new service Wcp
– RPQ executes Wcp(IQ)
– PQ P RPQ Wcp
• Filter Policy on <P,Q>
– RPQ calls Policy Evaluation RIS {IQ, P, Q}
– Fetch policy πfp for <P,Q>
– Evaluate policy πfp(IQ, P, Q) new service Wfp
– RPQ calculates Wfp(IQ) IQ
– RPQ executes Q(IQ)
– PQ P RPQ Wfp Q
7
S
OP
RPQ
P QIQ
OQ
IP
I,O
Wcp
PE
Policy Repository
P,Q πcp,fp
IQ,P,Q Wcp
Pre-
Post-
8. Roadmap
• Problem description
• Solution outline
• Examples in real world PALMS system
• Policy languages – a Domain Specific Language (DSL) approach
• System of Systems composition
• Evaluation
• Conclusions
• Future work
8
9. PALMS Policy Examples
• Access Control
– Control Policy (at ❸)
– if (subject-in-any-study-role('PI,RA')) then ()
else return-error('Insufficient permissions')
– Filter Policy (at ❼)
– filter-by-any-role('PI,RA')
• Audit (at ❷)
– audit("AuditID1", ("event", "ListDevices"),
("subject", $Subject),
("deviceName", cur-value("deviceName")))
9
PALMS ListDevices
Device
Repository
Client
❸❶ ❷
❽ ❺❻❼
Storage
❹
Return
Error
Remove Unauthorized Devices
If User ≠ “Bob”
10. Context System
• Optimizations
– Workflow
– Session
– Custom
10
class Expression Data
EnvironmentHistory MessageApplicationState
PointsVisitedByMessage MessagesAtAPoint RowSet
XQueryStatement
Data
CredentialsEvaluation
12. Roadmap
• Problem description
• Solution outline
• Examples in real world PALMS system
• Policy languages – a Domain Specific Language (DSL) approach
• System of Systems composition
• Evaluation
• Conclusions
• Future work
12
17. Roadmap
• Problem description
• Solution outline
• Examples in real world PALMS system
• Policy languages – a Domain Specific Language (DSL) approach
• System of Systems composition
• Evaluation
• Conclusions
• Future work
17
19. Evaluation
19
# Operation Time (ms)
Client Storage, empty device DB 63 (54.5 browser +
7.2 server + 1.3 network)
❶ Single service interaction, no Policy Evaluator RIS 0.115
❷ ❶ + Policy Evaluator RIS, empty interaction DB ❶ + 0.203
❸ ❷ + 1 interaction, no policy ❷ + 0.007
20. Evaluation
20
# Operation Time (ms)
Client Storage, empty device DB 63 (54.5 browser +
7.2 server + 1.3 network)
❶ Single service interaction, no Policy Evaluator RIS 0.115
❷ ❶ + Policy Evaluator RIS, empty interaction DB ❶ + 0.203
❸ ❷ + 1 interaction, no policy ❷ + 0.007
❸ + control policy ❸ + 76.50
❸ + passthru post-filter policy ❸ + 78.62
❸ + actual post-filter policy, no records ❸ + 84.51
❸ + actual post-filter policy, 1/1 record ❸ + 91.66
❸ + actual post-filter policy, 0/97 records ❸ + 359.98
❸ + actual post-filter policy, 97/97 records ❸ + 818.08
21. Conclusions
21
Traditional
Programming
Runtime Workflow
Composition
Time to Market
Speed,
Complexity,
StrongGuarantees
Less More
More
• Guarantees
– Depends on DSL language
– Traditional AC languages?
– Dependencies deferred to runtime
• Policy Programmer must know:
– Interactions
– Messages
– Available services
22. Conclusions
• Policies are mini-applications composed into base
workflow
• Clear positioning of policy relative within highly complex
distributed system
22
23. Future Work
• Policy programming
– Verification
– Modeling
– Model checking
– Integration of modeling (simulation and debugging)
– Extend to stakeholders (directly)
– Integration of existing policy engines?
• Further speed optimizations
– Precompilation
– Harmonizing message formats or policy language to reduce conversions
• Secure Policy Deployment
23
26. Existing Choice Mechanisms
• Compile time constants
• Attributes in directories (permissions, owners, groups, etc)
• Permissions in property files (Tomcat policies)
• Attributes and permissions in registries (Active Directory, Facebook privacy,
Oracle database permissions)
• Attribute Based Access Control (ABAC) and Role Based Access Control
(RBAC)
• Declarative mechanisms (triggers)
• All amount to predicates that select workflows based on strategy, bridge, and
state patterns
• Policy Engines, PDP/PEP moves predicates to external policy, but placement
is constant
• BPEL Process Integration with Business Rules
26
30. The Technical Requirement
• Technical Requirements
– Support research workflows
– Security and privacy
– High reliability and availability
– Scalability (bandwidth/storage/users)
– Auditability
– Provenance and curation
• Key Insights
– All stakeholders must have requirements met, or CI degrades
– Existing development models have long latencies
– Requirements are often lost in translation
– Success of CI depends on
– Accurate, timely, and continuous requirement elicitation
– Precise requirement formulation
– Low implementation latency
– Automatic requirement composition
30
31. Policy Driven Development
• Goals
– Enable rapid customization
– Empower stakeholders to directly define behavior
• Service Oriented Architecture (Rich Services)
– Services loosely coupled
– Late binding
– Scalability
– Testable
– Interoperable
– Incremental development
– Composition
– Services can be hierarchically decomposed
31
34. Messenger
Router/Interceptor
Policy
Service/Data
Connector
Messenger
Router/Interceptor
Failure
Manager
...
<<Rich Service>> S
Service/Data
Connector
...
<<Rich Service>> S.n
Service/Data
Connector }<<
Rich
Infrastructure
Services
>>
Encryption
Service/Data
Connector
Logging
Service/Data
Connector
Failure Manager
Service/Data
Connector
...
Service/Data
Connector
S.1
Service/Data
Connector
S.2
Service/Data
Connector
}<<
Rich
Application
Services
>>
S.n.2
Service/Data
Connector
S.n.m
Service/Data
Connector
}<<
Rich
Application
Services
>>
S.n.1
Service/Data
Connector
Service/Data
Connector
Logging
Service/Data
Connector
Encryption
Service/Data
Connector
Policy ...
Service/Data
Connector
Service/Data
Connector
<<
Rich
Infrastructure
Services
>>
}
From tightly to l o o s e l y coupled systems
Rich Service Blueprint
34
35. Event Logger
Access
Policies
PALMS Integration System
Integration
Adapter
Data
Repository
HIPAA
Policies
Service/
Data
Connector
Viewer
Viewer
Adapter
Consumer Systems
Service/
Data
ConnectorSensor
Adapter
Sensor
Producer Systems
Subject
Repository
Service/
Data
Connector
Authoring
Calculation
Repository
Calculation Systems
ExecutionPrototyping
Failure Detection/
Mitigation
Logical Architecture
35
36. Rich Services Virtual Network
Rich Services
RAS4
Services
Service S1
Roles
U1
U2
U3
U4
U5
Use Case Graph
Concerns
C1 C2 C3
C4
CC1
CC2CC3
Domain Model
R1 R2
R3 R4
R5 R6
R1 R2
msg
R3
CC1
CC2
Role Domain Model
R1 R2
R3 R4
R5 R6
CC1 CC2 CC3
Router/Interceptor
Messenger/Communicator
RAS1 RAS2
CC1 CC4 CC5
Router/Interceptor
Messenger/Communicator
RAS5 RAS6RAS3
S
/
D
S
/
D
RIS:
RIS:
ServiceElicitationRichServiceArchitecture
RAS7
System of Systems Topology
H1 H2
H3
H5
H6
H7
H8
H9
H4
RAS1 RAS2 RAS3
RAS5 RAS6 RAS7
Infrastructure Mapping
H1:RAS1 H2:RAS2
H3:CC1
H5:RAS2
H6:RAS5
H7:RAS7H8:RAS7
H9:RAS6
H4:RAS3
Optimization
Implementation
RAS1 RAS2
RAS3 RAS4
RAS5 RAS6
RAS7 CC1
CC2 CC3
CC4 CC5
Analysis
Synthesis
Analysis
Identification
Definition
Consolidation
Refinement
Hierarchic
composition
Refinement
Logical Model
SystemArchitecture
Definition
Logical Architecture Loop
Deployment Loop
Rich Service Development Process
36
37. Spectrum of Sharing1
Trust Publish Interaction Quality Privacy Enablers
No one Nothing No one - - -
Friends &
Family
Subsets/
derivatives
Word of
mouth
Person to
person
Handshake
promise
None
Community ″ Conference
booths/
papers
Curation2 De-ident &
agreement
Auto de-ident,
Agreement
template3,4
Public ″ Repository/
registry
Taxonomies/
semantics
″ ″
1 C. Fennema-Notestine. Enabling Public Data Sharing: Encouraging Scientific Discovery and Education
2 Strong metadata, use common ontological framework, collection conditions & semantics, validated calculation &
visualization
3 Suggested IRB or HIPAA wording
4 Promise to not re-identify, use data at own risk, no quality guarantees, properly acknowledge data source
37
38. Deployment
Web Browser
(UI)
PALMS
Service
GWT RPC
Mule Messaging
Browser
Proxy (UI)
PALMS
Subservices
CXF Web Services
Mule Messaging
CXF Web Services
GWT RPC
PALMS Server VM
PC Browser PALMS Server Machine
JAVA (GWT) JAVA (Mule ESB)
38
