Datenbank Spektrum (2010) 10: 159–161 DOI 10.1007/s13222-010-0027-1

K U R Z E R K L Ä RT

OGSA-DAI Martin Husemann · Norbert Ritter

Online publiziert: 21. Oktober 2010 © Springer-Verlag 2010

Zusammenfassung OGSA-DAI ist eine Middleware, die service-orientierte Schnittstellen für die technisch einheitliche Ansprache verschiedener Arten von Datenquellen definiert. Dabei besteht auch die Möglichkeit zur Bereitstellung erweiterter Funktionalität, um Datenverarbeitung im Nutzerauftrag direkt serverseitig durchführen zu können. OGSA-DQP erlaubt die Definition virtueller Datenquellen als Zusammenfassung von Relationen mehrerer relationaler Datenquellen. Der Grad der inhaltlichen und strukturellen Abstraktion von den zugrunde liegenden Datenquellen bleibt allerdings insgesamt begrenzt.

1 Motivation und Einordnung Die effektive Nutzung der stetig wachsenden Datenmengen, die in sehr unterschiedlichen Arten von Datenquellen verteilt gespeichert sind, ist ein klassisches Ziel auf dem Gebiet des Daten-Managements. Bevor hierbei komplexere Aspekte wie die Überwindung semantischer Heterogenität behandelt werden können, sind zunächst handfeste technische Hürden zu bewältigen, um verschiedenartige Datenquellen überhaupt ansprechen und auf ihre Inhalte zugreifen zu können. Im Service-Oriented Computing werden funktionale Komponenten mit technisch einheitlichen Schnittstellen in Form von Services versehen, um eine einfache Verwendung zu ermöglichen. Dieser Ansatz hat sich auch auf dem Gebiet des Grid-Computings [5] etabliert und löste dort ältere Ansätze mit geringerer Flexibilität und Interoperabilität ab. Diese Entwicklung nahm 2002 ihren Ursprung durch M. Husemann · N. Ritter () Universität Hamburg, Hamburg, Deutschland e-mail: [email protected]

eine gemeinsame Initiative des Globus Projektes [3] und IBM, aus der die „Open Grid Services Architecture“ (OGSA) hervorging, die wiederum in [2] wie folgt charakterisiert wird:1 „ Aufbauend auf Konzepten und Technologien aus den Bereichen des Grids und der Web-Services definiert OGSA eine einheitliche Semantik für angebotene Dienste (die so genannten Grid Services) sowie Standardmechanismen für die Erzeugung, Benamung und Entdeckung flüchtiger Grid-Service-Instanzen, bietet Ortstransparenz sowie multiple Protokollbindungen für Service-Instanzen und unterstützt die Integration mit zugrunde liegenden nativen Plattformeinrichtungen“. Entsprechend ähneln GridServices grundsätzlich Web-Services; sie verfügen jedoch zusätzlich über einen explizit definierten Lebenszyklus und sind in der Phase ihrer aktiven Verwendung zustandsbehaftet. Grids, in denen service-basierte Schnittstellen zum Einsatz kommen, werden als Service-Grids bezeichnet. Frühe Grid-Anwendungen nutzten meist einfache Dateien für die Datenspeicherung. Mit fortschreitender Entwicklung des Grid-Computings und steigender Komplexität der eingesetzten Anwendungen ergab sich sehr schnell der Bedarf nach mächtigerer Datenverwaltung, so dass verstärkt Datenbanksysteme heran gezogen wurden. Für die sinnvolle, nahtlose Einbindung von Datenbanksystemen in ServiceGrids sind Schnittstellen erforderlich, die von individuellen Besonderheiten abstrahieren und eine einheitliche Ansprache ermöglichen. Hierzu leistet OGSA-DAI („Open Grid Services Architecture – Data Access and Integration“) einen Beitrag [1]. OGSA-DAI ist eine Open-Source-Entwicklung [8], die gegenwärtig in Version 4 vorliegt und vom EPCC der Universität Edinburgh koordiniert wird. OGSA-DAI hat zum Ziel, verschiedenartige, verteilte Datenquellen über einheitliche Schnittstellen in Service-Grids ansprechbar zu 1 Aus

dem Englischen übersetzt.

160

machen [7]. Die aktuelle Benutzerdokumentation [8] sagt hierzu1 : „OGSA-DAI ist ein Produkt, das die gemeinsame Nutzung von Datenquellen zulässt, um Zusammenarbeit zu ermöglichen. Es unterstützt: Datenzugriff – Zugriff auf strukturierte Daten in verteilten, heterogenen Datenquellen; Datentransformation, etwa die Darstellung von Daten in Schema X gegenüber Nutzern als Daten in Schema Y; Datenintegration, etwa die Darstellung multipler Datenbanken gegenüber Nutzern als eine einzelne virtuelle Datenbank; Datenübertragung – die Übertragung von Daten an die Stelle, wo sie benötigt werden, unter Verwendung des bestgeeigneten Mittels, etwa Web-Service, E-Mail, HTTP, FTP, GridFTP“. Typische Arten verwendeter Datenquellen sind dabei relationale und XML-Datenbanken. Die führenden kommerziellen Datenbanksysteme werden durch vordefinierte Wrapper unterstützt. Grundsätzlich lassen sich aufgrund der Erweiterbarkeit von OGSA-DAI beliebige Datenquellen einbinden [4].

2 Architektur und Funktionalität OGSA-DAI ist als eine Middleware angelegt. Die aktuelle Version wurde im April 2010 zur Verfügung gestellt [8]. Wie in Abb. 1 dargestellt, kommuniziert ein Client (synchron oder asynchron) mit einem so genannten Data Request Execution Service (DRES), typischerweise einem WSRFkonformen Web-Service, der seinerseits eine Data Request Execution Resource (DRER) aktiviert. Letztere übernimmt die Ausführung von OGSA-DAI-Workflows und koordiniert somit den Ablauf, der in dem vom Client übergebenen (Perform-)Dokument beschrieben ist. Diese Workflows (siehe Beispiel in Abb. 2) bestehen aus Aktivitäten; die Activity stellt die funktionale Basiseinheit in OGSA-DAI dar. Während die Aufrufschnittstelle eines DRES und die Struktur eines Perform-Dokuments einheitlich und unabhängig von der unterliegenden Ressource definiert sind, gilt dies nicht für die Inhalte der Aktivitäten. OGSA-DAI abstrahiert beispielsweise weder von der Anfragesprache noch von der Datenstruktur einer Datenquelle. Ein Perform-Dokument etwa zum Zugriff auf eine relationale Datenbank muss also SQLStatements enthalten, die auf die konkrete Tabellenstruktur der Datenbank Bezug nehmen. Workflows unterstützen die parallele Ausführung von Aktivitäten, insbesondere auch die Pipelineparallelität auf

Abb. 1 Service-basierter Datenzugriff

Datenbank Spektrum (2010) 10: 159–161

Basis von Datenströmen. Aktivitäten können ressourcenspezifisch (z.B. die Ausführung einer SQL-Anfrage auf einer relationalen Datenbank) oder generisch (z.B. XSLTransform) sein. OGSA-DAI unterscheidet verschiedene Arten von Ressourcen, die hier nicht alle angeführt werden können; alle OGSA-DAI-Ressourcen werden von spezifischen Web-Services gekapselt. Die wichtigste OGSA-DAIRessource ist die DataResource, die eine Datenquelle repräsentiert. Sofern entsprechende Aktivitäten zur Verfügung stehen, kann ein kompletter Vorgang, beispielsweise bestehend aus Datenabfrage, Transformation und Integration, als Auftrag in einem Perform-Dokument formuliert und serverseitig abgewickelt werden, so dass nur die Endergebnisse an den Aufrufer zurückgeliefert werden (siehe Abb. 2). Auf diese Weise können Nutzer/Anwendungen von womöglich aufwändigen Verarbeitungsschritten entlastet werden und die Menge zu übertragender Daten wird reduziert; die Datenverarbeitung findet in der Nähe der Datenspeicherung und -verwaltung statt. Die Funktionalität für die serverseitige Durchführung komplexerer Operationen ist dabei von der Datenquelle bereitzustellen oder durch entsprechende Service-Komponenten (Aktivitäten) zu realisieren; OGSADAI definiert lediglich die Mittel und Wege zur Ansprache solcher Komponenten. Während frühere Versionen von OGSA-DAI sich auf die Vereinheitlichung des Zugriffswegs konzentrierten und somit kaum erweiterte Funktionalität anbieten konnten, wurde der zunächst in einem separaten Projekt entwickelte Dienst OGSA-DQP (Distributed Query Processing) mittlerweile in OGSA-DAI integriert. DQP [6] erlaubt Anfragen, die mehrere relationale Datenquellen überspannen. Hierzu wird eine virtuelle DataResource definiert, der Relationen unterschiedlicher Datenbanken zugeordnet werden können und die den Nutzern/Anwendungen die Illusion einer einzelnen relationalen Datenquelle gibt. Solche DQPFöderationen können lediglich relationale Tabellen vollständig einblenden; eine feingranularere Form der Integration wird nicht unterstützt. Weiterhin ist hier nicht der volle SQL-Sprachumfang anwendbar und es gibt keine übergeordnete Ablaufsteuerung, wie OGSA-DAI auch insgesamt noch keine integrierte verteilte Transaktionsverwaltung bietet.

Abb. 2 Workflow ‚Datenintegration‘

Datenbank Spektrum (2010) 10: 159–161

Abb. 3 OGSA-DAI-Architektur

Abb. 3 zeigt die OGSA-DAI-Architektur. Die meisten Komponenten sind selbsterklärend. Gegenwärtig erlaubt OGSA-DAI den Zugriff via Apache Axis, Globus Toolkit oder direkt über Java. Als Erweiterungspunkte sind in der Abbildung Aktivitäten und (DataResource-)Plug-Ins orange hinterlegt. Auch hinsichtlich der Sicherheitsmaßnahmen (Authentifizierung und Autorisierung) bestehen spezifische Erweiterungs- und Anpassungsmöglichkeiten.

3 Bewertung und Fazit OGSA-DAI wird seit 2002 kontinuierlich – mittlerweile als Open-Source-Initiative – (weiter) entwickelt. Zahlreiche Forschungsprojekte (Übersicht auf [7]) verwenden OGSA-DAI in den verschiedensten Anwendungsbereichen, wie z.B. Medizin, Geographie, Meteorologie, Logistik, Astronomie und Ingenieurwesen. Der wesentliche Nutzen von OGSA-DAI liegt darin, dass über Web-ServiceMechanismen eine Abstraktion von Implementierungsdetails wie Protokollen, DB-Treibern, Netzwerkports, etc. er-

161

reicht werden kann. Die vielfältigen Anforderungen hinsichtlich der Integration heterogener Datenquellen in GridUmgebungen kann OGSA-DAI jedoch nur begrenzt erfüllen, da keine wirkliche Abstraktion von Struktur oder Anfragesprache der Datenquellen geboten wird. Eine inhaltliche oder strukturelle Abstraktion lässt sich zwar über entsprechend (selbst) implementierte Aktivitäten erreichen; OGSADAI bietet hier aber keine spezielle Plattformunterstützung und fällt in diesem Punkt deutlich hinter bereits kommerziell existierende Integrationsprodukte, von denen an dieser Stelle beispielhaft der IBM Information Server genannt werden soll, zurück. Dennoch kann OGSA-DAI einen wertvollen Beitrag liefern, insbesondere wenn es gelingen sollte, eine breite Akzeptanz als Standard zu erlangen. Dies ist zum gegenwärtigen Zeitpunkt allerdings noch nicht abzusehen, so dass die Bedeutung von OGSA-DAI nicht abschließend beurteilt werden kann. Literatur 1. Antonioletti M, Atkinson M, Baxter R, Borley A, Hong NP, Collins B, Hardman N, Hume AC, Knox A, Jackson M, Krause A, Laws S, Magowan J, Paton NW, Pearson D, Sugden T, Watson P, Westhead M (2005) The design and implementation of Grid database services in OGSA-DAI. Concurr Comput Pract Exp 17:357–376 2. Foster I, Kesselman C, Tuecke S (2002) Grid services for distributed systems integration. Computer 35(6):37–46 3. Globus. http://www.globus.org. Stand 10.09.2010 4. Hong NC, Antonioletti M, Karasavvas K, Atkinson M (2007) Accessing data in grids using OGSA-DAI. In: Knowledge and data management in GRIDs. Springer, Berlin, I, pp 3–18 http://www.springerlink.com/content/j71200lu5453u06j/ 5. Magoulès F (2010) Fundamentals of grid computing, theory, algorithms and technologies. Chapman & Hall/CRC, Boca Raton 6. Lynden S, Pahlevi SM, Kojima I (2008) Service-based data integration using OGSA-DQP and OGSA-WebDB. In: 9th IEEE/ACM international conference on grid computing 7. OGSA-DAI. http://www.ogsadai.org.uk. Stand 10.09.2010 8. OGSA-DAI 4.0. http://sourceforge.net/apps/trac/ogsa-dai/. Stand 10.09.2010