IT-Infrastruktur – geduldetes Übel in der Welt der Services

Bernd Rintelmann (Oracle Deutschland GmbH)
IT-Infrastruktur – geduldetes Übel in der Welt der Services?
Jede funktionierende Organisation ist nur so gut, wie ihre Abläufe und Prozesse.
Zum einen sind dafür genau definierte Anforderungen der Fachbereiche notwendig;
zum anderen benötigt es einer IT, die Prozesse nicht nur unterstützt und abbildet,
sondern auch eine reaktionsfähige Infrastruktur bereitstellt, die sich an der
Transformation von Geschäftsprozessen ausrichtet.
Hohe IT Investitionen der Unternehmen in den Zeiten des „Client/Server- “ und
„Internet- Booms“ haben in den vergangenen Jahren zu einer schnell gewachsenen
Systemlandschaft geführt, die auf Grund ihrer „Silo“ Eigenschaften einen großen Teil
des IT-Budgets in Form von Wartung, Pflege und Entwicklung von Schnittstellen
verschlingt und nicht beweglich genug ist, sich auf veränderte Rahmenbedingungen
des jeweiligen Geschäfts einzustellen.
Soll hier Abhilfe geschaffen werden, so müssen in der IT- Infrastruktur Prinzipien wie
„Virtualisierung“, „Integration“ und „Automatisierung“ Einzug halten.
Notwendigkeit von Services beim Zugriff auf die DatenInfrastruktur
Während Virtualisierungstechnologien für eine Entkopplung von Anwendungen und
Datenhaltungssystemen von der darunter liegenden Hardware sorgen, ermöglichen
Technologien wie XML und der daruf aufbauenden Web Services eine standardisierte
Integration auf Software- und Infrastrukturebene.
Prinzipiell ist Virtualisierung lediglich die Abstraktion von den physischen
Gegebenheiten in der Darstellung. Im Server-Bereich (Partitionierung, Cluster,
Blades) oder im CPU Bereich (VMWare) ist sie bereits selbstverständlich. Bei den
Datenbanken sorgen Hersteller wie Oracle mit dem „Real Application Cluster“ (RAC)
und automatischem "Storage Management“ (ASM) dafür, dass sich mehrere
Datenbank- Server als virtuelle Einheit darstellen.
Betrachtet man aber den Service- Begriff nicht nur auf der Ebene der DB- Server,
sondern granularer, stellt sich zwangsläufig die Frage, wie die von den Servern
verwalteten Daten als Service bereitgestellt werden können, bzw. wie man überhaupt
zu Daten- Services kommt, mit denen die verschiedenen Aspekte der InformationsIntegration innerhalb eines Service- orientierten Ansatzes gehandhabt werden können.
Im folgenden die kurze Beschreibung zweier möglicher Technologien zur
Bereitstellung von Daten
EJB 3.0 und JPA 1.0/2.0
Aus Sicht einer technischen Architektur kann die Geschäftslogik, die z.B. in einem
Komponentenmodell wie dem Enterprise Java Beans Standard definiert ist, für das
Aggregieren von Daten aus strukturierten Datenquellen (relationalen Datenbanken)
verantwortlich sein. In der Vergangenheit haben objekt-relationale "Mapping
Frameworks" (Oracle TopLink, Hibernate) als auch Standards wie die EJB 2.x CMP
Spezifikation versucht, dem Entwickler die Herausforderungen der Datenpersistenz zu
vereinfachen – leider nicht immer mit Erfolg. Es gab keinen einheitlichen PersistenzStandard innerhalb der Java Plattform, der sowohl für die Enterprise als auch die
Standard Edition galt. Abhilfe verspricht hier das neue Java Persistenz API (JPA), das
erstmals innerhalb des EJB 3.0 Standards Einzug in die Java- Welt gehalten hat. Mit
dem Erscheinen von JEE6 wurde vie Version 2 des Jaba Persistence APIs
freigegeben.
Vereinfacht ausgedrückt wird ein einheitliches POJO Persistenz Programmier Modell
beschrieben - inkl. eines standardisierten Objekt-relationalen Mapping MetadatenModells und einer „Java Persistence Query Language“, so dass es auch ausserhalb
eines J2EE Containers verwendet werden kann.
Web Services
Datenbank-basierte Web Services stellen eine weitere (technische) Möglichkeit dar,
bestehende Investitionen zu sichern: Sie ermöglichen den Anwendungen einerseits
auf Daten mittels Web Services zuzugreifen, andererseits erlauben sie aber z.B. den
DB- Servern auch, als „Service-Konsument“ aufzutreten, d.h., dass z.B. eine SQLAbfrage oder eine DB-Prozedur einen externen Web Service nutzen kann. Hersteller
wie Microsoft, IBM oder Oracle bieten Zugriff auf ihre Datenbanken mittels der
klassischen Web Service Technologien wie SOAP, WSDL, UDDI und nutzen dafür
ihre eigenen Middleware- Frameworks. Agiert die Datenbank als Service Provider
können eine Vielzahl vorhandener Datenbank APIs für die Implementierung genutzt
werden, z.B.:
- SQL Abfragen und DML Statements
- XML APIs (Anwendungen können damit via Web Services direkt XML
Dokumente aus der DB lesen, lokal ändern und wieder zurückschreiben)
- Gespeicherte Prozeduren und benutzer-definierte Funktionen
- Datenbank- Queuing u. -Messaging APIs
Aber auch hier stellen sich die für Web Services üblichen Probleme, bzw.
Fragestellungen, wie das „Mapping von Datentypen“, Sicherheit,
Transaktionsunterstützung unf Interoperabilität.
Federated Services
Leider (aus Sicht der RDBMS- Hersteller) liegen aber nicht alle Informationen eines
Unternehmens in relationalen Datenbanken, sondern oftmals findet man eine Vielzahl
von Quellen wie Directory- Verzeichnisse, File- Systeme, VSAM- Dateien etc.
Unterschiedliche Dateistrukturen (Binär, XML, CVS) tragen ein übriges zur
Erhöhung der Komplexität bei. Zudem ist Java und das entsprechende Komponenten
Modell zwar mittlerweile ein akzeptierter und weit verbreiteter Standard aber nicht
die einzige Möglichkeit, um Services in einer SOA zu entwickeln.
Anstatt in jedem Business Service einen Zugriff auf die benötigten Daten zu
implementieren – und dabei die unterschiedlichsten APIs für das „Databinding“ zu
verwenden (JDBC, JDO, JAXB, ADO.NET,ODBC,etc.) kann es angebracht sein, eine
zentrale „Daten-Service Schicht“ zu erstellen, die den Datenzugriff für alle
Services/Applikationen zentralisiert und eine einheitliche Sicht auf die heterogenen
Datenquellen liefert.
Das jeweilige Geschäftsobjekt ruft dabei kein dezidiertes Service- Interface explizit
auf, sondern delegiert den Datenzugriff an ein System, das die Verantwortung für die
Datenintegration hat.
Der Zugriff aus dieser Daten-Service Schicht muss sowohl auf Daten möglich sein,
die stark typisiert sind und eine statische Strukturdefinition aufweisen (z.B. EJB oder
JDBC Zugriff auf eine relationale Datenquelle) als auch auf schwach typisierte Daten
deren Struktur erst zur Laufzeit ermittelt werden kann (z.B. Web Services). Der
Entwicklung von Business Services wird also von den verschiedenen Notwendigkeiten des Datenzugriffs abstrahiert.
Aus technischer Sicht kann dieser Schicht eine Architektur zugrunde liegen, wie sie in
der „Service Data Object“ Spezifikation beschrieben wird. Sie definiert einen
einheitlichen Datenzugriffs-Layer für heterogene Datenquellen und existiert in der
ersten Version bereits seit 2003 (JSR 235), erfährt aber erst durch die SOA Diskussion verstärkte Beachtung, und liegt momentan als Spezifikation in der Verantwortung von OASIS (nach den von der „Open Service Oriented Architecture
Collaboration“ (www.osoa.org) initierten Anfängen)
.
Die wichtigsten Konzepte der SDO Architektur sind:
- Data Objects (generische Repräsentation eines Geschäfts-Objektes;
unabhängig von einem bestimmten Speicher- Mechanismus)
- Data Graphs (zusammenhängende Datenobjekte, die einem Service zur
Bearbeitung übergeben werden; die Bearbeitung erfolgt entkoppelt von der
jeweiligen Datenquelle („disconnect programming model“))
- Data Access Service (ist als sog. Mediator für die Verbindung mit den
Datenquellen verantwortlich;
- Metadaten API (bietet Zugriff auf die Metadaten eines Data Objects)
SDO versucht also die Nachteile der herkömmlichen Datenzugriffsmethoden zu
vermeiden und bietet u.a. folgende Vorteile:
- SOA Abstraktions- Schicht
- Reduzierter Datenbank- Overhead, d.h. das „Data Object“ speichert seine
Änderungs- Historie, die vom „Data Access Service“ genutzt wird, falls es
Kollisionen beim Zurückschreiben in die Datenquelle gibt („optimistic
concurrency“ oder „offline locking“)
- SDO lieferte ein einheitliches APIs für heterogene Datenquellen
(verfügbar in C++, Java, PHP)
Diese Vorteile in einer SOA führen zu verstärktem Support durch Hersteller wie
Oracle, die in ihrer Fusion Middleware eine SDO Fassade oberhalb der EJB 3.0 und
JPA Schicht implementiert haben. SDO und EJB 3.0 werden also eher als ergänzende
Technologien gesehen. Während SDO eine Architektur ist, die einen einheitlichen
Zugang zu heterogenen Datenquellen beschreibt, so beschränkt sich EJB3/JPA
weiterhin darauf eine Persistenz- Technologie zu sein, die unterhalb des „Binding
Layers“ von SDO liegt und von dem o.a. „Mediator Service“ genutzt wird.
Ausblick
Als Fazit bleibt die Schlussfolgerung, dass die Bereitstellung von Daten- Services
durch Technologien wie SDO erst in einer Service Orientierten Architektur einen
wirklichen Mehrwert gegenüber bestehenden APIs liefert. Service Data Objects bietet
somit eine ideale Ergänzung zu einem zum SOA Komponentenmodell, dass als
„Service Component Architecture“ (SCA) ebenfalls von OASIS als Spezifikation
„verwaltet“ wird.
Neben der Spezifikation von Standards ist die Akzeptanz durch die Hersteller
unabdingbar. So liefert Oracle für das aktuelle Release ihrer Fusion Middleware eine
service-neutrale und plattform-unabhängige Laufzeitumgebung an („SOA Suite
11g“), die beliebige Services, die mittels des SCA Komponentemodells erstellt
worden sind, miteinander integriert. Unterstützt von einem Databinding- Modell, dass
u.a. duch die „Service Data Objects“ eine flexible service-oreintierte Einbindung von
Daten in eine SOA Architektur ermöglicht.
Da auch Analysten wie Gartner sich der SDO und SCA Spezifikationen angenommen
haben, kann man davon ausgehen, dass dieses Thema die Software- Hersteller – und
damit auch ihre Kunden – weiterhin beschäftigen wird.