UB BRAUNSCHWEIG
Symbolfoto
  • Impressum
  • Startseite
  • allegro-C von A-Z
  • Druckversion


Schnittstelle Z39.50 für das System allegro

DFG-Gefördertz39.50 Logo

Links zum Thema Z39.50-Protokoll

Eine knapp gehaltene Einführung zum Z39.50-Protokoll finden Sie hier. Weitergehende Informationen findet man auf der Seite Z39.50-Recources. Die Linksammlung enthält sowohl Dokumentationen zum Protokoll und Erfahrungsberichte erfolgreicher Projekte als auch Verweise auf frei verfügbare Software.

Die "offizielle" Dokumentation liegt bei der Library of Congress in Washington.

Z39.50 - Was ist das?

Z39.50 ist die Nummer einer ANSI-Norm und steht für ein standardisiertes Kommunikationsprotokoll zwischen bibliothekarischen Datenbanksystemen (Server oder Target genannt) und den Zugriffsprogrammen (Client oder Origin). Z39.50 erlaubt die weltweite Suche in heterogenen Datenbanken aus der gewohnten lokalen Programmumgebung. Der Einsatz des Protokolls führt zu einer Unabhängigkeit von der Struktur der Datenbank (hierarchisch, relational, ...), der lokalen Abfragesyntax, dem eingesetzten Betriebssystem und der Hardware. Man kann sich das Z39.50-Protokoll als ein Datenbank-Esperanto vorstellen, das es jedem Client ermöglicht, mit jeder Datenbank einen Dialog zu führen.

Wie bei jeder Standardisierung gibt es natürlich Kompromisse. Die Eigenheiten und Vorzüge des lokalen Systems finden im Regelwerk nicht immer eine Entsprechung. Zum Beispiel müssen das Rechercheprogramm und das Target-System sich auf ein Austauschformat einigen. International ist USMARC zumeist das Austauschformat der Wahl. Die Qualität der übertragenen Datensätze hängt dann von der Güte der Umwandlung vom Austausch- zum Lokalformat ab, in unserem Fall also von den Importparametern. Zum Glück können diese anwendungsseitig (ohne C-Programmierung) beliebig ausgebaut werden.

Ein einfacher Z39.50 Dialog

Ein Client teilt dem Z39.50-Server den Kommunikationswunsch in einer Initialisierungsanfrage (Init-Request) mit:

Initialisierung

Der Client übergibt dabei einige Initialisierungsdaten, z.B. die Zugangskennung (Name, Password), die Versionsnummer des Z39.50-Protokolls, die Größe des lokalen Ergebnisspeichers. Der Server ist frei, die Verbindung anzunehmen oder abzulehnen. Steht einer Annahme nichts entgegen sendet der Server dem Client die akzeptierten Werte im Rahmen der Init-Response zurück und teilt ihm gleichzeitig mit, welche Protokolldienste er unterstützt.

Als ersten Dienst möchte der Client nun eine Suchanfrage (Search-Request) übergeben.

Search-Request

Dazu spezifiziert der Client die gewünschte Datenbank oder überläßt die Auswahl dem Server (Datenbankname "default"). Den Kern der Suchanfrage bilden natürlich die gewünschten Suchstrings, verknüpft mit den boolschen Operatoren AND, OR, NOT. Jeder Begriff kann durch Attribute differenziert werden. Die für bibliothekarische Anfragen entwickelte Attributsammlung BIB1nennt 100 Kennzeichen, die den Suchbegriff erklären. Da die allegro-Datenbank normalerweise deutlich weniger Register aufweist, wird nicht jede Anfrage im gewünschten Sinn beantwortet werden können. Das ist jedoch normal: keine Datenbank bedient alle Attribute. Der Verwalter des Z39.50-Servers kann sich bei jedem nicht direkt unterstützten Attribut entscheiden, ob die Anfrage mit einer Fehlermeldung zurückgewiesen wird, oder ob die Suche auf ein verwandtes Register umgelenkt wird. Bei einer erfolgreichen Suche erhält der Client als Antwort die Zahl der gefundenen Datensätze. Der Server speichert die Ergebnismenge temporär. Auf Wunsch liefert der Server auch gleichzeitig ein paar Datensätze. Verbreiteter ist jedoch die Versendung der Sätze im Rahmen eines nachfolgenden Present-Requests.

Present-Request

Der Client übermittelt dabei den Startpunkt und die Anzahl der zu liefernden Datensätze aus der vorher erzeugten Ergebnismenge sowie das gewünschte Austauschformat. Der Server sendet als Antwort die formatierten Datensätze.Die Kommunikation kann in dieser Weise beliebig fortgesetzt werden oder sich auf weitere Dienste ausdehnen. Im Unterschied zu Datenbankabfragen, die über das bekannte HTML-Protokoll abgewickelt werden, besteht bei einem Z39.50-Dialog eine permanente Verbindung zwischen Server und Client. Da der Server alte Ergebnisse bis zum Verbindungsabbruch speichert, kann der Client auf die Resultate zurückgreifen. Mit HTML ist so etwas viel schwieriger zu realisieren.

Ein Verbindungsabbruch wird protokollkonform mit einem Close-Request eingeleitet.

Close-Request

Als Antwort kommt ein Close-Response zurück und der Server löscht die zu der Verbindung gehörenden temporären Dateien. Dies passiert natürlich auch, wenn die Verbindung irregulär abbricht. Der Z39.50-Server kann die Verbindung zu jeder Zeit von sich aus schließen, zum Beispiel, um das System von untätigen Clients zu befreien.

Was tut ein Z39.50-Server?
Server-Struktur

Ein Z39.50-Server hat drei Hauptaufgaben:

  1. Der Server muß die eintreffenden Z39.50-Anfragen dekodieren und in die lokale Datenbanksprache übersetzen. Umgekehrt werden die an den Client verschickten Antworten in die Z39.50-Sprache kodiert. Diese Aufgaben faßt man unter der Protokoll-Funktion zusammen.
  2. Dank einer Auftragsverwaltung kann der Server die Aufträge der gleichzeitig aktiven Clients trennen. Meist soll nicht jedem Client jede Datenbank offenstehen. Die Verwaltung der Datenbanken (Zugriffskontrolle) gehört mit zur Kontroll-Funktion des Servers. Außerdem wird der Server in der Regel die Anfragen der Clients und seine eigene Reaktion protokollieren.
  3. Die Kernfunktion eines Datenbank-Servers ist das Beantworten von Datenbankanfragen. Die Suche in der Datenbank und die Formatierung der gefundenen Sätze faßt man als Datenbank-Funktion zusammen.
Von dieser allgemeinen Gliederung weicht der allegro-Z39.50-Server nur in einem Punkt ab. Als ein externes Programm übernimmt der avanti-Server die Datenbank-Funktion und entlastet gleichzeitig das Target-Modul von der Verwaltung der Datenbanken. Z39.50-Schnittstelle und avanti-Server bilden gemeinsam den allegro Z39.50-Server.
 
ZurückWeiterIndex



[i] zuletzt aktualisiert: 15.04.2011
Email: ub@tu-bs.de