Bestandsaufnahme im Bereich Grid-Middleware

Bestandsaufnahme im Bereich Grid-Middleware
Arbeitskreis 2 der D-Grid Initiative
Name der Komponente (des Systems, des Projektes):
Gridsphere Portal Framework (http://www.gridsphere.org), GridLab
Funktion der Komponente (des Systems; Ziel des Projektes):
Bereitstellung einer einheitlichen, webbasierten, industriestandbasierenden
Benutzeroberfläche für Endnutzer und Administratoren. Das Projekt soll es
Wissenschaftlern und Forschern ermöglichen einen einfachen Zugriff auf GridServices
und Ressourcen zu erhalten. Dies soll einfach bedienbar, unabhängig vom
Betriebssystem und Aufenhaltsorts und minimale Anforderungen an den Rechner des
Anwenders sein.
Produzent der Komponente (des Systems; Projektbeteiligte):
EU Projekt GridLab; AEI Golm
Die Komponente (das System) wird zurzeit eingesetzt von:
AEI Golm, San Diego Supercomputing Center (GEOScience Network), Canadian NRC
Grid Infrastructure Project, Australian Virtual Observatory, Louisianna State University
Einbettung der Komponente (des Systems, des Projektes):
Mit welchen anderen Systemen kooperiert die Komponente?
Das Framework ist läuft zusammen mit dem CACTUS Toolkit und GLOBUS.
Mit welchen Systemen gibt es keine reibungslose Kooperation,
Über andere System als CACTUS und GLOBUS kann keine Aussage getroffen werden.
Welche anderen Komponenten sind für den Einsatz notwendig?
Das Portalframework basiert auf Java und ist somit auf allen Systemen verfügbar auf
denen eine entsprechende Java Virtual Machine installiert ist. Weiterhin benötigt es
einen Jakarta Tomcat Servlet Container. Dieser ist Open Source und frei verfügbar.
Worauf basieren diese Aussagen?
Diese Aussagen basieren auf Erfahrungen/Tests und der Projektdokumentation.
Bedeutung der Komponente (des Systems) im D-Grid;
Die Komponente (das System) sollte im D-Grid eingesetzt werden, da ...
Das Gridsphere Framework stellt eine webbasierte, open source Portallösung zur
Verfügung. D-Grid sollte einen webbasierten Zugriff auf Ressourcen und Informationen
bereitstellen weil dies zu einer hohen Akzeptanz bei Forschern und Wissenschaftlern
führt. Es sind keine externe Programme zu installieren die eventuell spezielle
Schreibrechte benötigen und nur von Administratoren bereitgestellt werden können. Die
einzig benötigte Komponente die der Nutzer braucht um Zugriff auf Ressourcen zu
erhalten ist ein normaler Webbrowser der seit einigen Jahren zur Grundausstattung
jedes Computers gehört. Weiterhin kann der Nutzer so unabhänging von seinem
Arbeitscomputer (z.B. Zugangssysteme auf Konferenzen, andere Einrichtungen,
Internet Cafe) auf alle Informationen/Programme schnell und problemlos zugreifen.
Erste Anpassungen des Gridsphere Frameworks an Besonderheiten einer
Gridumgebung sind bereits vorhanden, diese weisen aber in mehreren Punkten noch
deutlichen Verbesserungsbedarf (inbesondere Anpassungen an andere Applikationen,
Aufgabenstellungen) auf. Bereits in dieser Phase zeigte sich aber die Eignung als
schneller und komfortabler Zugriff auf im Grid bereitgestellte Services. Auch
Administratoren profitierten von einem einheitlichen Webinterface, da sie alle von ihrer
Einrichtung bereitgestellten Services nun von einer Oberfläche aus
konfigurieren/verwalten können. Alle diese Punkte sind nicht spezifisch einer
Community zuzuordnen, das gesamte D-Grid und alle Nutzergruppen können von
dieser Technologie profitieren.
Ein Einsatz der Komponente (des Systems) sollte nicht eingesetzt werden, da ...
Bei Komponenten (Systemen) die eingesetzt werden sollen
Welche Schwachstellen hat die Komponente (das System) zurzeit:
Endnutzer:
Das Benutzerinterface der „Cactus und GridPortlets“ ist zur Zeit ohne zusätzliches
Wissen über Gridcomuting nicht intuitiv genug um Wissenschaftlern ohne diesen
Hintergrund einen einfachen Zugang zu Ressourcen zu geben.
Administration:
Die Integration in andere (Servlet)Umgebungen als Jakarta Tomcat ist nicht gegeben.
Mittelfristiger Entwicklungsbedarf besteht in den Bereichen:
- Authentifikation gegenüber verschiedenen Identitysystemen
- Sicherheitsmodell um fein garnulierte Zugriffsrechte zu ermöglichen
- Unterstützung von Workflow Jobs/anderen Jobschedulern
- Entfernte Visualisierung via Webinterface um (Zwischen)ergebnisse
darzustellen
- Support für Remote Portlets (WSRP) um Portlets lokal bereitzustellen die in
anderen Einrichtungen erstellt wurden oder um mit Services installierte Portlets
zu nutzen
- Entwicklung von „Grid-Ready“ visuellen Komponenten um eine schnellere und
einfachere Anbindung von Applikationen zu gewährleisten
- Benutzerinterface (Unterstützung JSF, Struts)
- Anpassung der „Cactus und GridPortlets“ an JSR 168
(http://www.jcp.org/en/jsr/detail?id=168) Standard.
Wer arbeitet gegenwärtig an einer Verbesserung der Schwachstellen:
Meines Wissens arbeitet im Augenblick niemand an den oben genannten
Schwachstellen.
Bei Komponenten (Systemen) die nicht eingesetzt werden sollen
Welche Teildienste sollten funktionell in das D-Grid übernommen werden:
Das gesamte System sollte übernommen werden.
Erarbeitet von:
Oliver Wehrens ([email protected])