ProjectD/Software/BCE

Die frühere Benzing Communication Engine wurde später zum Projekt der Better Communication Engine und soll das Beste aus vielen verbreiteten Kommunikationsprogrammen und natürlich weniger Nachteile als diese bieten.

Designpremissen

• Verfügbarkeit unter Win32 und Unix-Derivaten
• Programmiersprache "C"
• Aufteilung der Teilprozesse (Aufgaben) auf mehrere eigenständige, miteinander kommunizierende Prozesse:
  • Kommunikation
  • Konfiguration
  • (Stamm-)Datenhaltung
  • Datenaustausch mit Hostsystem(en)
• Konfiguration mittels einfacher, kommentierbarer Textdateien
• Kommunikation der Prozesse untereinander über TCP/IP-Sockets, ev. auch lokal über Unix-Domain-Sockets (wenn auch unter WIn32 verfügbar)
• Kommunikation mit KABA-Terminals von uralt (BT9xx) bis aktuell (B-Net, FTP etc)
• Prinzipell offen für Kommunikation auch mit anderen Geräten,
• Wenn möglich Anbindung auch an Mobil-Data Commserver
• Hostanbindungen:
  • SAP
  • dpw, IIG, BMD (BConnect-CSV)
• Eingebauter HTTP-Server für Statusabfragen etc
• Eingebauter CLI-Port (Command Line Interface, Telnet)
• Alle (Netzwerks-)Kommunikationsfunktionen mit select() und timeouts
• Kommandos zwischen den Prozessen untereinander in FTP/SMTP-Ähnlichem Klartext-Protokoll
• Automatischen Anmelden und Parametrieren (inkl ftp-download) von neuen Terminals
• Terminal-Features (Unterschiede in Parameter-Features) konfigurierbar
• Mehrere Terminals mit gleicher BPA-Adresse (an unterschiedlichen IP-Adressen) möglich
• Terminals über NAT-Router-Zugang möglich
• Server hinter NAT möglich

Architektur

Konfiguration

Die Konfiguration der Programm-Komponenten erfolgt mittels Konfigurationsdaten als lesbare Textdateien. Diese Dateien haben eine einfache und klare Syntax, sind leicht per Mail zu versenden und ggf. auch ausdruckbar und auch als Ausdruck verständlich.

Es können sowohl verschiedene, getrennte Konfigurationsdateien für verschiedene Komponenten angelegt werden, insbesondere, wenn diese auf verschiedenen Rechnern installiert sind, als auch ist es möglich, einige oder alle Komponenten auf dieselbe Konfigurationsdaten (auf einem Rechner) zugreifen zu lassen oder sogar die Konfigurationsdatei über die Standard-TCP/IP-Kanäle, über die die Komponenten soundso miteinander kommunizieren, zu replizieren !

Das generelle Format der Konfigurationsdateien entspricht dem Project:D-Standard, d.h.:

• Zeilensequentielle
• leerzeilen werden ignoriert
• Zeilen, die mit '#' beginnen, sind Kommentar und werden ignoriert
• Der Zeileninhalt ab '#' ist Kommentar, ausser, das Zeichen kommt in einem gequoteten String vor
• Die Konfigurationsdatei ist in "Sektionen" unterteilt, welche durch 'Sektionsname:' gekennzeichnet sind
• Wertezuweisungen haben das Format "ParameterName = Wert"

Ein Beispiel:

# --------------------------------- #
#    Das ist eine Beispiel-
#    Konfigrurationsdatei
# --------------------------------- #
Protocol:
   LogFile  = Log/%P.%d
   LogLevel = 5
BCEConfAgent:
   LogLevel = 9

In diesem Beispiel sieht man Kommentare zur leichteren Interpretation durch den Menschen. Parameter-Wertezuweisungen können mehrfach vorkommen; ausschlaggebend ist, in welcher Sektion das Programm nach dem Parameter sucht !

Das Beispiel zeigt auch, daß alle Komponenten zunächst nach globalen Vorgaben suchen, das wäre in diesem Beispiel die Protokolldatei- und Loglevel-Zuweisung in der "Protocol"-Sektion. Danach wird nach spezifischen Übersteuerungen gesucht - im Beispiel würde der ConfAgent mit höherem Debuglevel betrieben werden als die anderen Komponenten.

Nomenklatur

Folgende Komponenten sind derzeit definiert:

BCECommAgent

Der oder die Instanzen, die Kommunikation mit den Hardware-Komponenten betreiben.

Diese Komponenten kann mehrfach vorkommen, insbesondere:

• Wenn Kommunikations-Protokoll verschiedener Hersteller im gleichen System verwendet werden sollen
• Wenn aus Lastverteilungs- oder Zuverlässigkeitsgründen die Kommunikation über mehrere Prozesse abgehandelt werden soll.
• Wenn die Kommunikation aus netzwerkstechnischen oder Performance-Gründen von verschiedenen Rechnern aus abgehandelt werden soll (z.b. ein Kommunikations-Rechner pro Standort, damit das Netzwerks-Protokoll der Hardware nicht zwischen den Standorten geroutet werden muß)
• Wenn Test- und Produktivinstanzen getrenn voneinander betrieben werden sollen.

BCEConfAgent

Diejenige Komponente, welche Konfigurationsdaten für das Gesamtsystem hält.

Diese Komponente kommt nur ein einziges Mal vor, ausser, wenn Test- und Produktivinstanzen getrennt betrieben werden sollen.

BCEDataAgent

Diejenige Komponente, welche Stamm- und Bewegungsdaten des Systems hält.

Je nach Systemauf- und -ausbau können dies "Flat Files" bis zum Interface zu "grossen" Datenbanken sein.

Diese Komponente kommt nur ein einziges Mal vor.

BCEXchgAgent

Diejenigen Komponenten, welche den Datenaustausch mit über- oder nachgeordneten Systemen führen.

Sourcecode-Architektur

Der Software-Quellcode ist folgendermassen aufgeteilt:

Kommandos

Sowohl die Programm-Komponenten untereinander als auch "menschliche" Benutzer benutzen das selbe CLI (=Command Line Interface) Interface über TCP/IP-Sockets.

Folgende Kommandos werden über diese Schnittstelle verstanden:

Kommando	Bedeutung
QUIT	Verbindung beenden (NICHT beenden des Daemons!)
EXIT	Verbindung beenden (NICHT beenden des Daemons!)
HELP	Mögliche Kommandos ausgeben
?	Mögliche Kommandos ausgeben
CLIENTS	Client-Verbindungen anzeigen
LOGIN	Interaktiver Login (als Mensch identifizieren)
LOGOUT	Interaktiven Login beenden