Einführung
SDO ist eine Spezifikation für ein Programmiermodell, das einen einheitlichen, von Datenquellen unabhängigen Zugriff
auf Back-End-Daten ohne aktive Verbindung ermöglicht. Mit diesem Modell können Daten aus jeder Datenquelle (Relationale
Datenbank, EJB-Entity-Beans, Web-Service, XML-Datenquellen etc.) abgerufen und in einem strukturieren Datengraph
(DataGraph) einheitlich dargestellt werden. SDO ermöglicht Operationen ohne aktive Verbindung, da der Datagraph
unabhängig von Back-End-Verbindungen oder Transaktionen abgerufen werden kann. Diese Spezifikation liegt zurzeit noch
als Vorschlag beim JCP-Komittee (Java Community Request) als JSR (Java Specification Request) 235 vor.
Architektur
Die SDO-Architektur verwendet eine einheitliche Datenzugriffsschicht (Data Mediator Service), um DataGraphs aus
heterogenen Datenquellen an Clients zurückzugeben. Abbildung 4 zeigt die Komponenten der SDO-Architektur.
Abbildung 4: DataObject der SDO-Architektur
Ein DataObject enthält tatsächliche Daten (z. B. Werte eines primitiven Datentyps oder eine Datenzeile aus einer
relationalen Datenbank) sowie mögliche Referenzen auf andere DataObjects. Mittels einer Prüfung können Typ, Beziehung
und Vorgaben festgestellt werden.
DataGraph
Ein DataGraph enthält eine Reihe von DataObjects und stellt üblicherweise die Übertragungseinheit zwischen den
Komponenten in der Architektur dar. Er zeichnet alle Änderungen an den Daten, einschließlich neuer, geänderter oder
gelöschter DataObjects auf.
Data Mediator Service
Ein Data Mediator Service (DMS) ist für die Interaktion mit einer Datenquelle verantwortlich, um daraus einen DataGraph
zu erstellen, der Daten enthält. Dieser Plug-in-Service ändert umgebungsspezifische Datendarstellungen in die von SDO
lesbare grafische Darstellung. Der DMS ist außerdem dafür verantwortlich, die Datenquelle mit den Änderungen, die an
einem DataGraph vorgenommen wurden, zu aktualisieren.
Anwendbarkeit von Frameworks
Mit der SDO-Technologie soll die Integration von Tools und Frameworks vereinfacht werden. Im Zusammenhang mit JSF und
anderen MVC-Frameworks kommen die beiden folgenden Lösungen in Betracht:
Bindung von UI-Komponenten an SDO (JSF)
In einem JSF-Framework können Werte für Webbenutzerschnittstellenkomponenten über Deklarationen an SDOs für den Abruf
von Daten gebunden werden. Eine Datentabellenkomponente kann für den Abruf von Werten aus einer Back-End-Datenquelle an
ein SDO gebunden werden. Diese Kombination vereinfacht die Datenkonnektivität von einer UI-Komponente, ohne dass
Programmierung erforderlich ist. Abbildung 5 zeigt die Architektur aus der Bindung von JSF-UI-Komponenten an SDOs.
Abbildung 5: SDOs mit JSF verwenden
SDOs mit Modellobjekten verwenden (beliebiges MVC-Framework)
Die Modellschicht eines MVC-Frameworks kann SDOs für den Zugriff auf Back-End-Daten verwenden. Abbildung 6 zeigt ein
Beispiel für einen Modellclient, der SDOs für den Zugriff auf mit Entity-EJBs persistent gespeicherte Daten verwendet.
Das Modellobjekt verwendet Datagraphs, die von einer Stateless-Session-EJB-Fassade zurückgegeben wurden. Diese
Session-Bean-Fassade wiederum ruft Datagraphs vom DMS ab, der als Datenfassade für den Entity-EJB-Peristenzmechanismus
eingesetzt wird.
Abbildung 6: SDOs mit Modellobjekten und EJBs verwenden
Ressourcen
Zusätzliche Informationen zu den Anwendungs-Frameworks und zur Komponententechnologie finden Sie auf den folgenden
Webseiten:
|