Reimagining Science Gateways: PolarGrid’s Web 2.0 and OpenSocial Evolution

TL;DR

The PolarGrid portal marks a strategic shift in scientific infrastructure, moving away from heavy, isolated "Portlet" architectures toward a lightweight, social-integrated model. By leveraging Google Gadgets, OpenSocial, and RESTful services, the researchers at Indiana University built a prototype that treats collaboration as a first-class citizen, integrating tools like Twitter and Picasa directly into the scientific workflow.

Background: The Sustainability Crisis in Science Portals

For years, science gateways—portals that provide access to high-performance computing (HPC) resources—have been built as "walled gardens." They utilized JSR 168 portlets and complex SOAP services. While functional, these portals struggled with two main issues:

1. Sustainability: When the project funding stopped, the custom-built forums and calendars died with the servers.
2. User Friction: Scientists didn't want to create yet another account for yet another niche social network.

The PolarGrid project's insight was simple: Don't build it if Google or Twitter already did.

The Architecture of Integration

The PolarGrid architecture is built on a four-tier model that prioritizes flexibility and reusability over monolithic design.

Figure 1: The mapping of technology choices to PolarGrid's requirements.

Key Components:

• Gadgets (Web Widgets): Unlike old portlets, gadgets are framework-agnostic XML/HTML/JavaScript components. They can be rendered in the PolarGrid portal or even in a user's personal iGoogle page.
• Apache Shindig: This serves as the "brain," a reference implementation of the OpenSocial spec that translates gadget XML into usable HTML and handles social data requests.
• RESTful Services: The backend wraps Matlab binaries (Wiener, Median filters) into simple HTTP endpoints. Results are returned as JSON, which the gadgets consume to plot radar data on Google Maps.

Methodological Deep Dive: Bridging Social and Grid Security

One of the most complex challenges addressed was securing the "Social Grid." How do you allow a web gadget to run a job on a secure TeraGrid cluster?

The authors proposed a bridge between OpenID/OAuth and Grid Security Infrastructure (GSI):

1. Authentication: Users log in via OpenID (using Google or Yahoo accounts), which the portal binds to local accounts.
2. Authorization: The team explored Two-legged OAuth to allow the portal to act on behalf of the user. This removes the need for users to constantly re-authorize every individual sub-task in a complex workflow.

Figure 2: The proposed flow for combining MyProxy certificates with OAuth for automated scientific workflows.

A Comparison of Capabilities

The researchers developed a custom Gadget Layout Manager to ensure they weren't entirely dependent on third-party containers like iGoogle, while maintaining feature parity.

Critical Insight: The Value of Externalizing Data

The true innovation of PolarGrid isn't just the UI—it is the offloading of intellectual content. By using a "Blog Gadget" or "Twitter Gadget" for status notifications (e.g., "Filter Execution Complete"), the metadata of the scientific process is archived on platforms with higher longevity than the typical 3-5 year academic grant cycle.

Challenges and Future Work

Despite its success, the "OpenSocial" approach faces hurdles. The paper notes that Inter-gadget communication remains complex; for instance, getting a "filter parameter" gadget to talk to a "map display" gadget requires sophisticated pub/sub patterns. Furthermore, the reliance on third-party security requires a high degree of trust in providers like Google to maintain privacy.

Conclusion

PolarGrid proves that by embracing Web 2.0 standards, scientific gateways can become more agile and collaborative. By moving the "social" aspect of science to the platforms where people already live, researchers can focus more on the radar data of the Greenland ice sheets and less on maintaining database servers for discussion boards.