1. Lightweight OGCE Gadget Portal for Science Gateways Zhenhua Guo, Marlon Pierce Community Grids Laboratory, Pervasive Technology Institute, Indiana University, Bloomington Introduction Science gateways are frontends by which researchers interact with backend computation and storage infrastructures. They increase the ability of domain scientists, students and the general public to interact with cyberinfrastructure. This poster summarizes our effort to revisit prevalent models and technologies used by science gateways and integrate state-of-the-art service model and web technologies. The outcome is OGCE gadget portal. Materials and methods Most traditional science gateways (e.g. TeraGrid portal, LEAD gateway) have following characteristics.  Based on Java Portlet standard Server-side integration of different applications.  Heavyweight and framework specific.  Lack of modern features (e.g. social networking) We surveyed and investigated new models and open standards. Our choices of technologies and designs are listed in Table 1 which bring us following benefits.  Agile development of full-fledged science gateway framework with more features than traditional gateways.  Immediately thousands of gadgets are available.  Gadgets can be easily reused across containers, such as iGoogle, Orkut and Hi5.  Inter-gadget and gadget-container communications enable gadgets to work collaboratively instead of separately. Challenges  Most users of science gateways are not computer science experts.  The architecture must be flexible enough to support requirements of different domains.  In addition to pure computation and storage, resource sharing and social networking become more and more critical in science gateways. Acknowledgments The National Science Foundation supports this work through awards 0721656, "SDCI NMI Improvement: Open Grid Computing Environments Software for Science Gateways" and 0504075, "SCI: TeraGrid Resource Partners: Indiana University.” Conclusions We revisited traditional ways to build science gateways and found that standards need to be re-evaluated, collaboration and social networking capabilities are not provided and sustainability is a key issue. Our methodology is to utilize lightweight open standards and make use of existing third-party services instead of building our own. This enables agile development and improves sustainability, extensibility and interoperability. Considering development time of PolarGrid portal and the accomplishments, we believe our investigation and trial is successful. Literature cited Wilkins-Diehr, N., Gannon, D., Klimeck, G., Oster, S., and Pamidighantam, S. 2008 TeraGrid Science Gateways and Their Impact on Science IEEE Computer 41(11): 32-41 TeraGrid Science Gateways [Online] http://www.TeraGrid.org/gateways/gateway_list.php TeraGrid user portal [Online] https://portal.TeraGrid.org/gridsphere/gridsphere Lead Portal [Online] https://portal.leadproject.org/gridsphere/gridsphere OpenSocial Specification [Online] http://www.opensocial.org/Technical-Resources PolarGrid Project [Online] http://www.PolarGrid.org/PolarGrid/index.php/Mai n_Page For further information Please contact zhguo@indiana.edu. OGCE gadget portal home page is http://www.collab-ogce.org/ogce/index.php/OGCE_Gadget_Container. Download link is http://www.collab-ogce.org/ogce/index.php/Portal_download. Related Polar Grid paper is Zhenhua Guo, Raminderjeet Singh, Marlon E. Pierce Building the PolarGrid portal using web 2.0 and OpenSocial. SC-GCE 2009 Architecture Following graph shows system architecture including authentication module, gadget rendering module, backend services and authorization mechanism. Communication flow 1)A user signs in his/her portal. 2)The portal is served by portal server. 3)Each gadget deployed in the portal is rendered by Shindig service. 1)Shindig service fetches the gadget source file 2)Shindig service parses the file and render it into HTML, Javascript, etc. 4)Rendered gadgets are displayed in browser. 5)Rendered gadgets make Ajax calls to load data from backend services and third-party services and update UI. Figure 1 Architecture Tech/Design choices Reason Web 2.0 Improves usability and responsiveness Gadget Enables development of reusable web components that can be deployed to any Gadget standard- compliant container. OpenSocial Enables gadgets to use common APIs to interact with multiple social networking websites. REST Makes applications able to access backend services using simple HTTP requests. OpenID Enables portal to interact with OpenID providers (e.g. Blogspot, Yahoo! OpenID). OAuth Enables portal to interact with OAuth-protected services (e.g. UC BLAST, Clusterw services) FriendConnect Add social networking features to portal without writing the system. Table 1 Technology and design decisions we made and corresponding reasons Feature highlights  Ease of installation and deployment One-command build: mvn clean install  Two gadget layouts – tab and tree  Support of Home and Canvas view  Drag-and-Drop for gadget re-organization  Addition and removal of gadgets and gadget groups  Theme customization  Layout data export and import  REST APIs to interact with portal data. Figure 3 and 4 are screenshots of built-in layouts. Use cases Following diagram depicts how PolarGrid image processing gadget and TeraGrid biology gadgets interact with backend services. PolarGrid service leverages existing public services for agile development and better sustainability. TeraGrid biology gadgets use OAuth as authorization mechanism to interact with backend data processing services. Figure 2 Example use cases. Demonstrate gadgets that access PolarGrid service hosted by IU and biology services hosted by UC. Figure 3 Tab Layout. The displayed tab contains three gadgets – CTSS Resource Map gadget, MyProxy certificate management gadget and Weather satellite data gadget. Users switch between gadget groups by clicking tabs in tab bar. Figure 4 Tree Layout. Users switch between gadgets and gadget groups via tree navigation. The displayed Xregistry gadget is in canvas view.