Die Entwicklungszeiten von Anwendungen müssen sich den beschleunigten Geschäftsprozessen anpassen. Die Firma Intersystems versucht dies mit ihrer objektrelationalen Datenbank Caché 4.0 und Caché Server Pages. Wir haben die Linux-Version des Produkts unter die Lupe genommen.

Viele Datenbanksysteme sind bereits auf Linux portiert worden. Dazu zählen auch solche, die ihre Datenbestände nicht in Form flacher, relationaler Tabellen, sondern objektorientiert verwalten. Ein Vertreter dieser Richtung ist die postrelationale Datenbank Caché der Firma Intersystems.

Caché, aktuell in der Version 4.0 vorliegend, bedient sich einer speziellen Form der Datenverwaltung, der Unified Data Architecture (Abbildung 1). Dabei ist es möglich, mit einer ganzen Reihe von Front-Ends auf die Datenbestände zuzugreifen und sie für die verschiedensten Auswertungen zur Verfügung zu stellen. So hat jeder Entwickler das ihm gewohnte Werkzeug und ist auch unabhängig vom eingesetzten Betriebssystem, das auf Server- und Client-Seite auch unterschiedlich sein kann.

Bezüglich der Serverplattform kann zwischen OpenVMS, Windows sowie verschiedenen Unixen und Linuxen gewählt werden. Offiziell unterstützt Intersystems Red Hat 6.0 bis 7.0, SuSE 6.3 bis 7.0 und Turbo Linux 6.0. Jedoch ist der Server bei etwas Aufwand auch mit höheren Versionen oder anderen Distributionen lauffähig.

Installationshürden

Für den Test stand die Linux-Department-Version 4.0.3 des Caché-Datenbankservers zur Verfügung. Nach dem Mounten der CD beginnt mit der Kommandofolge

cd /cdrom
./cinstall

die Installation. Hierzu ist ein echter Root-Login erforderlich, »su« führt zum Abbruch. Das Installationsskript »cinstall« testet auf Vorhandensein eines unterstützten Betriebssystems und fragt vom Administrator das Installationsverzeichnis ab. Danach wird eine Reihe weiterer Fragen zur Installation gestellt, unter anderem nach der Gruppe des Benutzers, der den Datenbankserver starten und herunterfahren darf. Zweckmäßig ist hier »root« anzugeben.

Das Kopieren von Dateien geht flott vonstatten (auf den meisten gängigen PCs unter zehn Minuten); danach wird der Server sofort gestartet und initialisiert. Schließlich ist noch eine Reihe diffiziler Fragen zur Lizenz zu beantworten. Der letzte Teil lässt sich auch auf später verschieben, dann läuft die Datenbank zunächst mit einer Ein-Benutzer-Lizenz, wie sie Beta-Testern bekannt ist (siehe Web-Link [1]).

Die Erweiterung der Lizenz lässt sich jederzeit nachträglich vornehmen. Zusätzlich ist es möglich, im Anschluss an die eigentliche Serverinstallation ein CGI-Interface zum – unter Linux meist vorhandenen – Webserver zu installieren. Dieser Installationsschritt macht den Server fit zur Verarbeitung von Cache Server Pages (CSP) und lässt sich, wie schon der vorige, auch später ausführen. Das zugehörige Skript »CSPinstall,« das sich im Unterverzeichnis »csp« des Caché-Installationsverzeichnisses befindet, hat einen kleinen Bug: Die Zeile

WSCGI ="/usr/httpd/cgi-bin"

müsste eigentlich lauten:

WSCGI="/usr/httpd/cgi-bin"

Das stört aber den Installationsprozess nur wenig. Gravierender ist der Lapsus, dass in die Apache-Konfigurationsdateien einfach beim jeweils letzten Auftreten des Containers für das CGI-Directory ein »FollowSymlinks« an die Optionen angehängt wird. Das kann gut gehen, schief geht es aber auf jeden Fall bei den »SSLOptions«, wo es natürlich ein Syntaxverstoß ist.

Deshalb empfiehlt es sich nicht, am Ende der Installation den Apache-Webserver neu starten zu lassen, da er sonst leise abstirbt. Vielmehr ist die überzählige Option von Hand aus dem SSL-Abschnitt der Datei »httpd.conf« beziehungsweise der »access.conf« zu entfernen und in den richtigen Container einzusetzen. Erst dann darf der Webserver neu gestartet werden. Zusätzlich ist ein Neustart des »CSPnsd« (CSP network service daemon) erforderlich. Leider versteht der Dämon das HUP-Signal nicht im üblichen Sinne, so dass er über

Installationsverzeichnis/csp/CSPnsd

im Anschluss an ein vorher gegebenes TERM- beziehungsweise HUP-Signal erneut gestartet werden muss.

Caché Server Pages

Nach all diesen Mühen wird der Installateur durch einen schönen Erfolg belohnt. Ein Blick auf die offenen Ports zeigt uns:

netstat -ta

Active Internet connections
(servers and established) Proto Recv-Q Send-Q Local
Address Foreign Address
State tcp 0 0 *:7038 *.* LISTEN
tcp 0 0 *:intersys-cache *.* LISTEN ...

Beide erforderlichen Ports »1972« und »7038« werden überwacht; sowohl der Datenbankserver als auch der CSP-Network-Service-Dämon warten auf Aufträge. Das lässt sich gleich verifizieren, indem in einem Javascript-fähigen Webbrowser die URL »http://localhost/csp /samples/menu.csp« eingegeben wird. Es dauert einen Moment, weil der Datenbankserver die angeforderte Seite beim ersten Aufruf zunächst kompilieren muss, aber dann erscheint ein Menü mit Links auf Beispielseiten, die die Leistungsfähigkeit der CSP-Technologie eindrucksvoll demonstrieren.

Eine einfache Anwendung ist die Anzeige von Eigenschaften gespeicherter Objekte (Abbildung 2): Der Benutzer trägt im Formularfeld eine Zahl von 1 bis 100 ein und klickt auf den »Go«-Button. Daraufhin wird das gespeicherte Objekt aus der Datenbank in den RAM geholt, wo sein Inhalt für diverse Auswertungen zur Verfügung steht. In unserem Fall handelt es sich um ein Objekt der Klasse »Person«, dessen Eigenschaften »Name« und »SSN« (Sozialversicherungsnummer) im unteren Teil des Browserfensters angezeigt werden.

Beim Browserzugriff ist es seitens der Datenbank egal, von welchem Rechner aus er erfolgt. Für den Caché-Server tritt als Kunde stets der Apache-Server in Erscheinung. Dessen Zugriffsberechtigungen sind für Remote-Zugriffe natürlich entsprechend den Wünschen des Anwenders einzustellen. Ist dies geschehen, kann der Client-Rechner irgendwo im Netz stehen, auch das Betriebssystem ist beliebig. Es ist lediglich in der obigen URL die Bezeichnung »localhost« durch den DNS-Namen oder die IP-Adresse des Hosts zu ersetzen, auf dem der Webserver läuft.

Abbildung 1: Die Unified Data Architecture (UDA) erlaubt sowohl objektbasierte als auch SQL-Zugriffe auf die gespeicherten Daten.

Unter der Haube

Die hier verwendete Technologie der Caché Server Pages ist eine Intersystems-Erfindung. Sie erinnert ein wenig an Active Server Pages, ist allerdings speziell auf die Verwendung mit der objektorientierten Datenbank Caché zugeschnitten. Das hat Vor- und Nachteile: Man kann damit mehr (und in kürzerer Zeit) tun als mit einer allgemein verbreiteten Sprache, andererseits bringt es zusätzlichen Lern- und Gewöhnungsaufwand mit sich.

Einfache Aufgaben – mal eben einen kleinen E-Shop schreiben – lassen sich relativ schnell bewerkstelligen; für die Raffinessen wie das Definieren von eigenen Tags (siehe Beispielseite »custom.csp«, ganz oben im Hauptmenü) braucht es aber doch eine beträchtliche Einarbeitungszeit. Alle mitgelieferten Beispielseiten liegen im Quellcode vor, so dass man ihnen viele Programmiertricks entnehmen kann.

Das hilft genauso bei der Aneignung der notwendigen Techniken wie das didaktisch gut aufgebaute Tutorial, das aber leider nicht auf jeder Installations-CD zu finden ist – besonders bei Linux-Versionen glänzt es durch Abwesenheit.

Sie erhalten die vollständige Dokumentation zusammen mit der Single-User-Version für Linux und Windows[1] über einen Download beziehungsweise auf Anforderung auch als CD. Die Startseite des CSP-Tutorials ist unter

docs/tutorials/BuildWebApps/Start.htm

auf dem Datenträger oder im Installationsverzeichnis der Dokumentation zu finden. Funktionieren bei Benutzung der CD einige Links zu Bildern oder anderen HTML-Seiten nicht, versuchen Sie den Datenträger mit der Option »-o map=o« zu mounten. Das verhindert die Umwandlung von Groß- in Kleinbuchstaben beim Mapping von Dateinamen.

Caché Server Pages sehen aus wie gewöhnliches HTML. Der einzige Unterschied sind eingebettete Tags, die den Umgang mit Server-Objekten managen. Die Einbettung erfolgt in XML-Manier; außer der speziellen Syntax der Tags gibt es folglich kaum etwas zu beachten oder zu erlernen. Betrachten wir als Beispiel den Code der Seite »object.csp« in Listing 1, der den Browser-Inhalt von Abbildung 2 erzeugt: Der Zugriff auf das gewünschte Objekt vom Typ »Person« wird durch das »csp:OBJECT-«-Tag bewerkstelligt. Die eindeutige Object-ID wird beim Aufruf der Seite mitgeliefert und über die Methode »%request.Get()« bereitgestellt. Der resultierende HTML-Code wird vom Caché-Datenbankserver erzeugt und an den anfordernden Webserver geschickt, der ihn an den Browser des Benutzers weiterleitet.

Sind an bestimmten Stellen der HTML-Seite variable Inhalte einzusetzen, wird die Konstruktion »#( Variable oder Ausdruck)#« verwendet. Bezugnahmen auf Objekteigenschaften gestalten sich gewohnterweise in der Form » Objektinstanz.Eigenschaftsname«, Beispiel: »person.Name«.

Alles andere ist HTML: Ein Formular um Interaktivität zu ermöglichen, ein Textfeld um die Objekt-ID anzuzeigen und zu verändern, dazu ein Submit-Button um den nächsten Request auszulösen. Schließlich noch eine Reihe notwendiger Formatierungen – und das war’s auch schon. Eine Besonderheit sind lediglich die »csp:IF-«Tags mit entsprechender schließender Klammer »/csp:IF.« Sie schließen Seitenabschnitte ein, deren Inhalt nur bei Erfüllung gewisser Bedingungen generiert wird. Im Listing sehen Sie einerseits die Fehlerreaktion, falls kein passendes Objekt in der Datenbank gefunden wird, und andererseits im Erfolgsfall die Ergebnisanzeige.

Ähnliche Mechanismen wie hier bei der Datenauswertung helfen auch beim Anlegen neuer Datenobjekte und ihrer Speicherung in der Datenbank. Natürlich lassen sich mit den CSP-Techniken nur solche Objekte anlegen und verwalten, deren Strukturdefinition (Klassendefinition) zuvor bereits in der Datenbank verewigt wurde. Hierzu benötigt man weitere Werkzeuge, die Caché selbstverständlich auch mitbringt.

Abbildung 2: So einfach holt man ein Objekt aus der Datenbank und bekommt dessen Eigenschaften am Bildschirm präsentiert.

Schöpfungsgeschichte

Das eine dieser Werkzeuge ist die Class Definition Language CDL, die zur Beschreibung von Klassen, Eigenschaften, Methoden und weiterer Parameter dient und direkt durch den Datenbankserver verarbeitet wird. CDL-Dateien sind einfache Ascii-Dateien, die vor ihrer ersten Benutzung vom Server zu kompilieren sind. Die innere Struktur erinnert etwas an »named.conf«-Dateien von Nameservern; die Syntax ist ausführlich in [2] (Seiten 74 bis 92) beschrieben.

CDL-Dateien können unter Linux mit einem beliebigen Texteditor angelegt und editiert werden. Der Kompilierungsvorgang ist über die Kommandozeile oder in einem Terminalfenster zu bewerkstelligen. Zu diesem Zweck wird einfach die Server-Binary »/usr/bin/cache« am Kommandoprompt eines gültigen Linux-Benutzers gestartet. Eine gesonderte Authentifizierung gegenüber dem Datenbankserver erfolgt nicht.

Diese Methode ist universell von allen Betriebssystemen aus nutzbar, auch remote. Sie hat allerdings den Nachteil, etwas umständlich und wegen fehlender Entwicklungsumgebung auch recht fehleranfällig zu sein. Wesentlich eleganter ist für diese Zwecke der Einsatz eines weiteren Werkzeugs aus der Caché-Palette, des Object Architect. Den Caché Object Architect gibt es zurzeit nur als Windows-Software; er kann jedoch auch jederzeit problemlos zur Erzeugung und Bearbeitung von Klassen auf Caché-Linux-Servern eingesetzt werden.

Die Verbindung erfolgt über TCP/IP, speziell über den normalen Caché-Port »1972«. Ist die Verbindung einmal eingerichtet, gestalten sich Aufbau und Erweiterung einer Datenbank-Struktur denkbar einfach. Vorausgesetzt wird, dass der abzubildende Wirklichkeitsausschnitt bereits in Form einer Hierarchie von Klassen mit ihren Eigenschaften und Methoden modelliert wurde.

In diesem Fall bietet die intuitiv bedienbare Oberfläche des Object Architect elegante Möglichkeiten. Alle Eigenschaften, Methoden und Parameter von Klassen – und damit von ihren Instanzen, den Objekten – lassen sich elegant über Eingabemasken mit Karteireitern, Dropdown-Listen, Checkboxen und anderen bekannten GUI-Elementen festlegen.

Abbildung 3 zeigt die Gestaltung einer Klasse »Person«, die Daten über Namen, Vornamen, Geburtsdaten und Anschriften von Personen aufnehmen soll. Für die Definition der Eigenschaften sind sowohl eingebaute Datentypen wie »%Library.Date« und »%Library.String« nutzbar als auch zuvor festgelegte wie die benutzerdefinierte Klasse »lxmag.Adresse« für die Eigenschaft »Anschrift«.

»lxmag.Adresse« seinerseits verfügt wiederum über die Eigenschaften

Ort     %Library.String
PLZ     %Library.Integer
          (MAXVAL=99999,MINVAL="01000")
Strasse %Library.String

(im Bild nicht sichtbar). Das Beispiel der Postleitzahl zeigt andeutungsweise, dass sich eine ganze Reihe weiterer Festlegungen für die Eigenschaften der Eigenschaften treffen lassen. Auf diese Weise sind auch relativ komplizierte Zusammenhänge schnell und relativ fehlerunanfällig formulierbar.

Abbildung 3: Der Caché Object Architect am Werk.

Front-Ends im Sixpack

Damit sind wir eigentlich komplett. Wir verfügen über einen Datenbankserver unter Linux und die nötigen Ein- und Ausgabeverfahren. Entwickler interessieren sich natürlich besonders für die Möglichkeiten, eigene Anwendungen auf der Basis einer Datenbank zu erstellen. Auch dafür bietet das Intersystems-Produkt viele Ansätze.

Der erste und wichtigste ist zweifellos die Anwendung des Web-Interfaces und der Caché Server Pages. Klar auf der Hand liegender Vorteil: Die Programmlogik wird in HTML eingebettet; die ursprüngliche Erzeugung und teilweise syntaktische Prüfung kann mit einem beliebigen Web-Entwicklungssystem erfolgen, die Quelltexte sind jederzeit einsehbar und editierbar. Hinzu kommt, dass neue oder veränderte Seiten bei ihrem ersten Aufruf von Caché kompiliert und in effektive interne Prozeduren des Servers umgewandelt werden.

Es handelt sich also bei der Kombination Caché/CSP um einen echten Applikationsserver mit allen damit einhergehenden Vorteilen wie Sicherheit und Performance. Ein Blick in die Suchmaschine Scoutmaster[3] – eine native Caché-Anwendung – zeigt, wie so etwas in der Praxis aussehen kann.

Am Rande: Macromedias Dreamweaver unterstützt seit der Version 3 ganz speziell auch Caché-eigene Tags, wofür bei der Installation der Windows-Version, sofern ein Dreamweaver gefunden wird, die richtigen Eingabemasken gleich passend eingespielt werden.

Nun entwickelt aber nicht jeder fürs Web. Deshalb gibt es eine Reihe weiterer Möglichkeiten, Caché-Datenstrukturen effektiv in Front-End-Applikationen einzubinden. Ein Blick auf Abbildung 1 zeigt, dass sich diese je nach verwendeter Zwischenschicht der Unified Data Architecture gestalten.

Für den objektorientierten Ansatz gibt es neben den unter Microsoft-Betriebssystemen einsetzbaren ActiveX-Controls – unter anderem eine hervorragende VBA-Anbindung – die mehr oder weniger betriebssystemunabhängigen Bibliotheken für C++ und Java, mit denen die Programmiererschaft nach kurzer Einarbeitungszeit flott zu Werke geht. Wer die SQL-Sicht auf gespeicherte Daten bevorzugt, ist mit JDBC meist am besten bedient. Es gibt auch bereits einen ODBC-Treiber für Linux, der jedoch für diesen Artikel nicht mehr getestet wurde.

Ein kleines Handicap für Entwickler soll nicht verschwiegen werden: Konsequente Anwendungsentwicklung im Stil eines Application Servers bedeutet auch und vor allem das Schreiben von Methoden, die in den Klassen oder ihren Instanzen, den Objekten, genutzt werden. Für die Entwicklung von Methoden wird Caché Object Script verwendet, eine Sprache, die zwar an vieles erinnert, was der Programmierer so kennt, aber mit keiner anderen Sprache identisch ist.

Ob es wirklich erforderlich war, den schon zahlreich vorhandenen Lösungen noch eine eigene hinzuzufügen, mag Gegenstand endloser Diskussionen sein. Ein Lichtblick: Die neueste Ausgabe von Caché Object Script hat die meisten zuvor vorhandenen Eigenbrötlereien abgelegt und ist nun stärker an Gewohntes angelehnt.

Fazit und Ausblick

Alles in allem: Caché 4.0 von Intersystems ist eine interessante Alternative für Datenbank- und Applikationsserver unter Linux. Besonders in der schnelllebigen Welt der Web-Entwicklung könnte es in Teilbereichen anderen Produkten den Schneid abkaufen.

Nachholbedarf besteht zweifellos bei den Front-Ends unter Linux, besonders bei den Verwaltungstools, die es in benutzerfreundlicher Ausführung bisher nur für Windows gibt – da aber nahezu perfekt. Kleiner Trost: Sie sind ohne Probleme auch für die Verwaltung Linux-basierter Systeme geeignet. (uwo)

01 <body bgcolor=#CCCCFF>
02 
03 <csp:OBJECT NAME=person CLASSNAME=Sample.Person OBJID=#(%request.Get("OBJID"))#>
04 
05 <form NAME=theForm>
06 <table cellspacing=5>
07 <tr>
08 <td>
09 <td>
10 <td>
11 <td>
12 </table>
13 </form>
14 
15 <hr>
16 
17 <csp:IF condition="person=$$$NULLOREF">
18 <I>No object found.</I>
19 </csp:IF>
20 
21 <csp:IF condition="person'=$$$NULLOREF">
22 <table cellspacing=5>
23 <tr>
24 <td>
25 </tr>
26 <tr>
27 <td>
28 </tr>
29 </table>
30 </csp:IF>
31 </body>
32 </html>