© Fraunhofer IAO, IAT Universität Stuttgart
Message based propagation of changes in VO membership in a Grid environment
Change Propagation in a heterogeneous Application Landscape
Cracow Grid Workshop 2009Oliver StraussFraunhofer IAO, Stuttgart, Germany
Cracow, October 13th 2009
© Fraunhofer IAO, IAT Universität Stuttgart
Slide 2
Outline
Background and motivation
Overview and architecture
Example
Conclusion
© Fraunhofer IAO, IAT Universität Stuttgart
Slide 3
GNS Systems
(Provider of numerical services)
Background: PartnerGrid
Goal: Usage of Grid in a commercial environment
Scenario: Portal based collaboration between a provider of crash simulations and its customers
RCE
GNS-Customer
Grid
G I A
RCEEngineer
RCEEngineer
...
Consultant
Animator
Generator
INDEED
Portal
© Fraunhofer IAO, IAT Universität Stuttgart
Slide 4
Problem: Keep the Grid in sync with the VO
Scenario: A new user enters the VO Accounts have to be created Roles in different systems
have to be assigned Access rights have to be set
Shell scripts work well for most tasks
PartnerGridVOMRS
VO-Representative
(potential)VO-Members
approves register
Data manageme
ntaccounts +
rights
WebDAVaccess rigths
Grid resources
affects
D-Gridmap
Web portal accounts,
roles, rights
Whitelist
What if we want to have a whitelist of grid users or other sources of change that affect the Grid configuration?
© Fraunhofer IAO, IAT Universität Stuttgart
Slide 5
Problem: Keep the Grid in sync with the VO
Scenario: A new user enters the VO Accounts have to be created Roles in different systems
have to be assigned Access rights have to be set
Shell scripts work well for most tasks
PartnerGridVOMRS
VO-Representative
(potential)VO-Members
approves register
Data manageme
ntaccounts +
rights
WebDAVaccess rigths
Grid resources affects
D-Gridmap
Web portal accounts,
roles, rights
Whitelist
What if we want to have a whitelist of grid users or other sources of change that affect the Grid configuration?
Idea: Why not take an event based approach and use messaging to propagate changes?
Changemanager
© Fraunhofer IAO, IAT Universität Stuttgart
Slide 6
Architecture: Message based change propagation
Source of changegrid-mapfile
Change adapter
Target of change Liferay Portal
Change adapter
Target of changeWebDAV
Change adapter
Message queueserver
Change Manager(Rule engine)
Incoming queue:
Changes
Dataprocessing
andenhancement
Messagerouting
Outgoing queue:Liferay
Outgoingqueue:
WebDAV
1 2
3
45
7
Rules
Rules
7Trigger
0 6
gridmapDN
UsernameVO Roles
gridmapDN
UsernameVO Roles
ApacheUsername
Generated PW
LiferayDN
UsernameOrganisationPortal Roles
Add. queues:LoggingErrorsMailetc…
Tools
…
ack
ack
© Fraunhofer IAO, IAT Universität Stuttgart
Slide 7
Adapters
Adapters have to be provided for each system
Inside the target system (e.g. as a Liferay Portlet)
Acting from the outside (e.g. via an API, WebServices, shell scripts)
Adapter have very limited responsibilities
Source adapters
Detect and submit changes to a message queue
Target adapters
Receive from a message queue and execute changes
Acknowledge success or report error
Optionally submit logging information
Adapters can be implemented in any language for which a Stomp client is available (e.g. Java, Ruby, Python, …)
© Fraunhofer IAO, IAT Universität Stuttgart
Slide 8
Change Manager
The Change Manager
receives requests on the “Incoming“ queue
feeds the change messages to the rule engine
Data normalization and enhancement
Lookup in external directories (e.g. LDAP)
Blacklists and whitelists
Send processed change request to output queue of the target system
Prototype implemented based on
Stompserver (Ruby) message queue
Rule engine (Rools)
© Fraunhofer IAO, IAT Universität Stuttgart
Slide 9
Example rules
# Receive original message and insert a GridmapChange object in the rule enginerule 'receiveGridmapChange' do parameter Message, :source, :body, :change_type condition { msg.source == "gridmap" } consequence { assert GridmapChange.new( msg.body, msg.source, msg.change_type ) }end
# On GridmapChange objects with organisation “IAO” change organization to# “Fraunhofer IAO”rule 'normalizeO' do parameter GridmapChange, :o condition { change.o == "IAO" } consequence { change.o = "Fraunhofer IAO" }end
# Send every GridmapChange object with change_type “add” to the targetrule 'addLiferayUser' do parameter GridmapChange, :change_type condition { change.change_type == "add" } consequence { send_add_liferay_user( change, “[email protected]” ) }end
© Fraunhofer IAO, IAT Universität Stuttgart
Slide 10
Discussion and future work
Advantages
Decoupling of change detection, data manipulation and change execution facilitates reuse
Modular system with explicit rule based logic provides good flexibility
Centralized logging (audit trail)
Easier maintenance and better extensibility expected
Easy integration with other tools like e.g. LDAP
Possible disadvantages
Introduction of a single point of failure
More complexity, one more server, more things that can go wrong
Security is crucial, since much harm can be done by injecting malicious messages
Future work
Further test practicability in the PartnerGrid scenario
Improve security (transfer via HTTPS, encryption and signing of messages)
© Fraunhofer IAO, IAT Universität Stuttgart
Slide 11
Contact
Fraunhofer-Institute for
Industrial Engineering (IAO)
Oliver Strauss
Research Assistant / Software Technology
Mail: [email protected]
Web: www.swm.iao.fraunhofer.de