160 likes | 252 Views
Open Grid Computing Environments www.collab-ogce.org. Marlon Pierce (IU) & Gopi Kandaswamy (RENCI). OGCE Software. A bundled set of JSR 168 compatible portlets and services for building Grid portals (“Science Gateways”). Build with GridSphere. Can will work with uPortal.
E N D
Open Grid Computing Environmentswww.collab-ogce.org Marlon Pierce (IU) & Gopi Kandaswamy (RENCI)
OGCE Software • A bundled set of JSR 168 compatible portlets and services for building Grid portals (“Science Gateways”). • Build with GridSphere. • Can will work with uPortal. • Sakai has new JSR 168 Container • Others possible • Porltets include • GT2 and GT4 GRAM Job submission • GridFTP file transfer • GPIR clients (can work with Teragrid, for example) • PURSe grid registration system. • Condor • MyProxy credential management • Miscellaneous (Iframes)
Supporting Grid Portlet Development • Portlets are built using the Java COG 4’s abstraction layer (developed as part of the project). • Hides the difference between Globus versions • We have developed a set of JSF Tag Libraries to simplify Grid portlet development. • http://fuji.ucs.indiana.edu/svn/repos/GridTags/trunk/GridTagsBeans • We support JSR 168 Velocity for historical interest.
Some OGCE Portal Collaborations • RENCI TeraGrid BioPortal • LEAD Portal • TeraGrid User Portal • TeraGrid Visualization Portal • CIMA Crystallography Portal • VLAB Portal Project • Numerous other projects that come and go: • PittGrid Portal, UNC-Charlotte Visualization Portal, DES and LSST Astronomy Portals, IU System Portals
Future Directions (1/3) • General Trend: we want to align with TeraGrid Science Gateways efforts. • User logging and reporting • Par of TG User Portal now • Generate reports such as • Top 10 users of the portal, • Most frequently used applications and the average response times of each • Applications used by individual users. • Auditing and accounting • Modified GRAM client and server running on TG • Provide the user with a list of submitted workflows and jobs along with allocation used totals per workflow and job. • Associated portlets • Enhanced GPIR capabilities (including MDS data) • Predictor portlets (with NWS) (see TG User Portal)
Future Directions (2/3) • Better support for computational experiments. • Generic Service Toolkit (Gopi will describe). • Other tools (adapted from the LEAD project) • Experimental builder portlets • Metadata management services for tracking and storing all aspects of a workflow.
Future Directions (3/3) • We need better packaging. • Currently use Maven 1 with some strategic Ant and shell scripts. • Some improvements: • More customizable: just download and build what you want • Ensuring all dependencies are met • Smaller download footprint • Maven 2 can do some of these things but it has reliability issues • You have to download dozens and dozens of jar files to build your initial repository. • Typically doesn’t work 100% the first time.
Future Directions (4/3) • We need to consider “Web 2.0” approaches for Science Gateways. • See general material from Monday’s workshop. • http://www.semanticgrid.org/OGF/ogf19/. • These are in general compatible with SOA (assuming build your services correctly). • But the implication on portals/gateways should be dramatic. • We have to decide how much we can shoe-horn into the JSR 168/286 specs.