1. Portlet Access Grid – The Next Generation Tobias Schiebeck, Anja Le Blanc, Andrew Rowley, Martin Turner Research Computing Services at the University of Manchester OMII Collaboration Workshop 30 th April /1 st May 2009

2. 2 Contents  What is Portlet Access Grid?  AG(Tk) issues  Standards  Features  Implementation  Timeline  Screenshots  Demo

3. 3 What is Portlet Access Grid? (PAG)  Access Grid Client running in a Portal – Supports all features of the AGTk Servers – Uses AGTk technologies

4. 4 What is AG(Tk)?

5. 5 AGTk Server Bridge Server SOAP XML-RPC Bridge Registry XML-RPC

6. 6 AGTk Issues AGSC Surveys 2006 and 2007 Common Problems Difficulty connecting to a venue (e.g. firewall or multicast problems) not being a multicast site …switch to the unicast bridge …” AG Firewall rules and Muilticast / Unicast are a nightmare – These need to be simplified and made more reliable Many partners have problems connecting because they are setting up temporary nodes. Most of the problems are due to inexperience with NAT (port forwarding) & firewall configurations

7. 7 Why do we need PAG? AGSC Surveys 2006 and 2007 Requested Improvements and comments More reliability Greater coverage of Access Grid across institutions that do not currently have it Speed of the venue client Make it more user friendly …integration into portals … The AGSC should work towards providing training and advice for user managed desktop access to the system Increase in use of the personal access grid Generally a lot of time is spent configuring the software …

8. 8 Why do we need PAG?

9. 9 Standards JSR-168 / 286 SOAP HTTPS XML-RPC H.261 L16 RTP UDP AJAX

10. 10 Features

11. 11 Features

12. 12 Features

13. 13 Implementation

14. 14 PAG Startup Process  Web browser request  Login to Portal / Input Client Profile – Start of Java Applet (VenueClientController) Java WebStart of Client application: VenueClient  Connect to Venue – VenueClient starts services through Java WebStart Download and start of VIC/RAT  Start shared application – VenueClient Starts shared application through Java Webstart Download and start application and application data

15. 15 Screenshots

16. 16 Screenshots

17. 17 One Year On  PAG funding ended in March 2008  PAG is installed on: – PAG reference Server: http://pag.rcs.manchester.ac.uk – AGSC pre-production Server: http://pag.agsc.ja.net  PAG is the basis for a new Project “One VRE to Join Them All” funded by JISC – PAG is being debugged and fixes go on to the PAG reference and production servers

18. 18 Issues addressed by PAG  PAG solved: – software installations and configuring AG – Maintenance of AG node – Bridge checking and switching (keeping connected)  PAG provided – Simple – “click and go” – personal node to AG – A “proof-of-concept” TCP-bridge to tunnel AG-traffic through a single TCP port

19. 19 Remaining Issues  AG is still a “high bandwidth job” – A low Bandwidth bridge that filters the incoming (and outgoing) streams for low bandwidth connections could solve that issue  TCP-bridge is not “production ready” – Moving the ideas from TCP-bridge to a “High-Connectivity bridge” a production ready solution  Recording Access Grid sessions – done in several projects - should it be integrated into PAG? – Replay AG recordings from PAG?

20. 20 One VRE to Join Them All  Moving PAG to the next Level:

21. 21 One VRE to Join Them All  PAG running in multiple VRE (portals) working as intermediary between collaboration users  Creating Venues on the fly  Monitoring venues of Virtual Organizations  Exchanging certificates for venues between PAG servers  Using invitation principle for venues  Exchanging Data and sharing applications across multiple portals through the AG virtual Venue

22. 22 One VRE to Join Them All

23. 23 OneVRE – side effects for PAG  PAG has now been tested and “ported” to work in – gridsphere 3.1 – Apache Pluto 1.1.7 PAG works almost “out of the BOX” – Sakai 2.6.x Sakai (or the PAG portlet) needs some minor changes to interoperate Changes have been submitted to the Sakai developers that make PAG work in Sakai (still some cosmetic issues, … )  the PAG servers will be brought up to date with fixes developed in and for OneVRE

24. 24 Low Barrier Access Grid proposal  Low Barrier Access Grid (LowBAG) is a proposal to develop new and innovative bridging technologies  High Connectivity bridge – TCP-bridge based development to tunnel AG traffic through a single TCP-port – Single “defined” Port bridge a Bridge that tunnels all AG traffic through a single defined UDP-port – Starting from PAG these bridges can connect to the Portal server that can filter the traffic between the users client and the AG server

25. 25 Low Barrier Access Grid proposal [2]  Low Bandwidth bridge – TCP-bridge based development to tunnel AG traffic through a single TCP-port – Single “defined” Port bridge a Bridge that tunnels all AG traffic through a single defined UDP-port – Starting from PAG these bridges can connect to the Portal server that can filter the traffic between the users client and the AG server

26. 26 Low Bandwidth Bridge

27. Research Computing Services PAG Reference Server: http://pag.rcs.manchester.ac.uk/ Portlet Access Grid Demo

28. Research Computing Services Contact Details http://www.rcs.manchester.ac.uk/projects/PAG PAG-SUPPORT@listserv.manchester.ac.uk Tobias.Schiebeck@manchester.ac.uk Portal Access Grid