Datenzugriff mit der API Service DataObjects, Version 1.0 und Version 2.01

Das SDO-Framework (Service Data Objects) ist ein datengestütztes, in XML integriertes Zugriffsverfahren, das ohne aktive Verbindung arbeitet und eine quellenunabhängige Ergebnisliste liefert.

  • SDO ist datenorientiert, weil Clientanwendungen nicht mit speziellen Datenformaten, wie z. B. den Objektdarstellungen der EJB-API (Enterprise JavaBeans), arbeiten müssen. Stattdessen arbeiten die Clients mit einfach traversierbaren DataObject-Graphen.
  • SDO arbeitet ohne aktive Verbindung, weil das abgerufene Ergebnis von allen Verbindungen und Transaktionen mit dem Back-End-Datenspeicher unabhängig ist.
  • Das SDO-Framework ist insofern XML-integriert, als dass es Services für die einfache Konvertierung der abgerufenen Daten aus dem und in das XML-Format bereitstellt.
Einfach ausgedrückt ist SDO ein Framework für die Entwicklung von Datenanwendungen, das eine Architektur und eine API umfasst. SDO zeichnet sich durch Folgendes aus:
  • Es vereinfacht das Modell der Java-EE-Datenprogrammierung (Java™ Platform, Enterprise Edition).
  • Es abstrahiert Daten in eine serviceorientierte Architektur (SOA, Service Oriented Architecture).
  • Es vereinheitlicht die Entwicklung von Datenanwendungen
  • Es unterstützt und integriert XML.
  • Es integriert Java-EE-Muster und Best Practices.

Das SDO-Framework (Service Data Objects) ist ein einheitliches Gerüst für die Entwicklung von Datenanwendungen. Wenn Sie SDO verwenden, müssen Sie mit den technologiespezifischen APIs nicht vertraut sein, um auf Daten zugreifen und diese nutzen zu können. Sie müssen nur eine API, die SDO API, kennen, mit der Sie Daten aus mehreren Datenquellen, einschließlich relationalen Datenbanken, Entity-EJB-Komponenten, XML-Seiten, Web-Services, Java Connector Architecture, JavaServer Pages usw. bearbeiten können.

Anders als einige andere Datenintegrationsmodelle hört SDO nicht bei der Datenabstraktion auf. Das SDO-Framework integriert auch eine Vielzahl von Java-EE-Mustern und Best Practices und vereinfacht damit die Integration bewährter Architekturen und Designs in Ihre Anwendungen. Die meisten heutigen Webanendungen sind (und können) nicht ständig mit Back-End-Systemen verbunden sein. Deshalb unterstützt SDO ein Programmiermodell für den nicht verbundenen Modus. Außerdem sind viele Anwendungen von großer Komplexität, so dass die Problemstellungen sehr vielschichtig sind. Wie werden Daten gespeichert? Wie werden Daten gesendet? Wie werden sie den Benutzern in einer grafischen Benutzerschnittstelle präsentiert? Das SDO-Programmiermodell definiert Verwendungsmuster, die eine klare Trennung dieser Problemstellungen ermöglicht.

SDO-Komponenten

Die folgende Übersicht über die Architektur von SDO beschreibt jede der Komponenten, aus denen sich das Framework zusammensetzt, und wie diese Komponenten miteinander interagieren. Die ersten drei aufgelisteten Komponenten sind "konzeptionelle" Features von SDO. Für sie gibt es keine entsprechende Schnittstelle in der API.

SDO-Clients

SDO-Clients verwenden das SDO-Framework für die Datenverarbeitung. Anstatt technologiespezifische APIs und Frameworks zu verwenden, nutzen Sie das Programmiermodell und die API von SDO. SDO-Clients bearbeiten SDO-DataObjects und müssen nicht wissen, wie die Daten, die sie bearbeiten, persistent gespeichert oder serialisiert werden.

Data Mediator Services
Data Mediator Services (DMS) sind für das Erstellen eines DataGraph aus Datenquellen und für die Aktualisierung der Datenquellen basierend auf den an einem DataGraph vorgenommenen Änderungen verantwortlich. (Ein DataGraph ist ein Hüllobjekt (Envelope), das Servicedatenobjekte enthält).

Die Data Mediator Services (DMS) stellen den Mechanismus bereit, mit dem Daten zwischen einem Client und einer Datenquelle verschoben werden können. Für die Erstellung werden Back-End-spezifische Metadaten verwendet. Die Metadaten definieren die Struktur des vom DMS erzeugten DataGraph und die für die Back-End-Datenbank auszuführende Abfrage. Wenn ein DataGraph vom DMS angefordert wird, fragt der DMS das Ziel-Back-End ab und übersetzt das native Ergebnis in das DataGraph-Format. Sobald der DataGraph zurückgegeben ist, hat der DMS keine Referenz mehr auf den DataGraph, d. h. in Bezug auf den DataGraph ist der DMS statusunabhängig (stateless). Wenn der DMS aufgefordert wird, die Änderungen an einem vorhandenen DataGraph an das Back-End weiterzugeben, extrahiert er die im Vergleich mit dem vorherigen Status des DataGraph vorgenommenen Änderungen und gibt dieses Änderungen an das Back-End weiter. Ein DMS verwendet in der Regel eine Art Strategie optimistischer Steuerung des gemeinsamen Zugriffs, um Aktualisierungskollisionen festzustellen.

WebSphere Application Server stellt Funktionen für zwei gesonderte Data Mediator Services bereit. Wenn Sie lediglich Daten aus einer relationalen Datenquelle abrufen und einen DataGraph zurückgeben müssen, sollten Sie den Java Database Data Mediator Service verwenden. Wenn Sie allerdings Geschäftslogik verwenden, dann sollen die Daten vermutlich objektorientiert in Form von Entity-Beans bereitgestellt werden. SDO können zwar auch als objektorientierte Bereitstellung von Daten ähnlich den Entity-Beans angesehen werden. Allerdings haben Entity-Beans bessere objektbezogene Zuordnungstools. Außerdem stellen der EJB-Container und Persistence Manager für Entity-Beans besser entwickelte Caching-Richtlinien bereit. Die beste Auswahl ist daher der EJB Data Mediator Service. Der EJB-Mediator kann mit diesen Caches arbeiten. Darüber hinaus ist das Entity-Bean-Programmiermodell ein Speichermodell mit einer einzigen Ebene. Sie können von Entity zu Entity navigieren, und der Container und der Persistenzmanager stellen die Daten mittels Vorabruf oder verzögertem Abruf bereit. Beim Aktualisieren wird die Transaktion vom Programmierer festgeschrieben, und der Container und der Persistenzmanager übernehmen die Aufgabe, die aktualisierten Beans zu ermitteln und diese in den Datenspeicher und den Hauptspeichercache zurückzuschreiben.

Datenquellen
Datenquellen sind nicht auf Back-End-Datenquellen beschränkt (z. B. Persistenzdatenbanken). Eine Datenquelle enthält in ihrem eigenen Format. Wenn Sie die SDO-API der Version 1.0 verwenden, greift nur DMS auf die Datenquellen zu, die SDO-Anwendungen nicht. Die Anwendungen funktionieren nur mit DataGraphs der SDO Version 1.0.
Jede der folgenden Komponenten entspricht einer Java-Schnittstelle im SDO-Programmiermodell.
DataObjects

Als grundlegende Komponente von SDO stellt DataObjects eine allgemeine Sicht der strukturierten Daten für SDO-Clients bereit. DataObjects können mehrere unterschiedliche Attribute jedes serialisierbaren Typs (z. B. String oder Integer) enthalten. Komplexere DataObjects können auch einfachere DataObjects enthalten. DataObjects verwalten ihre Daten in Eigenschaften.

DataObjects der SDO Version 1.0 werden miteinander verknüpft und sind in DataGraphs enthalten. Die DataObject-Schnittstelle der Version 1.0 stellt einfache Erstellungs- und Löschmethoden (createDataObject() mit verschiedenen Signaturen und delete()) sowie reflexive Methoden bereit, um ihre Typen (Instanzklasse, Name, Eigenschaften und Namespaces) abzurufen. Die Schnittstelle unterstützt auch statische Objekttypen, die Sie über externe Codegeneratoren erstellen. Weitere Informationen hierzu finden sie im Artikel "Dynamische und statische Objekttypen für JDBC DMS".

DataGraphs

Ein DataGraph ist ein strukturiertes Ergebnis, das als Antwort auf eine Serviceanforderung zurückgegeben wird. Der DMS übersetzt die Ergebnisse der Back-End-Abfrage in den DataGraph, der vom ursprünglichen Back-End-Datenspeicher unabhängig ist. Auf diese Weise lässt sich der DataGraph einfacher in verschiedene Datenquellen übertragen. Der DataGraph umfasst miteinander verbundende Knoten, von denen jeder in SDO ein DataObject ist. Er ist unabhängig von Verbindungen und Transaktionen der ursprünglichen Datenquelle. Der DataGraph verfolgt die Änderungen, die von der ursprünglichen Quelle an ihm vorgenommen werden. Diese Änderungshistorie kann vom DMS verwendet werden, um die Änderungen an der ursprünglichen Datenquelle zurückzuverfolgen. Ein DataGraph kann problemlos aus und in XML-Dokumente konvertiert und somit auf die verschiedenen Schichten einer mehrschichtigen Systemarchitektur übertragen werden. Die gültigen Zugriffsverfahren auf einen DataGraph sind "breadth-first" und "depth-first". Außerdem stellt der DataGraph einen unabhängigen Cache bereit, der für Web-Services serialisiert werden kann.

Der vom Mediator zurückgegebene DataGraph kann dynamische oder generierte statische DataObjects enthalten. Die Verwendung generierter Klassen garantiert typensichere Schnittstellen, die einfacher zu programmieren sind und eine bessere Laufzeitleistung bieten. Die von EMF generierten Klassen müssen in Bezug auf Name und Typ dem Schema entsprechen, das für dynamische DataObjects erstellt wird. Es können jedoch zusätzliche Attribute und Referenzen definiert werden. Es werden nur die in der Abfrage angegebenen Attribute und Referenzen mit Daten gefüllt. Die restlichen Attribute und Referenzen werden nicht definiert.

Änderungsübersicht

Änderungsübersichten der SDO Version 1.0 sind in DataGraphs enthalten und werden für die Darstellung der Änderungen verwendet, die an einem vom DMS zurückgegebenen DataGraph vorgenommen wurden. Zunächst sind sie leer (wenn der DataGraph an einen Client zurückgegeben wird) und werden dann bei Änderung des DataGraph mit Informationen gefüllt. Der DMS verwendet die Änderungsübersichten während der Back-End-Aktualisierung, um die Änderungen wieder auf die Datenquelle anzuwenden. Auf diese Weise kann der DMS die Datenquellen anhand der bereitgestellten Listen mit den geänderten Eigenschaften (zusammen mit den alten Werten) und den erstellen und gelöschten DataObjects im DataGraph effizient und inkrementell aktualisieren. Der Änderungsübersicht eines DataGraph werden nur dann Informationen hinzugefügt, wenn die Protokollierung für die Änderungsübersicht aktiviert ist. Änderungsübersichten stellen dem DMS Methoden für das Aktivieren und Inaktivieren der Protokollierung bereit.

Anmerkung: Die Änderungsübersicht der SDO Version 1.0 ist keine Client-API. Sie wird nur von DMS verwendet.
Eigenschaften, Typen und Sequenzen

eDataObjects verwalten ihren Inhalt in einer Reihe von Eigenschaften. Jede Eigenschaft hat einen Typ. Es kann ein Attributtyp sein, wie z. B. ein primitiver Datentyp (z. B. int), ein häufig verwendeter Datentyp (z. B. Date) oder bei Referenzen der Typ eines anderen DataObject. Jedes DataObject stellt Lese- und Schreibmethoden (Getter und Setter) für seine Eigenschaften bereit. Außerdem werden verschiedene überladene Versionen dieser Zugriffsmethoden bereitgestellt, die den Zugriff auf die Eigenschaften durch Übergabe des Eigenschaftsnamens (String), der Nummer (int) oder des Metaobjekts für die Eigenschaft selbst unterstützen. Die Zugriffsmethode "String" unterstützt eine XPath-ähnliche Syntax für den Zugriff auf die Eigenschaften. Beispielsweise können Sie get("department[number=123]") für ein Firmen-DataObject aufrufen, um die erste Abteilung mit der Nummer 123 abzurufen. Sequenzen bieten noch mehr. Sie ermöglichen die Beibehaltung der Reihenfolge in heterogenen Listen mit Eigenschaft/Wert-Paaren.

Weitere einführende Informationen

Eine hilfreiche Einführung in SDO 1.0, die auch eine kleine Beispielanwendung enthält, finden Sie in der Veröffentlichung "Introduction to Service DataObjects" von IBM® developerWorks.

Anmerkung: Zum vollständigen Verständnis des EJB Data Mediator Service benötigen Sie umfassende Kenntnisse des EJB-Programmiermodells. Weitere Informationen finden Sie in den Artikeln "Taskübersicht: Enterprise-Beans in Anwendungen verwenden" und "Service Data Objects: Lernmaterial".

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cdat_datsdo
Dateiname:cdat_datsdo.html