Change Propagation in a heterogeneous Application Landscape

1. Change Propagation in a heterogeneous Application Landscape Message based propagation of changes in VO membership in a Grid environment Cracow Grid Workshop 2009 Oliver StraussFraunhofer IAO, Stuttgart, Germany Cracow, October 13th 2009

2. Outline • Background and motivation • Overview and architecture • Example • Conclusion

3. Goal: Usage of Grid in a commercial environment Scenario: Portal based collaboration between a provider of crash simulations and its customers RCE RCE Engineer Engineer Background: PartnerGrid GNS-Customer GNS Systems(Provider of numerical services) Portal Consultant RCE ... G I A Animator INDEED Generator Grid

4. Whitelist (potential)VO-Members Problem: Keep the Grid in sync with the VO VO-Representative • 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 approves register PartnerGrid VOMRS D-Gridmap • What if we want to have a whitelist of grid users or other sources of change that affect the Grid configuration? affects Web portal accounts, roles, rights Grid resources Data managementaccounts + rights WebDAVaccess rigths

5. (potential)VO-Members Problem: Keep the Grid in sync with the VO VO-Representative • 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 approves register PartnerGrid VOMRS D-Gridmap • 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 Web portal accounts, roles, rights Grid resources affects Whitelist Data managementaccounts + rights WebDAVaccess rigths

6. Architecture: Message based change propagation gridmap DNUsernameVO Roles Message queueserver gridmap DNUsernameVO Roles Change Manager (Rule engine) Source of changegrid-mapfile Incomingqueue: Changes Dataprocessing andenhancement Change adapter 1 2 3 Target of changeLiferay Portal Outgoingqueue: Liferay Liferay DNUsernameOrganisation Portal Rolesemail Rules ack Tools Change adapter 7 Outgoing queue: WebDAV 5 Message routing Target of change WebDAV 4 ack Apache UsernameGenerated PW Rules Add. queues: LoggingErrorsMail etc… Change adapter 7 Trigger … 0 6

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, …)

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)

9. Example rules # Receive original message and insert a GridmapChange object in the rule engine rule '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 target rule 'addLiferayUser' do parameter GridmapChange, :change_type condition { change.change_type == "add" } consequence { send_add_liferay_user( change, “liferay@kant.iao.fhrg.fraunhofer.de” ) } end

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)

11. Contact • Fraunhofer-Institute forIndustrial Engineering (IAO) • Oliver Strauss • Research Assistant / Software Technology • Mail: oliver.strauss@iao.fraunhofer.de • Web: www.swm.iao.fraunhofer.de