1 / 16

Open Grid Computing Environments collab-ogce

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.

cana
Download Presentation

Open Grid Computing Environments collab-ogce

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Open Grid Computing Environmentswww.collab-ogce.org Marlon Pierce (IU) & Gopi Kandaswamy (RENCI)

  2. 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)

  3. 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.

  4. 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

  5. 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)

  6. 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.

  7. 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.

  8. 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.

More Related