Announcement of the Portlet Access Grid
Anja Le Blanc, Andrew Rowley, Tobias Schiebeck, Martin Turner
Research Computing Services, University of Manchester, UK Email address of corresponding author: Tobias.Schiebeck@manchester.ac.uk Abstract. This paper announces the development and software release of the portalization process of the Access Grid Toolkit. We describe the creation and some of the design decisions involved in building this new portlet, including the technical challenges that were encountered during the integration of Access Grid technologies.
Portal Technologies
A web portal is a site that functions as a point of access to information available on the World Wide Web as well as from other private and public sources. Portals often aim to present information from diverse sources in a unified way thus providing a single interface for enterprises with the options of a consistent look and feel as well as procedures for integrating different applications, which otherwise would have been unconnected entities1. A common key property is that all portlets within a portal individually inherit user authentication and authorization. This means that the user can sign in with a familiar username and password just once. The portal can also store portlet specific information for each user, so users do not have to repeatedly enter specific details.
Need for an Access Grid Portlet
The Open Middleware Infrastructure Institute UK (OMII-UK) has funded the “Portlet Access Grid” (PAG) project that has created a portlet version of the Access Grid Toolkit (AGTk) client. The main idea behind portalization of the AGTk is the general availability of web access on third party machines, even in remote places and behind restrictive firewalls; all of which could become an interface to the AG. The portal approach allows for central provision and management of the software and authentication. All tools necessary on the client side are downloaded automatically through Java Web Start thus removing the need for a complicated installation process. Portlet technologies are defined by generally accepted standards including the established JSR168 and the emerging JSR286, which enabled us to create a cross-platform implementation of the AG technologies. This has been tested across three of the main portal frameworks, Gridsphere, uPortal and Sakai2.
1 2
See also: Web portal - From Wikipedia; http://en.wikipedia.org/wiki/Web_portal Web links at; http://www.gridsphere.org/, http://www.uportal.org/ and http://sakaiproject.org/
The PAG project has also aimed to solve the restrictions imposed by network firewalls and bandwidth limitations through the implementation of a TCP/IP bridge and automatic multicast/unicast detection and switching.
Features
PAG is a complete replacement of the Venue Client provided by the AG Toolkit (AGTk). It is presented through the portal framework allowing for easy access through any available web browser. Installation procedures are minimal for the user as only a working instance of Java is required at the Client end. This model has the advantage that a service provider must centrally care about the portal as well as the PAG portlet installation whereas an end user just needs to worry about the AG meeting itself. PAG provides: 1. An AG client user interface accessible entirely through a portal interface. 2. Access to new bridging technology with minimal requirements for ports to be opened through firewalls. 3. An improved user experience, achieved through the introduction of “client-level bridging”. This also allows for future AG network upgrades. 4. An implementation of the current node services provided by the AGTk, including, but not limited to, audio and video services. These services will use the existing node service executables, and employ Java to deliver the executable packages to the client computer. 5. An implementation of shared applications currently available within the AGTk, including the Shared Presentation tool and the Shared Browser. 6. Access to the AGTk shared data architecture.
Technical Challenges
Many portlets are based on content that is web-friendly; that is, content that is not dynamically updated without some user interaction, and is likely to stay the same when refreshing the overall portal page. The AG presents a new challenge as there is now a need to respond to events that occur remotely, such as a user joining or leaving the virtual venue, without requiring that the whole page is refreshed. Additionally, external tools are required to communicate with the portlet, such as the audio and video tools. This communication must be continuous, even when the page is being refreshed in response to input to another portlet on the same page. In addition to the portlet related challenges, there were also a series of technical challenges that needed to be addressed from the AG itself. Users expect a web-based tool to be usable from a browser without any need for extra specific network configuration. The AG as it stands can often require complex network configurations, especially in relation to firewalls and the use of multicast.
Technologies used
Portal Access Grid Communication Architecture Addressing the challenges of the AG networking and service architecture PAG had to break out of the ordinary portlet structure. The portlet just creates the web interface of the PAGClient. A signed Java applet, the VenueClientController, is then used to communicate between the Portal Server and the PAG Client using asynchronous XML-RPC calls via AJAX. As all the communication is embedded in HTTP, PAG avoids problems with firewalls and proxy servers. The Java applet additionally starts a Java Application, the VenueClient, on the Client machine through Java Web Start. The VenueClient is there to control the AG services. These services are packaged as Java Web Start applications hosted on the PAG servlet. XML-RPC is used between the VenueClient and the VenueClientController as a straightforward communication method. The communication between the VenueClient and the AGServices is based on the SOAP interfaces provided by the AGTk. The UDP traffic from the services themselves is tunneled through a client bridge. This is a UDP bridge that passes the traffic between the service and the AG, either using multicast directly, or through a bridge. PAG includes an interface for allowing additional bridge types to be defined over the standard set provided.
Availability
PAG is currently accessible through a test server based at the University of Manchester. This instance is maintained by the developers of PAG and accounts can be provided through the PAG-support mailing list4. The PAG team, OMII-UK and NGS (National Grid Service) are
4 PAG-support mailing list; PAG-SUPPORT@listserv.manchester.ac.uk
currently discussing methods to make PAG available to the entire e-Science Community via the NGS portal. For third-party service providers downloads are available as source and binary packages from OMII-UK. For redevelopment and use purposes PAG is licensed under a BSD style Open Source License.5
References
Welcome to AccessGrid.org; http://www.accessgrid.org Web portal - From Wikipedia; http://en.wikipedia.org/wiki/Web_portal Contributed Software; http://www-new.mcs.anl.gov/fl/research/accessgrid/wiki/moin.cgi/ContributedSoftware Open Source Initiative OSI - The BSD License; http://www.opensource.org/licenses/bsd-license.php
5
Open Source Initiative OSI - The BSD License; http://www.opensource.org/licenses/bsd-license.php