CXI-Basis-Programmierreferenz / Version 2 /

Technischer Überblick

KOMPONENTEN

Das CXI-System besteht aus drei Hauptkomponenten. Jede Komponente baut auf einer oder mehreren der untergeordneten Stufen auf:

Stufe 1: Allgemeine Datenspeicherung
Stufe 2: Allgemeiner Datenaustausch
Stufe 3: Allgemeine Datenverarbeitung

Diese großen Stufen bestehen selbst intern aus mehreren kleineren Stufen und so fort. Die konsequente Konzeption und Programmierung nach diesem hierarchischen Mehrstufenschema bringt viele Vorteile mit sich:

Jede Stufe ist in sich geschlossen. Dies verhindert bei der Programmierung das Kartenhausphänomen: Eine Änderung führt zum Absturz an einer ganz anderen "Ecke" des Programms. Die Unterteilung in kleine abgeschlossene Unterstufen verhindert, dass Programmteile zu groß und unüberschaubar werden.

Jede Stufe ist für sich allein einsetzbar. Dies trifft sogar auf einige der Teilstufen zu. So kann z.B. die Datenspeicherung des CXI-Systems eingesetzt werden, aber eine von CXI unabhängige Verarbeitung erfolgen.

Die Schnittstellen der einzelnen Stufen sind so aufeinander abgestimmt, dass auch bei möglichen Erweiterungen keine Inkompatibilitäten auftreten.

Das gesamte CXI-System basiert auf diesem hierarchischen Mehrstufenkonzept. Die folgenden Abschnitte gehen auf die drei Stufen einzeln ein.

DATENSPEICHERUNG

Was passiert, wenn eine häufig benutzte Funktion um einen oder mehrere Parameter erweitert werden muss? Insbesondere, wenn diese Funktion sich innerhalb einer eigenen Programmdatei (DLL) befindet, ist der Folgeaufwand enorm: Alle beteiligten Programme müssen neu compiliert und gelinkt werden, möglicherweise müssen sogar die Aufrufe der betreffenden Funktion händig angepasst werden. Darüberhinaus muss sichergestellt werden, dass niemals eine alte DLL und ein neues Programm (oder umgekehrt) auf einem Rechner miteinander in Berührung kommen. Sonst sind in der Regel "Allgemeine Schutzverletzungen" oder ähnliche Programmabstürze vorprogrammiert.

Solche Überlegungen (und Erfahrungen) haben zur Grundidee des CXI geführt. Der Lösungsansatz besteht darin, das Konzept 'Namen statt Offsets' anzuwenden. Die festen Strukturen (struct in C), in denen jede Variable einen festgelegten Platz (Offset) hat, werden ersetzt durch allgemeine Datenbehälter, in denen der Zugriff auf die Variablen unabhängig von deren Anzahl und Reihenfolge erfolgen kann.

Die Basis zur Datenspeicherung im CXI-System ist ein allgemeiner Behälter zur Aufnahme von Objekten (oder "Variablen") beliebigen Datentyps:

Binär
Logisch
Zeichen
Zahl
String
Stringliste
Datenzeiger
Funktionszeiger
Spezielle Typen (CXI-intern)
Datenbehälter (geschachtelt)

Die Objekte innerhalb eines Behälters werden über symbolische Namen angesprochen. Beim Eintragen eines Objekts wird dessen Name vom Anwender vergeben. Daneben können anonyme Objekte erstellt werden, die keinen Namen, sondern eine Nummer besitzen.

Zum Zugriff auf Objekte existiert eine große Anzahl von Funktionen in C und C++, z.B.:

zum Erstellen und Löschen von Datenbehältern
zum Eintragen neuer Objekte
zum Kopieren von Objekten
zum Umbenennen von Objekten
zum Ersetzen und Ändern bestehender Objekte
zur Abfrage von Objekteigenschaften (Typ, Größe, ...)
zum Schreiben des Behälters in eine Datei
zum Lesen des Behälters aus einer Datei
zum Umnummerieren anonymer Objekte
Optional automatische Typkonvertierung bei der Abfrage

Aus Sicht des Anwendungsprogramms und des Compilers sind alle Datenbehälter gleichartig, so dass das Hinzufügen oder Löschen von Objekten nicht zu Inkompatibilitäten führen kann. Damit löst CXI das oben genannte Problem: Das Datenbehälterkonzept eignet sich sehr gut als Schnittstelle zwischen Programmen oder Programmteilen, um Versionskonflikte zu vermeiden.

Ein Datenbehälter kann selbst als Objekt in einem Datenbehälter enthalten sein. Dadurch ergibt sich eine Baumstruktur von Behältern (Knoten). Vergleichbar ist dies mit dem Verzeichnisbaum einer Platte. Die Verzeichnisse entsprechen den Behältern, die Dateien den enthaltenen Objekten. Analog zum Dateisystem erfolgt der Zugriff auf solche Baumstrukturen, indem ein Behälter als das aktuelle Sichtfenster des Baums ausgewählt wird. Auf diesen Knoten beziehen sich dann alle Zugriffsfunktionen, sofern nicht explizit ein "Pfad" als Objektname angegeben wird. Im Gegensatz zum zweistufigen Aufbau (Abschnitte und Variablen) der INI-Dateien von Windows und OS/2 ist die Schachtelungstiefe bei CXI-Bäumen also nicht begrenzt.

Zur Verwaltung des Baums existieren weitere Funktionen:

zum Erstellen und Löschen von Knoten im Baum
zum Wechseln des Sichtfensters
zum Sichern und Restaurieren der Position im Baum
zum Zugriff auf Objekte mit und ohne Pfadangaben

Darüberhinaus können Unterbäume wie normale Objekte kopiert, umbenannt etc. werden.

Alle Knoten, die nicht das aktuelle Sichtfenster bilden, werden auf einem Speichermedium zwischengelagert. Hierfür stehen als Medium der Speicher (Heap) und ein externer Datenträger (Datei) zur Auswahl. Dateien können verschlüsselt abgelegt werden. Das Dateiformat ist lediglich von der Rechnerarchitektur (Endian) und vom Zeichensatz (ASCII, EBCDIC, ...) abhängig, nicht jedoch vom verwendeten Betriebssystem (DOS ohne/mit Windows, OS/2, ...) und der Wortbreite des Systems (16 oder 32 Bit). Da Informationen über die Zahldarstellung und den Zeichensatz im Header der Datei gespeichert werden, ist eine automatische Erkennung und Konvertierung möglich.

Es existieren Programme, um das CXI-Dateiformat in ein Textformat und umgekehrt zu konvertieren.

Beispiel eines Baums (Textformat):

     Vorname = "Thomas"
     Nachname = "Meyer"
     Weiblich = FALSE
     Hobbys = "Essen", "Trinken", "Schlafen"
     BEGIN Anschrift
       Strasse = "Große Straße"
       HausNummer = 1
       BEGIN Ort
         Postleitzahl = "62901"
         Ortsname = "Hinterwald"
       END
     END
     BEGIN Telefon
       Vorwahl = "01191"
       Rufnummer = 9123
     END
     BEGIN Freunde
     END
     Alter = 27

Der gleiche Baum in grafischer Darstellung:

Nochmals der gleiche Baum als Sourcecode (C++):

CxiTree t;  // Leeres Objekt anlegen
// Die folgenden Einrückungen entsprechen der Baumstruktur
t.SetVarStr ("Vorname", "Thomas");
t.SetVarStr ("Nachname", "Meyer");
t.SetVarLog ("Weiblich", 0);
t.SetVarLst ("Hobbys");            // Leere Liste erzeugen
t.AppendItem ("Hobbys", "Essen");  // Elemente anhängen
t.AppendItem ("Hobbys", "Trinken");
t.AppendItem ("Hobbys", "Schlafen");
t.MoveDownAuto ("Anschrift");      // Unterbaum erzeugen
  t.SetVarStr ("Strasse", "Große Straße");
  t.SetVarNum ("HausNummer", 1);
  t.MoveDownAuto ("Ort");
    t.SetVarStr ("Postleitzahl", "62901");
    t.SetVarStr ("Ortsname", "Hinterwald");
  t.MoveUp ();
t.MoveUp ();   // Zusammengefasst auch: t.MovePath ("\\");
t.MoveDownAuto ("Telefon");
  t.SetVarStr ("Vorwahl", "01191");
  t.SetVarNum ("Rufnummer", 9123);
t.MoveUp ();
t.MoveDownAuto ("Freunde");
t.MoveUp ();
t.SetVarNum ("Alter", 27);

Oder kürzer (in C++):

CxiTree t =          // Objekt anlegen und initialisieren
  "Vorname=Thomas;Nachname=Meyer;Weiblich=FALSE;"
  "Hobbys='Essen','Trinken','Schlafen';"
  "Anschrift={"
    "Strasse='Große Straße';HausNummer=1;"
    "Ort={Postleitzahl='62901';Ortsname=Hinterwald;};"
  "};"
  "Telefon={Vorwahl='01191';Rufnummer=9123;};"
  "Freunde={};Alter=27;";

In C:

CxiHandle t = cxiCreateCxiTreeMem ();
cxiSetVarsFromString (t,
  "Vorname=Thomas;Nachname=Meyer;Weiblich=FALSE;"
  "Hobbys='Essen','Trinken','Schlafen';"
  "Anschrift={"
    "Strasse='Große Straße';HausNummer=1;"
    "Ort={Postleitzahl='62901';Ortsname=Hinterwald;};"
  "};"
  "Telefon={Vorwahl='01191';Rufnummer=9123;};"
  "Freunde={};Alter=27;", 0);

DATENAUSTAUSCH

Datenaustausch mit CXI kann erfolgen

zwischen Programmteilen innerhalb eines Prozesses
zwischen Prozessen innerhalb einer Betriebssystemumgebung
zwischen Betriebssystemumgebungen (Rechnern)

Der Austausch erfolgt in Form von Meldungen, die von einem Absender verschickt werden und bei einem Empfänger ankommen. Die Daten der Meldung sind in einem Behälter abgelegt (siehe Stufe 1).

Ein Programm, das am Meldungssytem teilhaben möchte, registriert sich beim CXI-System als Empfänger, wobei ein Name mitzugeben ist. Dieser Name dient als Adresse des Empfängers; alle Programme, die diesen Namen kennen, können innerhalb derselben Betriebssystemumgebung an den Empfänger Meldungen schicken.

Zum Absenden einer Meldung ist lediglich ein Funktionsaufruf notwendig, alles andere wird von CXI erledigt. Meldungen können asynchron (Post) und synchron (Send) verschickt werden.

Der Empfänger erhält eine Meldung auf folgende Weise:

Bei Verwendung der C-Funktionsschnittstelle wurde bei der Registrierung des Empfängers die Adresse einer Funktion angegeben. CXI ruft diese Funktion auf und übergibt die empfangene Meldung als Parameter.

In der Klassenschnittstelle für C++ ist ein Empfänger eine Instanz einer Klasse. Beim Empfang einer Meldung wird von CXI eine virtuelle Memberfunktion aufgerufen, wobei auch hier die empfangene Meldung als Parameter mitgegeben wird.

Alle Meldungen an denselben Empfänger werden von CXI in einer Warteschlange (Message Queue) gespeichert, damit die Verarbeitungsfunktion nicht rekursiv aufgerufen wird. Der Empfänger kann einen rekursiven Aufruf jedoch explizit an definierten Stellen erlauben.

Da Prozesskommunikation systemabhängig ist, besteht auch das Meldungssystem aus mehreren Stufen:

(a) systemabhängiges Basissystem
(b) allgemeines lokales Meldungssystem
(c) rechnerübergreifendes Meldungssystem
(d) allgemeines hierarchisches Meldungssystem

Stufe (a) muss für jedes Betriebssystem neu implementiert werden, der Funktionsumfang ist relativ gering. Es können nur einfache nicht geschachtelte Datenbehälter bis zu 16 KB verschickt werden.

Stufe (b) ist systemunabhängig und vervollständigt den Funktionsumfang, so dass beliebig große und verschachtelte Datenbehälter verschickt werden können.

Stufe (c) ist als offene Schnittstelle realisiert. Sie wird von speziellen Meldungsempfängern ("Treibern") gebildet, die Transfers zu anderen Rechnern durchführen können. Das CXI-System klinkt diese Treiber in die eigene Verteilung ein, so dass rechnerübergreifender Datenaustausch möglich wird. Auf die gleiche Art und Weise ist ein Transfer zwischen verschiedenen Betriebssystemumgebungen eines Rechners (z.B. OS/2 <--> DOS-Box) möglich. Kommunikationstreiber für NETBIOS und einige weitere Protokolle wurden bereits erfolgreich getestet (siehe "Verbindungsmanager"). Diese Stufe beinhaltet die automatische Konvertierung versendeter Daten zwischen verschiedenen Rechnerarchitekturen. Zeichensatz und Zahldarstellung werden automatisch angepasst. Der folgende Abschnitt beschäftigt sich näher mit der Globalisierung des Meldungssystems.

Stufe (d) ist weitgehend fertig gestellt. Alle Meldungsempfänger (interne und externe) werden in eine Baumstruktur eingeordnet. Dadurch ist es möglich, lokale Namensräume zu schaffen und die Anwendungsprogramme von der Unterscheidung interner und externer Meldungen zu entlasten.

Das CXI-Meldungssystem ist unabhängig vom Meldungssystem grafischer Oberflächen wie Windows für DOS und Presentation Manager (PM) für OS/2. Es kann zwischen beliebigen Programmen eingesetzt werden.

Das gesamte CXI-System ist nicht an bestimmte Programmiersprachen oder Compilerhersteller gebunden, Datenaustausch ist auch zwischen Programmen möglich, die in verschiedenen Sprachen (momentan sind dies C und C++) entwickelt oder von verschiedenen Compilern erstellt wurden (getestet wurden Borland C/C++ 3.1 bis 5.0 für DOS/Windows, Borland C/C++ 1.x und 2.0 für OS/2, Watcom C/C++ 10.x, Microsoft Visual C++ 1.5). Da nur die allgemein übliche Aufrufkonvention des jeweiligen Systems benutzt wird, sollte es auch mit anderen Compilern oder Sprachen keine Probleme geben. Sogar eine Verwendung in Assemblerprogrammen ist denkbar.

Für Windows und OS/2 steht ein Trace-Programm zur Verfügung, das alle oder ausgewählte Meldungen protokolliert. Es kann somit zum Debugging oder zur Kontrolle eingesetzt werden.

Es folgt ein kleines Beispielprogramm in C++, das demonstriert, wie einfach mit CXI Datenaustausch realisiert werden kann. Das obligatorische "Hello, world!" darf bei CXI natürlich nicht fehlen.

// ************ Der Empfänger ************

#include <stdio.h>
#include "cxi.h"


// Empfänger sind Ableitungen der CXI-Basisklasse:

class TestReceiver : public CxiMessageHandlerWithQueue
{
public:
  TestReceiver (const char *name)
    : CxiMessageHandlerWithQueue (name) {}
protected:
  virtual long int Handler2 (CxiTree& p, CxiNode& e);
};


// Handler2 wird aufgerufen, wenn eine Meldung ankommt:

long int TestReceiver::Handler2 (CxiTree& p, CxiNode& e)
{
  // p enthält die Daten der Meldung;
  // e enthält Zusatzinformationen, z.B. den Namen des Absen-
  //   ders, wenn dieser ebenfalls Meldungen empfangen kann.
  const char *text = p.GetItem ("TEXT");  // Variable auslesen
  if (text)
    printf ("%s\n", text);                // ausgeben
  return 0;
}


// Eine Instanz mit dem Namen "TESTREC" anlegen

TestReceiver trec = "TESTREC";


// ************ Der Absender ************
// Absender und Empfänger müssen sich nicht im gleichen Pro-
// gramm befinden, sondern lediglich gleichzeitig aktiv sein.

#include "cxi.h"


int main (int argc, char **argv)
{
  CxiTree Message;                             // Meldung
  Message.SetVarStr ("TEXT", "Hello, world!"); //  erstellen
  PostMessageTree (Message, "TESTREC");        //  verschicken

  // ... sonstige Verarbeitung ...
  return 0;
}

GLOBALISIERUNG

Das von der CXI-Basis zur Verfügung gestellte Meldungssystem unterstützt direkt nur solche Meldungen, die an einen auf dem lokalen Rechner vorhandenen Empfänger geschickt und von diesem verarbeitet werden. Es ist nicht unmittelbar möglich, einen auf einem anderen Rechner oder in einer anderen Systemumgebung (DOS-Box) registrierten Meldungsempfänger anzusprechen.

Daher existieren verschiedene Möglichkeiten zur Erweiterung der Funktionalität des lokalen CXI-Meldungssystems. Das Basissystem stellt hierzu Schnittstellen in Form spezieller Empfänger und Hilfsfunktionen zur Verfügung. Die folgenden Abschnitte beschreiben die aktuell verfügbaren Erweiterungen.

Default-Handler

Kann das System eine Meldung nicht zustellen, weil der Empfänger nicht existiert, geht die Meldung normalerweise verloren, der Absender erhält einen Fehlercode.

Wird jedoch ein Empfänger mit dem speziellen Namen "@DEFAULT" definiert, so leitet CXI alle unzustellbaren Meldungen an diesen Default-Handler weiter. Damit ist es möglich,

(a) Empfänger dynamisch nachzuladen (load on call): Der feh- lende Handler wird geladen und registriert, danach die Meldung weitergeleitet.

(b) eine eigene Fehlerdiagnose zu betreiben. Es kann zum Beispiel ein Fehlertrace geschrieben werden und/oder eine Nachricht an den Absender zurückgesandt werden.

Globale Queue

Optional kann CXI angewiesen werden, alle Meldungen über eine einzige globale Warteschlange zu verwalten. Dadurch ist immer nur eine Meldung in Bearbeitung, Rekursionen und ungewollte Parallelverarbeitungen werden damit vermieden.

Die globale Queue stellt jedoch einen Flaschenhals dar, diese Option wird daher standardmäßig nicht verwendet.

Pfadangaben

Anstelle eines einfachen Empfängernamens kann vom Absender ein Pfad angegeben werden. Dieser Pfad besteht aus einzelnen Namen, die durch \ getrennt sind.

Das Meldungssystem verwendet nur die erste Komponente des Pfades als Adresse eines "Verteilers", an diesen Namen wird die Meldung geschickt. Die weiteren Teile des Pfades werden unverändert an den Empfänger (Verteiler) übermittelt.

Ein Verteiler ist technisch gesehen ein normaler Empfänger. Er unterscheidet sich von anderen Handlern nur dadurch, dass die Meldungen, die bei ihm eintreffen, in der Regel nicht direkt für den Verteiler bestimmt sind.

Die Bestimmung einer Meldung ist in den weiteren Komponenten des Empfängernamens angegeben. Der Verteiler kann diese Angaben auswerten und die Meldung entsprechend weiterleiten. Verteiler sind daher in der Regel nur Durchgangsstationen einer Meldung.

Beispiel: Meldung an V1\V2\R3

Schritt 1: Der Verteiler V1 erhält die Meldung, der Name für die Weiterleitung ist V2\R3. V1 schickt die Daten an V2\R3.

Schritt 2: Der Verteiler V2 erhält die Meldung, der Name für die Weiterleitung ist R3. V1 schickt die Daten an R3.

Schritt 3: Der Empfänger R3 erhält die Meldung, der Name für die Weiterleitung ist leer. R3 verarbeitet die Meldung.

Das Verteilerkonzept ist dann sinnvoll, wenn Weiterleitungen von Meldungen über andere Wege als das CXI-Meldungssystem erfolgen sollen oder müssen.

Meldungstreiber

Ein Meldungstreiber ist ein Sonderfall eines Verteilers. Die Weiterleitung der Meldung besteht in deren Übertragung auf eine andere Betriebssystemumgebung oder einen anderen Computer.

Dort angekommen, wird die Meldung dann anhand der Weiterleitungsinformation (die nächsten Pfadkomponenten) weitergeleitet.

Der Treiber selbst repräsentiert somit innerhalb des lokalen Meldungssystems den fremden Computer. Die Namen solcher Treiber sind daher in der Regel identisch mit den Namen der Rechner.

Beispiel: Meldung an R1\R2\R3

Schritt 1: Der Verteiler R1 auf dem lokalen Rechner erhält die Meldung. Die Daten der Meldung und der Name für die Weiterleitung (R2\R3) werden an den Computer R1 übertragen. Das Programm dort schickt die Daten an R2\R3.

Schritt 2: Der Verteiler R2 auf dem Rechner R1 erhält die Meldung. Die Daten der Meldung und der Name für die Weiterleitung (R3) werden an den Computer R2 übertragen. Das Programm dort schickt die Daten an R3.

Schritt 3: Der Empfänger R3 auf dem Rechner R2 erhält die Meldung, der Name für die Weiterleitung ist leer. R3 verarbeitet die Meldung.

Das Basissystem unterstützt Meldungstreiber bei ihrer Arbeit, indem es auf Wunsch das Übertragungsprotokoll übernimmt:

Aufteilung der Baumstruktur der Meldung in eine Folge von binären Datenblöcken auf der Senderseite; diese Blöcke enthalten alle relevanten Daten, die die Weiterverteilung auf der Empfängerseite benötigt

Sammeln, Überprüfen und Zusammenfügen der empfangenen binären Blöcke zu einer Baumstruktur auf Empfängerseite und automatische Weiterleitung vollständig empfangener Meldungen an die (jeweils als nächste Pfadkomponente) angegebenen Empfänger

Konvertierungen, falls eine Übertragung zwischen verschiedenen Rechnertypen oder Systemen stattfindet: Zahldarstellung (little oder big endian), Zeichensatz (ASCII, EBCDIC, ...), Codepage (437/850/858 DOS+OS/2, 1252 Windows, ...)

In diesem Fall muss der Treiber nur noch Routinen zur Übertragung von Binärdatenblöcken enthalten.

Aliasnamen

Häufig ist es sinnvoll, die Adresse einer Meldung nicht fest vorzugeben, sondern dynamische Änderungen zuzulassen. Um nicht an jeder Stelle, wo Meldungen verschickt werden, erst die aktuelle Adresse feststellen zu müssen, erlaubt CXI die Definition von Aliasnamen. Dies ist vergleichbar mit den Kurzwahlen einer Telefonanlage.

Der Absender schickt seine Daten immer an den gleichen Empfängernamen, CXI setzt diesen dann anhand der definierten Aliaszuordnungen um.

Ein Aliaszuordnung kann folgende Werte annehmen:

Name eines anderen Alias (geschachtelter Alias)
Name eines Meldungsempfängers
Pfadangabe

Wird eine Meldung verschickt, so geht das CXI-System folgendermaßen vor: Ist der Empfängername der Name eines Alias, wird er durch den Wert dieses Alias ersetzt. Dieser Schritt wird sooft wiederholt, bis der Empfängername bzw. die erste Komponente des Empfängernamens kein Aliasname mehr ist. Danach folgt die normale Verarbeitung.

Die Alias-Ersetzung erfolgt immer bezogen auf die erste Komponente des Namens. Eine Pfadangabe (z.B. "R2\M1") wird daher umgesetzt, wenn ein Alias für den ersten Namensteil ("R2") existiert. Weitere Namensteile bleiben unberührt. Es ist möglich und sinnvoll, mit einem Alias einen einfachen Namen in eine Pfadangabe umzusetzen, zum Beispiel:

R0 -> SERVER\VERTEILER
R1 -> SERVER\RECHNER1
R2 -> R0\RECHNER2\R1

In obigem Beispiel wird hierdurch eine Meldung, die an R2\M1 adressiert wird, tatsächlich an SERVER\VERTEILER\RECHNER2\R1\M1 geschickt:

  R2\M1  ->  R0\RECHNER2\R1\M1
  --         --------------

  R0\RECHNER2\R1\M1  ->  SERVER\VERTEILER\RECHNER2\R1\M1
  --                     ----------------

SERVER ist kein Alias, also endet die Umsetzung.

Die Umsetzung der Aliasnamen erfolgt erst beim Verschicken einer Meldung. Daher ist es nicht notwendig, dass der tatsächliche Empfänger vor dem Alias registriert wird.

Verbindungsmanager

Alle bisher genannten Erweiterungen können durch ein spezielles Programm dynamisch verwaltet werden, um das Anwendungsprogramm von diesen Kommunikationsaufgaben zu entlasten.

Dieser Verbindungsmanager besteht aus folgenden Komponenten:

Urlader/Watchdog
Ladeprogramm
Protokollmanager
Kommunikationstreiber

Das Urladeprogramm (LOADxxx.EXE) ist die einzige Komponente, die direkt vom Anwender bzw. dem Anwendungsprogramm gestartet wird. Die einzige Aufgabe besteht darin, das Ladeprogramm zu starten und zu überwachen. Hierdurch ist ein automatischer Neustart des Verbindungsmanagers möglich, wenn ein Fehler auf anderem Wege nicht behebbar ist. Außerdem kann so ein Update von CXI-Komponenten durchgeführt werden, da der Urlader keine weitere Datei (DLL) benötigt. Der Urlader entkoppelt das Anwendungsverzeichnis vom Startverzeichnis des Ladeprogramms, das sich daher auch z.B. auf einem mehrfach benutzten Netzlaufwerk befinden kann. Nur die lokalen Konfigurationsdaten (CXI.INI) müssen sich in einem privaten Verzeichnis befinden.

Das Ladeprogramm (CXIBxLDS.DLL und ggf. CXIBxLDR.DLL) lädt alle im [LOAD]-Abschnitt der Datei CXI.INI angegebenen Programme und Treiber. Es stellt außerdem ein Ein-/Ausgabemedium zur Verfügung, je nach System ist dies der gesamte Bildschirm, ein Konsolenfenster oder ein Windows-Dialogfenster.

Eines der geladenen Programme ist der Protokollmanager (CXICxSHL.DLL). Er enthält die wesentlichen Komponenten des Verbindungsmanagers:

Verwaltung der Konfiguration (Rechnernamen, Verbindungen)
Router (sucht Wege zu nicht direkt verbundenen Rechnern)
Generischer Meldungstreiber für alle angebundenen Rechner
Transferkomponente zur Dateiübertragung
Queue zur Zwischenspeicherung von Meldungen
Interaktive Kommandoauswertung (CXI SHELL)

Der generische Meldungstreiber ist ein Stellvertreter für die angebundenen Rechner. Er verwaltet und steuert die je nach Konfiguration unterschiedlichen Kommunikationstreiber. Die folgenden Aufgaben werden automatisch ausgeführt:

Laden und Entladen des Kommunikationstreibers
Aufbau und Abbau der physikalischen Verbindung
Anmelden und Abmelden der logischen Verbindung
Übertragung der Nutzdaten mit Prüfsumme
Blockwiederholung, falls ein Fehler aufgetreten ist

Geplant ist die Anbindung fremder Meldungssysteme an CXI:

Übernahme von Meldungen des fremden Systems nach CXI
Übergabe von Meldungen von CXI an das fremde System

Insbesondere interessant in diesem Zusammenhang ist eine Einbindung über die MAPI-Schnittstelle oder über eMAIL.

Anwendungsschnittstellen für Sonderfälle der Kommunikation sind in Form von DLLs verfügbar.

DATENVERARBEITUNG

Die Datenverarbeitung unter Verwendung von CXI kann bereits mit den beschriebenen Mitteln (Datenspeicherung und -austausch) erfolgen. CXI bietet zusätzlich ein neues Programmierkonzept, das durch eine meldungsorientierte Denkweise eine Verallgemeinerung der Datenverarbeitung ermöglicht. Die einzelnen Teilaspekte sind voneinander unabhängig nutzbar. Realisiert sind eine auf C++ basierende Makrosprache und die Dienstleistungsknoten.

Mit Hilfe der Makrosprache werden NODEs (Knoten) definiert, die Meldungen entgegennehmen und verarbeiten; diese Knoten werden durch ihre Namen identifiziert (siehe vorangehender Abschnitt). Die NODEs können anderen namentlich bekannten NODEs beliebige Daten als Meldungen schicken. Ein Programm besteht aus vielen solchen Knoten, die ausschließlich per Meldungen kommunizieren. Dadurch ist es möglich, die einzelnen NODEs eines Programms beliebig auf mehrere Rechner zu verteilen, ohne dass - wie bei herkömmlichen Programmen - Probleme beim Zugriff auf globale Daten entstehen. In dieser Makrosprache lässt sich die Empfängerseite des vorangegangenen Beispiels kurz so formulieren:

NODE TESTREC
  DEFAULT   // Hier könnte nach Aktionen unterschieden werden
    const char *text = REQUEST.GetItem ("TEXT");
    if (text)
      printf ("%s\n", text);
ENDNODE

Eine weitere Eigenschaft des Programmierkonzepts sind Dienstleistungsknoten, die den Standardfunktionen einer normalen Programmiersprache entsprechen. Solche Knoten stellen bestimmte Fähigkeiten allgemein zur Verfügung, z.B. Dateiverwaltung, Oberflächensteuerung, Systemverwaltung, Laden benötigter Knoten etc. Jederzeit können weitere derartige Knoten hinzugefügt werden.

In Planung sind Hilfsmittel zur Automatisierung der Verteilung von Aufgaben auf mehrere Knoten, die sich auch auf verschiedenen Rechnern befinden können. Die Abbildung zeigt eine Beispielkonfiguration, in der von einem Knoten Daten an drei Rechner verteilt werden. Diese schicken nach der Verarbeitung ihre Ergebnisse an einen zentralen Ausgabeknoten.

DOKUMENTATION

Alle Klassen, Funktionen und Fehlernummern des CXI-Systems sind in einer ausführlichen Dokumentation beschrieben. Sie steht im HTML-Format und als Online-Hilfe für OS/2 (INF-Datei), Windows (HLP-Datei) und DOS (EXE-Datei) zur Verfügung.

Die Online-Dokumentationen enthalten besonders gekennzeichnete Verweise auf andere Themen (Hyperlinks). Diese Textstellen können ausgewählt werden, und so kann direkt in den entsprechenden Hilfetext verzweigt werden.

Sie haben ein Anzeigeprogramm vor sich, das Hyperlinks unterstützt. Wählen Sie das folgende hervorgehobene Wort aus, um die Hilfe zu "GetItem" zu erhalten. Diese Funktion wird im obigen Beispielprogramm "Hello, world!" verwendet.

TECHNISCHE DATEN

Interne Daten:

Maximale Größe eines Behälters
64 KB für Einzelbehälter (16-Bit-Systeme: DOS, Win16)
16 MB für Einzelbehälter (32-Bit-Systeme: OS/2, Win32)
64 KB für Knoten innerhalb von Bäumen (alle Systeme)

Objektnamen
Länge 1 bis 255 Zeichen
Groß- und Kleinschreibung wird beibehalten
Groß- und Kleinschreibung ist nicht relevant für Vergleiche
Zulässige Zeichen wie in Dateinamen

Maximale Anzahl der Meldungsempfänger
ist abhängig von der Länge der Empfängernamen, Faustregel: Speicherbedarf eines Empfängers = Länge des Namens + 32
bis zu 64 KB (dynamisch) unter DOS
ca. 32 KB (statisch) unter Win16, OS/2 und Win32

Verfügbarkeit:

Betriebssysteme
DOS
Win16 (DOS + Windows 3.1)
Win32 (Windows NT und Windows 95)
OS/2

Formate
Statische LIB für Borland-Linker (DOS)
DLL für LOADDOS
16-Bit-DLL für Win16
32-Bit-DLL für Win32
32-Bit-DLL für OS/2

Compiler/Linker
Borland C/C++ 3.1 und 4.x für DOS/Win16
Borland C/C++ 5.0 für Win32
Borland C/C++ 1.x und 2.0 für OS/2
Watcom C/C++ 10.x für DOS/Win16, Win32 und OS/2
Microsoft Visual C++ 1.5 für Win16

Programmiersprachen
C (Funktionsschnittstelle)
C++ (Klassenschnittstelle und Makrosprache)

Dokumentation
auf Papier
Online für OS/2 PM (INF-Format)
Online für Windows (HLP-Format)

Stand: Version 2.07 vom Januar 1997
Änderungen vorbehalten

J.N. 1997