2.2.5 Architektur

  In der Grobarchitektur entspricht ConceptBase einem typischen Client/Server--System
[3] (s. z.B. [And91]). Die verschiedenen Applikationen (Toolbar, GraphBrowser, Editor, ...), die die Schnittstelle zum Benutzer bilden, stellen die Klienten dar. Diese Klienten sind jeweils über ein 'Socket' mit dem als Server fungierenden ConceptBase --Kern verbunden. Die Verbindung wird vom ``CB--Interface`` verwaltet, das den Klienten vordefinierte C--Funktionen für Verbindungsaufbau, Datenmanipulation, Anfragen, ... und dem Server die für ProLog aufbereiteten Daten zur Verfügung stellt. Ein Kommando der Applikation wird dem Server übermittelt, dort abgearbeitet, und das Ergebnis wird zur Applikation zurückgesendet. Befehle verschiedener Applikationen werden streng seriell abgearbeitet. Das kann zur Folge haben, daß ein arbeitaufwendiges Kommando viele nachfolgende Befehle (und damit auch die zugehörigen Applikationen) blockiert.

 
Figure:

Durch die Integration des Objektspeichers ändert sich nur wenig an der Architektur. Lediglich die für die Persistenz der Propositionen zuständigen ProLog--Module werden nicht mehr benötigt.

Mehr auf die Einzelheiten eingehende Architekturdiagramme finden sich in verschiedenen Veröffentlichungen [Gal90,Jeu92,JEG93]. Weil es jedoch keine offizielle Darstellung gibt, unterscheiden sich alle Bilder je nach Standpunkt und Zielsetzung des Autors. In dieser Tradition fortfahrend möchte ich hier die für diese Arbeit wichtigen Architekturteile präsentieren.

  Zuerst sei kurz Bild 2.3 beschrieben, in dem die Architekturteile gezeigt werden, die bei einem TELL/UNTELL von Bedeutung sind.
Im Modul IPCChannel befindet sich die Hauptschleife, die auf Nachrichten der Klienten wartet und diese an CBserverinterface zur Verarbeitung weiterreicht. Alle Befehle, die sich nicht sofort befriediegen lassen (also TELL, UNTELL, ASK, HYPO-ASK), werden an Funktionen aus TellAndAsk weitergegeben, das sie mit Hilfe von Prädikaten aus Languageinterface von der 'Frame'-- in die 'SML'--Repräsentation umwandelt. Die SML--Fragmente werden dann vom ObjectProcessor weiterverarbeitet, indem er z.B. bei einem TELL zuerst den ObjectTransformer veranlaßt, sie temporär abzuspeichern, dann die Integrität vom Modul SemanticIntegrity testen läßt und im Erfolgsfall die temporär gespeicherten Propositionen und Regelinformationen unter Aufruf diverser Untermodule permanent macht.

  
Figure 2.3: Teile der Architektur des CB--Kerns bei TELL/UNTELL

Die Aufgaben des ObjectTransformers liegen darin, unter Zuhilfenahme von FragmentToProposition aus den SML--Fragmenten Propositionen zu erzeugen, die FragmentToProposition mit dem STORE Prädikat in Rep_temp temporär ablegt. Wenn dies mit allen SML--Fragmenten geschehen ist, ruft ObjectTransformer erneut FragmentToProposition auf, damit nun alle bisher nur in String--Repräsentation gespeicherten 'Assertions' (Regeln) in ein für ConceptBase verständliches Format umgewandelt werden. Dies geschieht im AssertionCompiler, dessen Interna den ConceptBase --'Freaks' überlassen bleiben sollen.

Änderungen in der Architektur müssen hauptsächlich an zwei Stellen durchgeführt werden: Erstens müssen die obersten Module (Kreis A) an die durch ein Transaktionssystem zusätzlich zur Verfügung stehenden Befehle angepaßt werden. Da alles unterhalb von Linie B durch den Objektspeicher ersetzt wird, erscheint es zweitens sinnvoll, hier die Hauptteile des Transaktionssystems einzufügen, die den Zugriff auf die Propositionen regeln sollen. Wünschenswert ist auch eine direkte Verbindung der beiden Teile, um Informationen wie z.B. die ID der derzeit behandelten Transaktion ohne den Umweg über den ProLog--Teil den Verwaltungsroutinen direkt mitteilen zu können.

Der z.Z. im Anschluß an jedes TELL/UNTELL durchgeführte Integritätstest wird wie gesagt vom Modul SemanticIntegrity durchgeführt. Dies unterscheidet dabei den Test auf Erfüllung der Axiome 13, 14, 15   (teilweise), 16, 3 und 4 von O--Telos (vgl. [JEG93]), der von SMLaxioms ausgeführt wird, und den Test auf Einhaltung der Benutzer--definierten Beschränkungen in BDMIntegrityChecker. Dieser stützt sich auf die diversen BDM--Module ab, die allesamt BDMKBMS zur Speicherung der vorübersetzten Regeln und 'Constraints' benutzen.

Änderungen in diesem Bereich betreffen zum einen das Aufbrechen der festen TELLIntegritätstest--Abfolge in ein TELLAxiomtest, COMMITConstrainttest. Desweiteren muß der Zugriff auf die mittels BDMKBMS gespeicherten Regeln an und für sich genauso überwacht werden, wie die Zugriffe auf Propositionen über PropositionProcessor.