1. Distributed Account Management Middleware Glenn Bresnahan (PI), Boston University Steve Quinn (CoPI), NCSA Aaron Fuegi, Boston University Chris Pond, NCSA Michael Shapiro, NCSA Ester Soriano, NCSA

2. Objective Provide mechanisms to allow for the automated management of resource allocations, resource access control, user information, user login accounts, and usage reporting in a grid environment spanning multiple administrative domains

3. Background Alliance partnership (PACI) –NCSA, Boston, Kentucky, New Mexico, Wisconsin, Maui NSF PACI Allocation Peer Review (NRAC and AAB) Manage accounts, allocations and reporting across Alliance resources

4. Requirements Compatible with current practices (e.g. PACI) Independent of local account management system Heterogeneous environment Multiple administration domains Economic model neutral

5. Strategy Provide grid services to exchange and manipulate shared accounting objects –Resource requests –Resources allocations –User information –Project/group information –Access permissions –Usage reports

6. AMIE Data Representation XML schema for Accounting Objects –Machines –Users –Accounts –Allocations –Usage

7. AMIE Architecture Transaction-based exchange mechanism –Transaction comprised of sequence of packets (messages) and acknowledgements Sites send Requests and Notifications –Site A requests site B to perform an action –Site B notifies site A of actions taken Independently or as the result of a request Set of objects and states –Well defined state change sequences Robust error detection and recovery Asynchronous or real-time communication –No transport reliability assumptions “Glue” modules to interface to site-specific accounting system

8. Configuration: Star

9. Configuration: Peer to Peer

10. Current Implementations Alliance Partner Sites (Version 1) Alliance Grid Testbed (Version 1) Teragrid (Version 2 – NMI) NEES Grid (Version 2 – NMI) (implementation in progress)

11. Transaction Example 1 Account Creation

12. Transaction Example 2 Modify User Information

13. Transaction Example 3 Usage Reporting

14. Transaction States Four possible states On-hold 1. On-hold - Waiting for another event. No further action should be taken until state changes. In-progress 2. In-progress – processing is underway Completed 3. Completed – processing completed Error 4. Error – processing failed. More information is available via the packet state

15. Transaction Packet States Incoming Packets Construct Construct – Message being assembled Received Received – Complete and ready to be processed Validate Validate – Waiting for XML validation Inbox Inbox – Waiting to be put into AMIE DB Done Done – All processing sucessfully completed Error Error – Awaiting error notification to be issued Failed Failed – Completed with failure

16. Transaction Packet States Outgoing Packets Construct Construct – Message being assembled Validate Validate – Waiting for XML validation Outbox Outbox – Waiting to be transmitted Sent Sent – Sucessfully sent to remote site Wait Wait – Waiting for a reply Done Done – All processing sucessfully completed Error Error – Awaiting error notification to be issued Failed Failed – Completed with failure

17. AMIE Reference Implementation

18. Current Status Items Complete Core AMIE system XML Schema XML validation Method call interface specification Transport/processing engine State tracking Error handling Testbed Implementation

19. Current Status Reference Implementation Reference implementation of AMIE method call interface Relational "intermediate DB" schema (Oracle, Postgres, Sybase support) to interface AMIE to local AM system

20. Current Status In Development Reference implementation of Account Management system –fully functional AM DB Schema –method call implementation –glue between AM system and AMIE implementation –Should be "drop in" AM system with grid capability through AMIE

21. Current Status Packaging Core implementation Reference implementation of method call interface Reference AM implementation Documentation

22. Distributed Account Management Questions?