Die Serverkommunikation
Als unteres Ende des CDO Clients in Richtung Repository kann man sich die CDOSession vorstellen. Sie überträgt neue und geänderte Revisions zum Server, wenn Transaktionen committed werden, und sie fordert auch Revisions vom Server an, wenn diese bei Lesezugriffen auf das Modell nicht im Cache gefunden werden. Die gesamte Kommunikationslogik ist in einem Interface abstrahiert, dem CDOSessionProtocol, das sich mit fast beliebigen Transportmitteln implementieren lässt. Die Umsetzung auf Basis der Net4j Signalling Platform, die vor fünf Jahren zunächst eigens für die Anforderungen von CDO entwickelt wurde, ist derzeit die Standard-Implementierung. Net4j bietet u. a.:
- Einen kompakten und schnellen Multiplexing Kernel, der ausschließlich auf buffered, non-blocking I/O beruht
- Ein erweiterbares Framework für physische Transportmethoden, mit Connector- und Acceptor-Implementierungen für TCP, HTTP und JVM (direkte Methodenaufrufe innerhalb einer Virtual Machine)
- Mehrere virtuelle Channels pro physischer Verbindung zur Übermittlung von Buffer-Sequenzen
- Ein erweiterbares Framework für anwendungsbezogene Kommunikationsprotokolle (CDO implementiert ein solches) auf Stream-Basis
- Pluggable Authentication, Remote Progress Monitoring und mehr
Das Model Repository
Genau wie ein CDO Client kann ein CDO-Server (Abb. 6) entweder innerhalb von OSGi/Eclipse oder völlig autonom betrieben werden. Auch einer Einbettung in einen JEE Container steht prinzipiell nichts entgegen (eine besonders interessante Option ist übrigens die Einbettung eines CDO Clients in einen Web Container!). In einem Server können, ausreichende Ressourcen vorausgesetzt, beliebig viele Repositories laufen. Jedes einzelne Repository besteht dabei aus zwei Ebenen. Die obere Ebene beheimatet eine Reihe von Managerkomponenten für spezielle Aufgaben. Neben dem Lock Manager, dem Commit Manager, dem Notification Manager und dem Query Manager sind vor allem der Session Manager, der Package Manager und der Revision Manager von Bedeutung. Dazu kommt noch die Möglichkeit, Read und Write Access Handlers am Repository zu registrieren, um zum Beispiel den Zugriff auf Daten zu beschränken oder Fremdsysteme bei Modifikationen zu benachrichtigen. Alle Komponenten dieser Ebene sind noch vollständig unabhängig von dem unterliegenden Persistenzmechanismus.
Die untere Ebene eines Repositories dient ausschließlich der Backend-Integration, also der Anbindung an existierende Datenquellen unterschiedlichster Art zur Speicherung und zum Laden von Revisions. Ein solcher Integrationsadapter wird in CDO als "Store" bezeichnet, und um neue Datenquellen zu integrieren, müssen lediglich wenige Interfaces implementiert werden. Die gängigen Backends kann CDO aber bereits mit Bordmitteln bedienen. Folgende Stores gehören derzeit zum Lieferumfang:
- MEMStore ist eine transiente Umsetzung des Store-Vertrags. Er wurde hauptsächlich zu Testzwecken entwickelt, kann aber durchaus auch in speziellen Anwendungsszenarien von Interesse sein.
- DBStore ist der traditionelle, proprietäre O/R Mapper von CDO. Er bietet einige Eingriffsmöglichkeiten in das konkrete Mapping von Klassen auf Tabellen. Im Wesentlichen basiert er auf einer horizontalen Mapping-Strategie, also auf einer Abbildung jeder konkreten Klasse auf eine eigene, in sich abgeschlossene Tabelle. Eigene Mapping-Strategien können wiederum problemlos ergänzt werden. Der DBStore bildet eine Art Referenzimplementierung des Store-Vertrags. Er ist am einfachsten zu konfigurieren, unterstützt zuerst alle Features des Frameworks und sollte folglich zumindest für die Erstevaluierung von CDO verwendet werden.
- HibernateStore ist eine Anbindung an relationale Datenbanken auf dem Umweg über Hibernate. Er implementiert den Store-Vertrag mithilfe von Teneo [4], ebenfalls eine Komponente von EMF, und wurde ursprünglich von Martin Taal, dem Vater von Teneo, entwickelt. (Anmerkung des Autors in eigener Sache: Wir sind derzeit aus Zeitgründen auf der Suche nach neuen Adoptiveltern für die Hibernate-Integration und würden uns in diesem Zusammenhang sehr über Interesse bei Hibernate-Experten freuen.)
- ObjectivityStore bindet CDO Repositories an die objektorientierten Datenbanken der gleichnamigen Firma an. Diese Integration wurde von Simon McDuff, einem Mitglied des CDO-Teams, entwickelt und ist beim kanadischenVerteidigungsministerium erfolgreich im produktiven Einsatz. Leider haben lizenzrechtliche Bedenken eine Veröffentlichung des ObjectivityStores bis jetzt verhindert. Wir stehen diesbezüglich in freundschaftlichem Kontakt mit Objectivity Inc., wo man an einem neuen, kostenfreien Lizenztyp speziell für die Entwicklung mit CDO und EMF arbeitet.
Jede Teilkomponente eines CDO-Servers ist eine ganz normale Java Bean, die klare Interfaces implementiert und bei Bedarf einfach ausgetauscht werden kann. Die Verdrahtung und Konfiguration zur Laufzeit kann auf vielfältige Weise erfolgen. Die CDO-Distribution enthält Beispiele für manuelle Verdrahtung, Spring Application Contexts, einen Extension-Registry-basierten, proprietären Wiring-Container und eine Headless OSGi Application, die die Konfiguration aus einer XML-Datei liest und dann über die OSGi Console steuerbar ist. Alle Komponenten von CDO und Net4j sind in ein Operations-and-Maintenance-Framework eingebunden, das wichtige Aufgaben wie Tracing, Logging, Progress und Performance Monitoring, Preferences und Lifecycle Management abstrahiert und nahtlos in die jeweiligen Services einer konkreten Laufzeitumgebung einbindet.
EMF ist toll!
Ich hoffe, dass ich eine verständliche Einordnung von Modeling in den Enterprise-Kontext geben und aufzeigen konnte, welche Aufgabenbereiche EMF und CDO dabei abdecken. Die Eingangsfrage beantworte ich mit einem klaren: "Ja, EMF ist toll", und zwar nicht, weil es alle Mittel zum Einsatz von Modeling im großen Maßstab bereits mitbringt, sondern weil es dem Anwender und Frameworks wie CDO elegante Schnittstellen zum Einklinken aller fehlenden Funktionalitäten bietet.Nachdem Nutzen und Aufbau von CDO beleuchtet wurden, fehlen noch einige praktische Übungen und Codebeispiele. Im zweiten Teil dieser Artikelserie werde ich konkret zeigen, wie man ein EMF Model für CDO aufbereitet, wie man ein CDO Repository startet und wie man Code gegen die CDO APIs schreibt. Dabei werden neben den Grundlagen wie dem Öffnen von Sessions oder dem Arbeiten mit Transactions auch viele der neuen Features wie Resource Folders, Query Framework, Explicit Locking, Save Points, Passive Updates und Change Subscriptions gestreift. Abrunden werde ich die Serie mit einem Ausblick auf die kommenden Aktivitäten in den Bereichen Offline Mode, Legacy Model Support und OCL als Common Query Language auf dem Server, sowie Integrationen mit EFS, Team Support, Common Navigator und GMF. Bis dahin freue ich mich über Besucher auf der brandneuen CDO-Homepage, in meinem Blog über Eclipse und Modeling [5], sowie auf spannende Diskussionen in der Newsgroup [6].
Eike Stepper ist der ursprüngliche Autor von CDO und Net4j und leitet das inzwischen siebenköpfige, internationale Committer-Team. Mit seiner 1991 gegründeten Firma ES-Computersysteme konnte er in vielen Projekten Erfahrungen als Entwickler und Berater sammeln. Themen wie Modeling, OSGi-Softwaredesign und "gutes Entwickeln" faszinieren ihn immer wieder. 
