Programmieren mit Pascal & Delphi

Inprise MIDAS ist ein hochproduktives Tool zur Erstellung sicherer verteilter Anwendungen. Von seiner Natur her ist MIDAS eine Technologie zur Datenkommunikation. Zwei Grundbestandteile der MIDAS-typischen Kommunikation sind der Provider und das Client Dataset. Diese beiden Komponenten tauschen über sogenannte Data Packets Informationen untereinander aus.

Auf unterster Ebene besteht ein Data Packet aus einem Array of Bytes. Tatsächlich enthält das Packet eine Datentabelle mit Support für diverse Datentypen einschließlich BLOBs und Nested Tables.

Das Client Dataset kann ein Data Packet vom Provider erhalten, im internen Speichercache ablegen und für Modifikationen verfügbar machen. Alle Änderungen an den Daten werden in einem internen Protokoll festgehalten.

Auf die Originaldaten kann man über das Property Data des Client Dataset zugreifen, während die Änderungsprotokollierung durch das Property Delta verfügbar gemacht wird. Darüber hinaus können die Daten, die sich im Besitz des Client Dataset befinden, jederzeit in eine externe Datei gespeichert werden. Dabei werden alle Änderungen zusammen mit den Originaldaten abgelegt.

Neben der Möglichkeit des Änderns von Daten im internen Cache, bietet das Client Dataset auch fortgeschrittene Techniken zum Sortieren, Filtern und Suchen.

Das Client Dataset weiß nichts über die wahre Quelle der Daten, die sie besitzt. Sind die Daten erst einmal als Array of Byte vom Provider empfangen worden, sind sie akzeptabel für alles, was damit geschehen soll.

Client Dataset

Der Prozeß des Aufbaus eines Data Packets wird von einer Provider-Komponente erledigt. Der Entwickler besitzt die volle Kontrolle darüber, wie die Daten vorbereitet und zusammengestellt werden. So ist es beispielsweise möglich, ein Data Packet aus einem Ergebnis einer SQL-Abfrage zu erzeugen oder manuell aus jeder nur denkbaren Informationsquelle zu erzeugen. Egal, woher die Daten stammen, das Endresultat wird immer eine vereinheitlichte Datentabelle aus einem Array of Byte.

Die Bandbreite der dem Client Dataset bekannten Feldtypen ermöglicht das Bereitstellen reichhaltiger Daten, die Strings, Inetegrs, Fließkommawerte, Datums-/Zeit-Felder, BLOBs und mehr beinhalten können. Zusätzlich existiert ein spezieller Feldtyp genannt Dataset Field. Mit diesem Feld kann der Entwickler einen kompletten Datensatz wie einen Feldwert des Ergebnissatzes speichern und damit effizient eine Master/ Detail-Relation beschreiben. Unter Rückgriff auf Dataset Fields kann der Entwickler sogar so weit gehen, ein komplettes Datenbankschema in einem Array of Bytes zur Manipulation durch das Client Dataset unterzubringen.

Ein Data Packet bietet darüber hinaus weitere Informationen zu den Daten. Zwei wichtige Teile dieser Information sind Constraints für Validierungen und benutzerdefinierte Properties sowohl auf Zeilen- als auch auf Feldebene. Ein Constraint ist eine einfache SQL-Auswertung und eine korrespondierende Fehlermeldung. Wenn eine Client-Applikation die im Client Dataset enthaltenen Daten aktualisiert, werden vom Provider mitgereichte Constraints automatisch angestoßen. Dies paßt auf der Client-Seite, wenn der Dateneintrag erfolgt. Ist einer der Constraints ungültig, weist das Client Dataset die Datenaktualisierung zurück und eine Exception mit einer entsprechenden Fehlermeldung wird ausgelöst.

Auf der Provider-Seite kann der Entwickler benutzerdefinierte Properties einem Data Packet hinzufügen, wenn der Provider das Packet zusammenstellt. Jedes Property erhält dabei seinen eigenen Namen, einen Wert und ein Gültigkeitsflag. Letzteres definiert, ob ein benutzerdefiniertes Property Teil des Dataset Delta Data Packets wird oder nicht.

Provider

Sobald das Data Packet im internen Cache des Client Dataset abgelegt ist, kann sein Inhalt manipuliert werden. Man kann durch die Datensätze navigieren, interessierende Datensätze suchen und Datensatzteile über fortgeschrittene Filteroperatoren wie LIKE, GETDATE, TRIM, LOWER, MONTH, und andere bearbeiten. Datensätze können im Client Dataset auch in jeder beliebigen Reihenfolge sortiert werden, unabhängig davon, wie ihre Eingangsreihenfolge lautete. Das Client Dataset kennt die wahre Quelle der Datensätze nicht und behandelt alle Spalten gleich. Modifikationen wie Einfügen, Aktualisieren und Löschen einzelner Zeilen sind ebenso möglich. Das Client Dataset verwaltet dazu alle Änderungen in Form von Speicherindizes, um unterschiedliche Ordnungen der Datensätze zu ermöglichen.

Als eine weiter fortgeschrittene Technik unterstützt das Client Dataset die Document/View Architektur, so daß verschiedene Ansichten des gleichen Data Packets mit Zugriffen auf gemeinsam genutzte Datensätze möglich sind. Dazu werden für die in frage kommenden Datensätze über Cloning Kopien erzeugt, wobei jeder Prozeß beliebig viele Kopien eines Data Packets besitzen kann, sofern der Speicher ausreicht.

Eine spezielle Anforderung an die mobile Datenerfassung besteht darin, mehrfache Änderungen an Daten über einen fortlaufenden Zeitraum vorzunehmen, diese in einem Data Packet temporär zu speichern und bei Bedarf zurückzuladen, ohne die vorgenommenen Änderungen zu verlieren. Diese Möglichkeit stellt das Client Dataset über das sogenannte briefcase Computing bereit.

Mit einem Data Packet arbeiten

Sobald die Daten im Data Packet erfolgreich bearbeitet wurden, können die Änderungen auf die ursprüngliche Quelle durchgeschrieben werden. Hierzu muß das Protokoll der Änderungen an den Provider übergeben werden. Ist die Quelle des Data Packets eine Datenbank, ist der Provider intelligent genug, um die Datenupdates an die entsprechenden Tabellen zu verteilen.

Der Entwickler besitzt die Kontrolle über den Updateprozeß und falls nötig, kann ein eigenes Regelwerk implementiert werden. Kann der Datensatz nicht vom Änderungsprotokoll auf die Datenquelle durchgeschrieben werden, schreibt der Provider ein Fehlerprotokoll zusammen mit einer Fehlermeldung und den aktuellen Datenwerten der Quelle.

Während des Abarbeitens des Änderungsproptokolls führt der Provider entweder ein Commit aller erfolgreichen Änderungen auf die Datenbank aus oder nimmt ein Rollback vor. Commit oder Rollback hängen hierbei von der Anzahl der aufgetretenen Fehler ab, sowie der Vorgabe, wie viele Fehler auftreten dürfen.

Abschließend sendet der Provider alle protokollierten Probleme an das Client Dataset.

Updates vornehmen

Das Client Dataset prüft das vom Provider erhaltene Fehlerprotokoll gegen das eigene Protokoll der Änderungen. Während der Iteration durch das Änderungsprotokoll versucht das Client Dataset, den Datensatz im Fehlerprotokoll zu finden. Wird der aktuelle Datensatz nicht im Fehlerprotokoll gefunden, fügt das Client Dataset die Änderungen mit den Originaldaten des Data Packets zusammen und entfernt den Datensatz aus dem Änderungsprotokoll, womit die Änderung auch für das Client Dataset vollzogen ist.

Für jeden problematischen Datensatz wird ein spezieller Event ausgelöst. Bei der Behandlung des Events hat der Entwickler vollen Zugriff auf die neuen und alten Feldwerte des Datensatzes im Änderungsprotokoll, ihre aktuellen Werte in der Datenbank, sofern diese verfügbar sind, und dem vom Provider gemeldeten Fehler. Der vom System bereitgestellte vorgefertigte Dialog kann ggfs. zusammen mit eigenem Code eingesetzt werden, um Fehler zu behandeln.

Update in Einklang bringen

Wie die vorhergehenden Absätze gezeigt haben, gibt es drei verschiedene Übertragungsansätze von Data Packets zwischen Provider und Client Dataset, der Datenfluß ist nachfolgend noch einmal zusammengefaßt.

Unter MIDAS gibt es zwei mögliche Anwendungs-Architekturen:

• Monolithische Applikationen, die sowohl den Provider als auch das Client Dataset beherbergen.
• Multiple Applikationen, die entweder den Provider oder das Client Dataset beinhalten.

Im ersten Fall hat der Entwickler direkten Zugriff auf sämtliche Properties von Provider und Client Dataset Komponenten. Es ist somit kein großer Aufwand, das Data Packet von einer Komponente zur anderen zu transportieren.

Der zweite Ansatz ist hingegen etwas anspruchsvoller, daß man sich auf Standard-Protokolle mir Remote Procedure Call Unterstützung wie beispielsweise IIOP (BRBA) oder RPC (DCOM, DCE) verlassen muß, um die Datenpakete von einer Anwendung zur anderen zu transportieren. Grundsätzlich besteht natürlich auch die Möglichkeit, normales TCP/IP zu implementieren, um die Daten zwischen den Anwendungen auszutauschen. Da die Data Packets lediglich aus einem Array of Byte bestehen, kann jede der genannten Techniken verwendet werden, um die Daten über eine Verbindung zu versenden.

Zusammenfassung

Inprise MIDAS bietet einen High-Performance Mechanismus zur Datenbank-Kommunikation, bei dem zwei MIDAS Komponenten, der Provider und ein Client Dataset, Datenpakete miteinander austauschen. Der Provider ist dabei für das Bereitstellen der Daten sowie das Übernehmen der vorgenommenen Änderungen zuständig, während das Client Dataset die Manipulation der Daten erlaubt.

Für den Transport der Daten kommen unterschiedliche Technologien in frage, die nachfolgend anhand praxisnaher Beispiel vorgestellt werden.

Verfügbarkeit

MIDAS ist als Set von VCL Komponenten für Delphi und C++ Builder implementiert. Darüber hinaus existieren diverse Tools, die das Arbeiten mit MIDAS erleichtern.

Die höchst mögliche Entwicklungsproduktivität und Laufzeit-Performance der MIDAS Komponenten erreicht man direkt mit der Borland Database Engine, da der BDE-fähige Provider Bestandteil der Client/Server Versionen von Delphi und C++Builder sind. Entwicklern steht es frei, ihre eigenen Provider zu erstellen und mit beliebigen Datenzugriffstools und Informationsquellen zu arbeiten.

Die Enterprise/Professional Versionen von Delphi und C++-Builder kommen mit der Entera Middleware Suite ins Haus. Teil dieses Tools ist die Datenzugriffstechnologie, die mit der Entera Provider Komponente verbunden werden kann.

Zu guter letzt ermöglicht auch J/MIDAS Java Clients die Interaktion mit MIDAS Server, die in Delphi oder C++Builder entwickelt wurden. J/MIDAS ist ein Set aus Java Beans Komponenten, die ein Data Packet lesen und den geänderten Inhalt zurücksenden können.

Data Packet Transport