4. • Common Research Interests
– Geospatial activity data based on wearable devices
– Activity classification based on trips
– Engineering better health
• Common Problems
– Safe and secure data storage
– Trip and activity classification algorithms
– Transfer of analysis to visualization
– Funding
• The PALMS Strategy
– Build it and they will come?
Community Drivers
4
5. Roadmap
• Approach to PALMS Community development
• PALMS technical requirements
• Rationale for Policy Driven Design
• Mechanics of Policy Driven Design
• Example of policy injection and policies
• Feature injection
5
6. Emerging PALMS Community
• Engagement
– 20+ groups internationally (mostly non-NSF/NIH)
– Advisory Board and online surveys (SurveyMonkey)
– Early adopters
– Existing networks (GPSHRN, ALR, IPEN) – newsletters and co-grants
– 1st Annual International PALMS User Conference
• Lowering Barriers to Entry
– Introduction and instruction video
– User documentation
– IRB and grant language
– Scientific validity – validated algorithms
– Revenue model
– Preloading data & PALMSCom
• Incremental scaling
– Distributed models (calculation execution, data storage, server, authorship)
– File Sharing (concentric rings) & social networks
6
7. 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
7
8. 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
8
9. Policy Driven Development
• Goals
– Enable rapid customization
– Empower stakeholders to directly define behavior
• Service Oriented Architecture (Rich Services)
– Services loosely coupled
– Service interactions can be intercepted
– Services can be hierarchically decomposed
Producer Database
OK
StoreData(xxx)
Time
9
Access Control
Producer Database
Message Bus
StoreData(xxx)
OK
10. Policy Driven Development
• Goals
– Enable rapid customization
– Empower stakeholders to directly define behavior
• Service Oriented Architecture (Rich Services)
– Services loosely coupled
– Service interactions can be intercepted
– Services can be hierarchically decomposed
Event
Logger
Policy
Service/
Data
Connector
Community
Calculation
Repository
PALMS Service
Service/
Data
Connector
Device
Repository
Calculation
Repository
Study Repository
Observation
Repository
Subject
Repository
Failure Detection/
Mitigation
Result
Repository
Community
Device
Repository
Event
Logger
Policy
Failure Detection/
Mitigation
Browser User Interface
10
13. Policy Driven Development
• Goals
– Enable rapid customization
– Empower stakeholders to directly define behavior
• Service Oriented Architecture (Rich Services)
• Workflows as service compositions
User
Interface
Device
Repository
GetList(userID)
DeviceID[]
Show Devices
Screen
Get
Device List
Show
Device List
UI UIPALMS
13
14. A Workflow and Policy Case Study
Filter by Role
User
Interface
Device
Repository
Policy: Reject
Role(userID)PI
GetList(userID)
DeviceID[]
Err: Reject
… or ...
{
Allow only PIs
Show Devices
Screen
Get
Device List
Show
Device List
UI UIPALMS
User
Interface
Device
Repository
Policy: Filter
Device Records
by Role(userID)
GetList(userID)
DeviceID[]
14
15. Policy Driven Development
• Goals
– Enable rapid customization
– Empower stakeholders to directly define behavior
• Service Oriented Architecture (Rich Services)
• Workflows as service compositions
• Policy injection
– Policy evaluation
– Domain Specific Language (DSLs)
User
Interface
Device
Repository
Policy
Engine
GetList(userID)
GetList(userID)
DeviceID[]
DeviceID[]'
Policy: Reject
Role(userID)PI
Err: RejectEvent
Logger
Policy
Service/
Data
Connector
Community
Calculation
Repository
PALMS Service
Failure Detection/
Mitigation
Community
Device
Repository
Browser User Interface
15
16. Policy Driven Development
• Goals
– Enable rapid customization
– Empower stakeholders to directly define behavior
• Service Oriented Architecture (Rich Services)
• Workflows as service compositions
• Policy injection
– Policy evaluation
– Domain Specific Language (DSLs)
if ($UserID = '/O=caBIG/CN=bdemchak')
then () (: execute normal flow :)
else return 'Err:Reject'
if (palms:subject-in-study-role('PI')
then () (: execute normal flow :)
else return 'Err:Reject'
DeviceListPolicy.templateReference = DeviceListTemplate
DeviceListPolicy.templateParameter.RoleList = PI
16
17. Policy Driven Development
• Goals
– Enable rapid customization
– Empower stakeholders to directly define behavior
• Service Oriented Architecture (Rich Services)
• Workflows as service compositions
• Policy injection
• Feature injection
– Policy System
– Auditing
– Provenance
Event
Logger
Policy
Service/
Data
Connector
Community
Calculation
Repository
PALMS Service
Failure Detection/
Mitigation
Community
Device
Repository
Browser User Interface
Policy
Engine
Policy
Repository
Policy UI
Event
Acquisition
Event
Repository
Audit UI
17
22. 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
22
23. 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
23
24. 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
24
25. Yesterday Today
Device A Device B Device C Subjects
Calculation 1
Result 1
• Calculations are complex
(includes tagging, hides
intermediate results)
• Results can’t be used in
calculations
Device A Device B Device C Subjects
Calculation 2
Result 3
Tagging
B
Tagging
C
Tagging
Subj
Tagging
A
Tagged
A
Tagged
B
Tagged
C
Tagged
Subj
Calculation 3
Result 2
• Finer grained calculations easier
to write and reuse
• Intermediate results can be
reused
• Results can be fed to calculations
Flexible Networks
25
26. Provenance
Device B Device C Subjects Calculation 1
Result 1
Today Tomorrow
Solution: Provenance
Tracking which calculations and
data contributed to a result
What went into Result1?
Device A Device B Device C Subjects
Calculation 2
Result 3
Tagging
B
Tagging
C
Tagging
Subj
Tagging
A
Tagged
A
Tagged
B
Tagged
C
Tagged
Subj
Calculation 3 Result 2
What went into Result3?
26
27. 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
27
30. 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)
30