DE69032191T2

DE69032191T2 - Anordnung und Verfahren zur Realisierung von Hochleistungskommunikation zwischen Softwareprozessen

Info

Publication number: DE69032191T2
Application number: DE69032191T
Authority: DE
Inventors: Mark Bowles; Marion Dale Skeen
Original assignee: Teknekron Software Systems Inc
Current assignee: Refinitiv Ltd
Priority date: 1989-07-27
Filing date: 1990-01-19
Publication date: 1998-11-05
Anticipated expiration: 2010-01-20
Also published as: DE69032191D1; AU5867190A; EP0412232B1; AU636152B2; CA2001621C; AU5249396A; US5187787B1; EP0412232A2; AU677555B2; US5187787A; ATE164695T1; EP0412232A3; AU4213393A; CA2001621A1; JPH03148739A

Description

HINTERGRUND DER ERFINDUNG

Die Erfindung gehört in den Bereich des entkoppelten Informationsaustausches zwischen Software-Prozessen, die auf unterschiedlichen Computern oder sogar auf dem selben Computer laufen, wobei die Software-Prozesse unterschiedliche Formate für die Datendarstellung und Datenorganisation verwenden können oder die selben Formate und dieselbe Organisation verwenden können, wobei aber die Formate und die Organisation später geändert werden können, ohne daß eine Neuprogrammierung erforderlich wäre. Auch verwenden die Software-Prozesse "semantische" Informationen oder Feldnameninformationen auf derartige Weise, daß jeder Prozeß Daten verstehen und verwenden kann, die er von irgendeinem fremden Software-Prozeß erhalten hat, und zwar unabhängig von den semantischen Unterschieden oder den Feldnamenunterschieden. Die semantischen Informationen sind von den Informationen über die Datendarstellung und die Datenorganisation entkoppelt.
Mit der Verbreitung unterschiedlicher Arten von Computern und Software-Programmen und der ständigen Anforderung an unterschiedliche Computertypen, auf denen unterschiedliche Software-Programme laufen, Daten miteinander auszutauschen, ist ein Bedarf an einem System entstanden, durch welches ein derartiger Datenaustausch durchgeführt werden kann. Typischerweise gehören zu Daten, die zwischen Software-Modulen ausgetauscht werden müssen, die einander fremd sind, Text, Daten und Graphiken. Gelegentlich besteht jedoch auch der Bedarf, digitalisierte Sprachdaten oder digitalisierte Bilddaten oder andere, exotischere Informationsformen auszutauschen. Diese unterschiedlichen Datentypen werden als "Primitive" bezeichnet. Ein Software-Programm kann nur jene Primitiven bearbeiten, die zu verstehen und zu bearbeiten es programmiert ist. Werden andere Arten von Primitiven als Daten in ein Software-Programm eingeführt, verursacht dies Fehler.
Mit dem in diesem Zusammenhang verwendeten Begriff "fremd" ist hierin gemeint, daß die beim Austausch involvierten Software-Module oder Host-Computer "unterschiedliche Sprachen sprechen". Zum Beispiel verwenden die in Personal-Computern und Workstations häufig verwendeten Mikroprozessoren von Motorola und Intel insoferne unterschiedliche Arten der Datendarstellung, als daß in einer Mikroprozessorfamihe das wichtigste Byte in aus mehreren Bytes bestehenden Wörtern an die erste Stelle gesetzt wird, während in der anderen Prozessorfamihe das wichtigste Byte an die letzte Stelle gestellt wird. Des weiteren werden Textbuchstaben in IBM-Computern mit dem EBCDIC-Code codiert, während in nahezu allen anderen Computern Textbuchstaben mit dem ASCII-Code codiert werden. Auch gibt es mehrere unterschiedliche Arten, Zahlen darzustellen, einschließlich Ganzzahlen, Fließkommazahlen usw. Des weiteren verwenden fremde Software-Module unterschiedliche Arten der Datenorganisation sowie unterschiedliche semantische Informationen, d.h., wie die einzelnen Felder in einem Datensatz bezeichnet werden und was die Bezeichnungen bedeuten.
Die Verwendung dieser unterschiedlichen Formate für die Darstellung und Organisation von Daten bedeutet, daß Übersetzungen entweder in eine allgemeine Sprache ader von der Sprache des einen Computers oder Prozesses in die Sprache eines anderen Computers oder Prozessors durchgeführt werden müssen, bevor eine sinnvolle Kommunikation möglich ist. Des weiteren befinden sich viele Software-Module, zwischen denen eine Kommunikation stattfinden soll, auf unterschiedlichen Computern, die örtlich voneinander getrennt und nur über lokale Datennetze, Weitverkehrsnetze, Gateways, Satelliten usw. miteinander verbunden sind. Diese unterschiedlichen Netzwerke besitzen ihre eigenen, sehr unterschiedlichen Protokolle für die Kommunikation. Auch ist es, zumindest in der Welt der Finanzdienste, so, daß verschiedene Rohdatenguellen, wie zum Beispiel Dow Jones News oder Telerate , unterschiedliche Datenformate und Kommunikationsprotokolle verwenden, die verstanden und befolgt werden müssen, um Daten von diesen Quellen empfangen zu können.
Bei komplexen Datensituationen, wie zum Beispiel bei Finanzdaten hinsichtlich Aktien, Anleihen, Geldmärkten, usw., ist es oft nützlich, die Daten zu verschachteln. Das heißt, Daten bezüglich eines bestimmten Gegenstandes werden oft als Datensatz mit mehreren "Feldern" organisiert, wobei jedes Feld einem unterschiedlichen Aspekt des Gegenstandes zugeordnet ist. Es ist oft nützlich, wenn ein bestimmtes Feld Unterfelder haben kann, und ein bestimmtes Unterfeld seine eigenen Unterfelder haben kann und so weiter, wie viele Ebenen dabei auch immer notwendig sein mögen. Zum Zwecke der hierin enthaltenen Diskussion wird diese Art der Datenorganisation als "verschachtelung" bezeichnet. Zum Zwecke der hierin enthaltenen Diskussion werden die Feldnamen und deren Bedeutung im Hinblick auf den Gegenstand als "semantische Informationen" bezeichnet. Die eigentliche Datendarstellung für ein bestimmtes Feld, wie z.B. Fließkommazahlen, Ganzzahlen, alphanumerische Zeichen, usw., sowie die Organisation des Dateneintrags im Hinblick darauf, wie viele Felder er besitzt, welche Felder Primitiv-Felder sind, welche Felder nur Daten enthalten, und welche Felder verschachtelte Felder sind, die Unterfelder enthalten, wird zum Zwecke der hierin enthaltenen Diskussion als "Format-" oder "typ"-Information bezeichnet. Ein Feld, das nur Daten enthält (und keine verschachtelten Unterfelder besitzt), wird als ein "primitives Feld" bezeichnet, und ein Feld, das andere Felder enthält, wird hierin als ein "konstruiertes Feld" bezeichnet.
Es gibt zwei grundlegende Operationsarten, die beim Austausch von Daten zwischen Software-Modulen auftreten können. Die erste Operationsart wird als "Formatoperation" bezeichnet und umfaßt die Umwandlung des Formats eines Datensatzes (im folgenden können Datensätze auch manchmal als " ein Formular" bezeichnet werden) in ein anderes Format. Ein Beispiel einer solchen Formatoperation wäre die Umwandlung von Datensätzen mit Fließkomma- und EBCDIC-Feldern in Datensätze mit gepackter Darstellung, wie sie für die Übertragung über ein lokales ETHERNET -Datennetz benötigt werden. Am empfangenden Prozeßende kann eine weitere Formatoperation für die Umwandlung des ETHERNET -Paketformats in Ganzzahlen- und ASCII-Felder am empfangenden Prozeß oder Software-Modul durchgeführt werden. Eine weitere Operationsart wird im folgenden als "semantikabhängige Operation" bezeichnet, weil sie Zugriff auf die semantischen Informationen sowie auf die Typ- oder Formatinformationen über ein Formular erfordert, um Arbeiten am Formular ausführen zu können, wie z.B. um ein bestimmtes Feld dieses Formulars, z.B. den aktuellen Aktienkurs von IBM oder den gestrigen Tiefststand von IBM, an ein Software-Modul zu liefern, das diese Informationen anfordert.
Weiter gibt es in der heutigen Umgebung oft zahlreiche Quellen unterschiedlicher Datentypen und/oder zahlreiche Quellen desselben Datentyps, wobei sich die Quellen abdeckend überlappen, aber unterschiedliche Formate und unterschiedliche Kommunikationsprotokolle verwenden (oder sich sogar mit demselben Format und demselben Kommunikationsprotokoll überlappen). Es ist von Vorteil, wenn ein Software-Modul (Software-Module können im folgenden manchmal als "Anwendungen" bezeichnet werden) in der Lage sind, Informationen bezüglich eines bestimmten Gegenstandes zu erhalten, ohne die Netzwerkadresse des Dienstes zu kennen, der die Informationen dieser Art zur Verfügung stellt, und ohne die Einzelheiten des bestimmten Kommunikationsprotokolls zu kennen, das zur Kommunikation mit dieser Informationsquelle benötigt wird.
Es ist daher ein Bedarf an einem Kommunikationssystem entstanden, welches eine Schnittstelle zwischen unterschiedlichen Software-Modulen, Prozessen und Computern für einen zuverlässigen, sinnvollen Austausch von Daten schaffen kann, während es die Software-Module und Computer "entkoppelt". "Entkoppeln" bedeutet, daß der Programmierer des Software-Moduls auf Informationen von anderen Computern oder Software-Prozessen zugreifen kann, ohne zu wissen, wo sich die anderen Software-Module und Computer in einem Netzwerk befinden, ohne das Format der Formulare und Daten in der fremden Software zu kennen, ohne zu wissen, welche Kommunikationsprotokolle zum Übertragen von Netzwerken zwischen dem Quellprozeß und dem Bestimmungsprozeß verwendet werden, und ohne zu wissen, welche von mehreren Rohdatenquellen die angeforderten Daten liefern können. Des weiteren bedeutet der Begriff "Entkoppeln", so wie er hier verwendet wird, daß Daten zu einem Zeitpunkt angefordert und zu einem anderen Zeitpunkt geliefert werden können, und daß ein Prozeß die gewünschten Daten von den Formularinstanzen erhalten kann, die mit fremden Formatdaten und fremden Semantikdaten durch die Ausführung durch eine Kommunikationsschnittstelle der entsprechenden semantischen Operationen erhalten werden können, um die angeforderten Daten von den fremden Formularen mit dem Extraktionsprozeß, der vom anfordernden Prozeß verstanden werden kann, zu extrahieren.
Es gibt unterschiedliche Systeme im Stand der Technik, die es ermöglichen, Informationen zwischen fremden Software-Modulen mit einem unterschiedlichen Grad an Entkoppelung auszutauschen. Ein derartiger Systemtyp ist eine Software für elektronische Post, welche die Normen für den Austausch von elektronischen Dokumenten (Electronic Document Exchange Standards) einschließlich der CCITT-Norm X.409 implementiert. Die Software für elektronische Post entkoppelt Anwendungen in dem Sinne, daß Format- und Typdaten in jeder Instanz eines Datensatzes oder Formulars enthalten sind. Es gibt jedoch keine Vorkehrungen zum Aufzeichnen oder Verarbeiten von semantischen Informationen. Semantische Operationen, wie zum Beispiel das Extrahieren oder Übersetzen von Daten basierend auf dem Namen oder der Bedeutung des gewünschten Feldes in der fremden Datenstruktur, sind daher unmöglich. Semantisch abhängige Operationen sind für eine erfolgreiche Kommunikation sehr wichtig. Des weiteren gibt es in der Software für elektronische Post keine Vorkehrungen, mit Hilfe derer eine gegenstandsbasierte Adressierung implementiert werden kann, bei der die anfordernde Anwendung einfach aufgrund des Gegenstandes Informationen anfordert, ohne die Adresse der Informationsquelle dieses Typs zu kennen. Des weiteren kann eine solche Software nicht auf ein Service oder ein Netzwerk zugreifen, für das kein Kommunikationsprotokoll errichtet wurde.
Relationale Datenbanken-Software und Datenwörterbücher sind andere Beispiele für Softwaresysteme des Standes der Technik, die es fremden Prozessen ermöglichen, gemeinsam auf Daten zuzugreifen. Der Nachteil dieser Softwareklasse liegt darin, daß solche Programme nur "flache" Tabellen, Datensätze und Felder innerhalb von Datensätzen, nicht aber verschachtelte Sätze innerhalb von Sätzen bearbeiten können. Weiter gibt es die oben erwähnten Nachteile elektronischer Post-Software auch bei Software für relationale Datenbanken.
Lum et al., "A General Methodology for Data Conversion and Restructuring", IBM Journal of Research and Development, Ausgabe 20, Nr. 5, September 1976, Seiten 483-497, offenbart ein Verfahren und ein Modell zur Datenumsetzung durch Umwandlung von Quelldaten in eine Zwischenform, die zur Übersetzung in das gewünschte Zielformat verwendet wird, wobei die Quelldaten, die Zwischenform und auch eine erste Version der Zieldaten durch aufeinanderfolgende Dateien dargestellt werden. Das Modell schafft eine Vielzahl an Schnittstellen, einschließlich einer Quellsystemschnittstelle, einer Zielsystemschnittstelle und einer Umsetzungsschnittstelle, die nacheinander verwendet werden. Die Anwendung des Verfahrens erfordert, daß die Benutzer die Datenstrukturen der linearisierten Eingabe- und Ausgabedateien beschreiben und die Zuordnungen zwischen den Quell- und Zieldaten festlegen. Zu diesem Zweck wurden zwei Sprachen, nämlich DEFINE und CONVERT, definiert, wobei die eine der Datenbeschreibung und die andere der Zuordnungsfestlegung dient.
Darüber hinaus offenbart Summers "Local-area distributed systems", IBM Systems Journal, Ausgabe 28, Nr. 2, 1989, Seiten 227-240, Systemsoftware-Aspekte in verteilten Nahbereichssystemen. Insbesondere diskutiert dieser Artikel verteilte Betriebssysteme, in denen die grundlegenden Betriebssystemobjekte oder -dateien verteilt sind. Ein solches Betriebssystem stellt dem Benutzer die Ansammlung von Computern, aus denen sich ein verteiltes System zusammensetzt, wie ein Bild eines einzelnen Systems dar, und es verhält sich wie ein einziger Computer mit einer einzigen Architektur. Dieser Artikel diskutiert weiter Netzwerkbetriebssysteme mit heterogenen Hardware- und Betriebssystemen, welche die sich ändernden Systembilder der Computer, die als Knoten im verteilten System arbeiten, bewahren, indem sie ihre Betriebssysteme warten und eine Netzwerkkomponente hinzufügen, die mit ihnen zusammenarbeitet. Der Artikel betrifft auch das Client-Server-Modell und das objektorientierte Modell. Das Client-Server-Modell betrifft sowohl verteilte Betriebssysteme als auch Netzwerkbetriebssysteme. Ein Client stellt eine Anforderung an ein Service, das irgendwo im System angeboten wird. Das System wird von einem Server verwaltet, der eine Software möglicherweise an einem anderen Knoten ausführt. In einem verteilten Betriebssystem ist jeder Knoten in der Lage, sowohl die Rolle des Clients als auch die Rolle des Servers zu spielen. In anderen Systemen besitzen einige Knoten nicht die Fähigkeit, die Aufgabe eines Servers zu übernehmen. Selbst dann, wenn alle Knoten über dieselben grundlegenden Fähigkeiten verfügen, können einigen Knoten bestimmte Funktionen zugewiesen werden. Im objektorientierten Modell besitzt jedes Systemobjekt einen Typ, der eine Gruppe von Operationen festlegt, um Objekte dieses Typs zu erzeugen und zu manipulieren. Die Implementierung eines Objektes wird vor dessen Benutzern verborgen, die nur die Typdefinition sehen.
Summers bezieht sich auch auf Programmschnittstellen- und Benennungsfunktionen in verteilten Nahbereichssystemen, wo Programme in der Lage sein müssen, Dateien auf einem Dateiserver ohne Änderungen an den Programmen gemeinsam zu nutzen. Es werden drei Ansätze für die Programmschnittstelle diskutiert. In einem ersten Ansatz wird ein Betriebssystemaufruf abgefangen und von Subroutinen in eine Anforderung eines anderen Knotens umgewandelt. Bei der Umwandlung können Informationen verwendet werden, die in einem früheren Befehl zur verfügung gestellt wurden, wie zum Beispiel Informationen, die notwendig sind, um ein Laufwerk auf ein Fernverzeichnis abzubilden. Bei einem zweiten Ansatz handelt es sich um eine Systemschnittstelle, die von verschiedenen Programmiersprachen aus aufgerufen werden kann. Beim dritten Ansatz handelt es sich um eine Programmiersprache oder eine Programmiersprachenerweiterung, die speziell für die verteilte Programmierung erstellt wird. Die Benennungsfunktion wird von der Benennungsdienst- oder Verzeichnisservicekomponente ausgeführt, welche die Namen der Objekte, bei denen es sich um Benutzer, Workstations, Services und anderes handeln kann, in Positionen abbildet. Der Benennungsdienst kann von einem Knoten oder von jedem Knoten für seine eigenen Objekte zur Verfügung gestellt werden, oder er kann für einige oder alle Knoten vervielfacht werden. Der Benennungsdienst kann auch bestimmen, welche Objekte den Anforderungen des Benutzers entsprechen. Zum Beispiel kann der Benutzer ein Druckservice benötigen, das ein bestimmtes Format für das Desktop Publishing akzeptiert. Der Benennungsdienst muß dann Objekte mit deren Namen und deren Attributen, wie zum Beispiel Position, akzeptierte Formate und Geschwindigkeit, asoziieren.
Keiner dieser Artikel betrifft eine Lösung, wie sie von der Erfindung geschaffen wird.

ZUSAMMENFASSUNG DER ERFINDUNG

Gemäß den Lehren der Erfindung, wie sie in den Ansprüchen festgelegt sind, wird ein Verfahren und eine Anordnung zum übertragen von Daten zwischen Anwendungen geschaffen, so daß eine anfordernde Anwendung Daten bezüglich eines bestimmten Gegenstandes anfordern kann, ohne die Netzwerkadresse des Servers oder Prozesses zu kennen, an dem die Daten zu finden sind. Diese Form der Entkoppelung erfolgt duch ein gegenstandsorientiertes Adressiersystem innerhalb der Informationschnittstelle.
Die gegenstandsorientierte Adressierung wird von der Kommunikationskomponente der Kommunikationsschnittstelle der Erfindung implementiert. Die Kommunikationskomponente erhält "Subskriptions"-Anforderungen von einer Anwendung, welche den Gegenstand angibt, über den Daten angefordert werden. Ein Gegenstandsabbilder-Modul in der Kommunikationskomponente empfängt die Anforderung von der Anwendung und sucht dann den Gegenstand in einer Datenbank, Tabelle oder ähnlichem. Die Datenbank speichert "Service- Sätze", welche die verschiedenen Serverprozesse anzeigen, die Daten über verschiedene Gegenstände liefern. Der entsprechende Service-Satz, der den jeweiligen Server-Prozeß identifiziert, welcher Daten des angeforderten Typs liefern kann, und das Kommunikationsprotokoll (im folgenden manchmal als Service-Disziplin bezeichnet), das bei der Kommunikation mit dem identifizierten Server-Prozeß verwendet wird, werden zum Gegenstandsabbilder-Modul zurückgegeben.
Der Gegenstandsabbilder hat Zugriff auf eine Vielzahl von Kommunikationsprogrammen, die als "Servicedisziplinen" bezeichnet werden. Jede Servicedisziplin implementiert ein zuvor festgelegtes Kommunikationsprotokoll, das für einen Serverprozeß, ein Netzwerk usw. spezifisch ist. Danach ruft der Gegenstandsabbilder die entsprechende, im Service-Satz identifizierte Service-Disziplin auf.
Die Service-Disziplin erhält den Gegenstand über den Gegenstandsabbilder und fährt damit fort, die Kommunikation mit dem entsprechenden Serverprozeß zu errichten. Danach werden Formularinstanzen, die Daten bezüglich des Gegenstandes enthalten, vom Serverprozeß über die Service- Disziplin, welche die Kommunikation errichtet hat., zum anfordernden Prozeß geschickt.
Die Serviceprotokoll-Entkoppelung wird von dem im vorhergehenden Abschnitt beschriebenen Prozeß realisiert.
Die zeitweilige Entkoppelung wird in manchen Service-Disziplinen, die auf seitenorientierte Serverprozesse, wie z.B. Telerate , gerichtet sind, durch Zugriff auf Echtzeit-Datenbanken implementiert, die Aktualisierungen in Seiten speichern, für welche Subskriptionen offen sind.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Figur 1 ist ein Blockdiagramm, das die Beziehungen der verschiedenen Software-Module der Kommunikationsschnittstelle einer Ausführungsform der Erfindung zu Client-Anwendungen und dem Netzwerk zeigt.
Figur 2 ist ein Beispiel einer Formularklassendefinition der konstruierten Mannigfaltigkeit.
Figur 3 ist ein Beispiel einer anderen konstruierten Formularklassendefinition.
Figur 4 ist ein Beispiel einer konstruierten Formularklassendefinition, welche Felder enthält, die selbst konstruierte Formulare sind. Daher ist dies ein Beispiel für Verschachtelung.
Figur 5 ist ein Beispiel für drei primitive Formularklassen.
Figur 6 ist ein Beispiel einer typischen Formularinstanz, wie sie im Speicher abgelegt wird.
Figur 7 zeigt die Aufteilung der semantischen Daten, der Formatdaten und der tatsächlichen oder Wertdaten zwischen der Formularklassendefinition und der Formularinstanz.
Figur 8 ist ein Flußdiagramm der Verarbeitung während einer Formatoperation.
Figur 9 ist eine zielformatspezifische Tabelle zur Verwendung bei Formatoperationen.
Figur 10 ist eine weitere zielformatspezifische Tabelle zur Verwendung bei Formatoperationen.
Figur 11 ist ein Beispiel einer allgemeinen Umwandlungstabelle für Formatoperationen.
Figur 12 ist ein Flußdiagramm einer typischen semantikabhangigen Operation.
Figur 13A und 13B sind eine Klassendefinition bzw. das Klassendeskriptorformular, in dem diese Klassendefinition gespeichert ist.
Figur 14 ist ein Blockdiagramm, das die Beziehungen zwischen dem Gegenstandsabbildermodul und den Service- Disziplinmodulen der Kommunikationskomponente für die anfordernde Anwendung und das Service für gegenstandsbasierte Adressierung zeigt.
Figur 15 zeigt die Beziehung der verschiedenen Module, Bibliotheken und Schnittstellen einer alternativen Ausführungsform der Erfindung für die dient-Anwendungen.
Figur 16 zeigt die Beziehungen der verschiedenen Module innerhalb der Kommunikationsschnittstelle einer alternativen Ausführungsform.

DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN UND ALTERNATIVEN AUSFÜHRUNGSFORMEN

Bezug nehmend auf Figur 1 ist ein Blockdiagramm eines typischen Systems dargestellt, in dem die Kommunikationsschnittstelle der Erfindung enthalten sein könnte, wenngleich eine Vielzahl unterschiedlicher Architekturen von den Lehren der Erfindung Nutzen ziehen kann. Die Kommunikationsschnittstelle der Erfindung kann im folgenden manchmal als TIB oder Teknekron Informationsbus in der untenstehenden Beschreibung einer alternativen Ausführungsform bezeichnet werden. Der Leser wird an dieser Stelle dringend gebeten, das in dieser Beschreibung enthaltende Begriffsglossar zu studieren, um ein grundlegendes Verständnis einiger der wichtigsten Begriffe zu erlangen, die hierin zur Beschreibung der Erfindung verwendet werden. Die Lehren der Erfindung sind in mehreren Computerprogrammbibliotheken enthalten, die gemeinsam eine Kommunikationsschnittstelle mit zahlreichen Funktionen darstellen, welche die Modularität bei der Client-Anwendungsentwicklung und Änderungen bei Netzwerkkommunikations- oder Servicekommunikationsanwendungsprotokollen erleichtern, indem zahlreiche Clients in einer "entkoppelten" Weise gekoppelt werden. Im folgenden werden die Lehren der Erfindung als die Kommunikationsschnittstelle bezeichnet. Der hierin verwendete Begriff "Entkoppeln" bedeutet, daß der Programmierer der Client-Anwendung Einzelheiten über die Kommunikationsprotokolle, das Datendarstellungsformat und die Datensatzorganisation all der anderen Anwendungen oder Services, mit denen ein Datenaustausch erwünscht ist, nicht kennen muß. Des weiteren muß der Programmierer der dient-Anwendung die Position der Services oder Server, welche Daten über bestimmte Gegenstände zur Verfügung stellen, nicht kennen, um in der Lage zu sein, Daten über diese Gegenstände zu erhalten. Die Kommunikationsschnittstelle sorgt sich automatisch um alle diese Einzelheiten beim Datenaustausch zwischen Client-Anwendungen und zwischen Dat en-Verbraucheranwendungen und Datenlieferservices.
Das in Figur 1 dargestellte System ist ein typisches Netzwerk, welches mehrere Host-Computer über ein Netzwerk ader durch einen gemeinsam benutzten Speicher ankoppelt. Zwei Hast-Computer, 10 und 12, sind in Figur 1 dargestellt, auf denen zwei dient-Anwendungen 16 und 18 laufen, wenngleich diese zwei dient-Anwendungen in anderen Ausführungsformen am selben Computer laufen können. Diese Host-Computer sind über ein Netzwerk 14 aneinandergekoppelt, bei dem es sich um ein beliebiges bekanntes Netzwerk, wie zum Beispiel das ETHERNET -Kommunikationsprotokoll, das Token-Ring-Protokoll usw. handeln kann. Ein Netzwerk für den Austausch von Daten ist für die Ausführung der Erfindung nicht erforderlich, da jedes im Stand der Technik bekannte Verfahren zum Datenaustausch zum Zwecke der Ausführung der Erfindung genügt. Demgemäß genügen auch gemeinsam verwendete Speicherdateien oder ein gemeinsam benutzter verteilter Speicher, auf die bzw. den die Hast-Computer 10 und 12 gleichen Zugriff haben, als Umgebung, in der die Lehren der Erfindung zur Anwendung kommen können.
Jeder der Hast-Computer 10 und 12 besitzt einen Direktzugriffsspeicher und einen Massenspeicher, wie zum Beispiel damit in Verbindung stehende Platten- oder Bandlaufwerke (nicht dargestellt). In diesen Speichereinrichtungen sind die verschiedenen Betriebssystemprogramme, die Client- Anwendungsprogramme sowie andere Programme, wie zum Beispiel die Programme in den Bibliotheken, enthalten, die gemeinsam die Kommunikationsschnittstelle bilden, durch welche die Hast-Computer in der Lage sind, nützliche Arbeiten auszuführen. Die Programmbibliotheken in der Kommunikationsschnittstelle stellen allgemeine Werkzeuge zur Verfügung, die von Client-Anwendungen aufgerufen werden können, um bestimmte Aufgaben durchzuführen, wie z.B. die Suche nach der Position der Services, die Daten über einen bestimmten Gegenstand zur Verfügung stellen, und eine Kommunikation mit dem Service unter Verwendung des geeigneten Kommunikationsprotokolls herzustellen.
Jeder der Hast-Computer kann auch an Anwenderschnittstellen, wie z.B. Terminals, Drucker, usw. (nicht dargestellt) gekoppelt werden.
Im beispielhaften System, das in Figur 1 dargestellt ist, hat der Hast-Computer in seinem Speicher ein Client-Anwendungsprogramm 16 gespeichert. Nehmen wir an, daß dieses Client-Anwendungspragramm 16 den Austausch von Daten mit einem anderen Client-Anwendungsprogramm oder Service 18 erfordert, das den Hast-Computer 12 kontrolliert, um nützliche Arbeiten auszuführen. Nehmen wir weiter an, daß die Hast-Computer 10 und 12 unterschiedliche Formate zur Darstellung van Daten verwenden, und daß auch die Anwendungsprogramme 18 und 18 unterschiedliche Formate für die Darstellung und Organisation der Daten für die dadurch erzeugten Datensätze verwenden. Diese Datensätze werden im folgenden meistens als Formulare bezeichnet. Nehmen wir auch an, daß der Datenpfad 14 zwischen den Host-Camputern 10 und 12 aus einem lokalen ETHERNET -Datennetz besteht.
Jeder der Hast-Prozessoren 10 und 12 ist auch mit einer Programmbibliothek programmiert, die zusammen die Kommunikationsschnittstelle 20 bzw. 22 umfassen. Die Kommunikationsschnittstellenprogramme sind entweder mit dem kampilierten Code der Client-Anwendungen uber einen Linker verknüpft, um den Laufzeitcade zu erzeugen, oder der Quellcode der Kommunikationsprogramme ist vor der Kompilierung im Quellcode der Client-Anwendungspragramme enthalten. Auf jeden Fall sind die Kommunikationsbibliatheksprogramme auf irgende ine Art und Weise mit der Client-Anwendung verbunden. Wenn daher auf dem Host-computer 10 zwei Client- Anwendungen laufen, würde jede dient-Anwendung mit einem Kommunikationsschnittstellenmodul,wie zum Beispiel dem Modul 20, verbunden sein.
Zweck des Kommunikationsschnittstellenmoduls 20 ist es, die Anwendung 16 von den Einzelheiten des Datenformats und der Organisation der Daten in den von der Anwendung 18 verwendeten Formularen, der Netzwerkadresse der Anwendung 18 und den Einzelheiten des von der Anwendung 18 verwendeten Kommunikationsprotokolls sowie den Einzelheiten des zum Senden der Daten über das Netzwerk 14 erforderlichen Datenformats und der Datenorganisation und des Kommunikationsprotokolls zu entkoppeln. Das Kommunikationsschnittstellenmodul 22 dient dem gleichen Zweck für die Anwendung 18, wodurch es sie von der Notwendigkeit befreit, viele Einzelheiten über die Anwendung 16 und das Netzwerk 14 kennen zu müssen. Die Kommunikationsschnittstellenmodule ermöglichen insoferne eine Modularität, als Anderungen in Client- Anwendungen, Datenformaten oder Organisationen, Host- Computern oder den Netzwerken, die zum Ankoppeln aller oben genannten Vorrichtungen verwendet werden, durchgeführt werden können, ohne daß diese Änderungen zur Gewährleistung kontinuierlicher Kompatibilität im gesamten System weitergeführt werden müssen.
Um einige dieser Funktionen zu implementieren, haben die Kommunikationsschnittstellen 20 und 22 über das Netzwerk 14 Zugriff auf ein Netzwerkdateisystem 24, welches eine Gegenstandstabelle 26 und eine Servicetabelle 28 umfaßt. Diese Tabellen werden in näheren Einzelheiten unter Bezugnahme auf die Diskussion der gegenstandsbasierten Adressierung weiter unten diskutiert. Diese Tabellen führen die Netzwerkadressen der Services an, die Informationen über verschiedene Gegenstände anbieten.
Ein typisches Systemmodell, in dem die Kommunikationsschnittstelle verwendet wird, besteht aus Anwendern, Anwendergruppen, Netzwerken, Services, Serviceinstanzen (oder Servern) und Gegenständen. Anwender, repräsentiert durch menschliche Endanwender, werden durch eine Anwenderkennung identifiziert. Die in der Kommunikationsschnittstelle verwendete Anwenderkennung ist normalerweise dieselbe wie die Anwenderkennung oder Anmeldekennung, die vom darunterhegenden Betriebssystem (nicht dargestellt) verwendet wird. Dies muß jedoch nicht unbedingt der Fall sein. Jeder Anwender ist ein Mitglied exakt einer Gruppe.
Gruppen bestehen aus Anwendern mit ähnlichen Servicezugriffsmustern und Zugriffsrechten. Zugriffsrechte auf ein Service oder ein Systemobjekt sind auf der Ebene der Anwender und auf der Ebene der Gruppen zuteilbar. Der Systemadministrator ist für die Zuteilung der Anwender zu den Gruppen verantwortlich.
Mit dem hierin verwendeten Begriff "Netzwerk" werden die darunterliegende "Transportschicht" (wie dieser Begriff im ISO-Netzwerkschichtmodell bezeichnet wird) und alle Schichten unterhalb der Transportschicht im ISO- Netzwerkmodell bezeichnet. Eine Anwendung kann Daten über jedes beliebige Netzwerk, an dem ihr Host-Computer angeschlossen ist, senden oder empfangen.
Die Kommunikationsschnittstelle gemäß den Lehren der Erfindung, von der die Blöcke 20 und 22 beispielhaft in Figur 1 dargestellt sind, umfaßt für jede dient-Anwendung, an die sie angebunden ist, eine Kommunikationskomponente 30 und eine Datenaustauschkomponente 32. Die Kommunikations komponente 30 ist eine allgemeine Gruppe von Kommunikationseinrichtungen, die zum Beispiel gegenstandsbasierte Adressierung und/oder Service-Disziplimentkoppelung implementieren. Die Kommunikationskomponente ist mit jeder Client-Anwendung verknüpft. Darüber hinaus ist jede Kommunikationskomponente mit den Standardtransportschichtprotokollen, wie z.B. TCP/IP, des Netzwerkes verknüpft, an das sie gekoppelt ist. Jede Kommunikationskomponente ist mit mehreren Transportschichtprotokollen verknüpft und kann diese unterstützen. Die Transportschicht eines Netzwerkes führt folgende Arbeiten aus: sie bildet Transportschichadressen auf Netzwerkadressen ab, nutzt vielfach die Transportschichtverbindungen auf Netzwerkverbindungen aus, um einen größeren Durchsatz zu ermöglichen, führt eine Fehlererkennung und Fehlerüberwachung der servicequalität, Fehlerbehebung, Segmentierung und Blockung, Flußkontrolle der einzelnen Anschlüsse der Transportschicht zum Netzwerk und Sitzungs schichten sowie beschleunigte Datenübertragung durch. Die Kommunikationskomponente bietet zuverlässige Kommunikationsprotokolle für dient-Anwendungen sowie eine Positionstransparenz und Netzwerkunabhängigkeit für die Client- Anwendungen.
Die Datenaustauschkomponente der Kommunikationsschnittstelle, für die die Komponente 32 typisch ist, implementiert eine leistungsstarke Möglichkeit zur Darstellung und Übertragung von Daten durch Einkapselung der Daten innerhalb von selbstbeschreibenden Datenobjekten, die als Formulare bezeichnet werden. Diese Formulare sind insoferne selbstbeschreibend, als sie nicht nur die angeforderten Daten enthalten, sondern auch Informationen über den Typ oder das Format, welche die für die Daten verwendeten Darstellungen und die Organisation des Formulars beschreiben. Da die Formulare diese Typ- oder Formatinformationen enthalten, können Formatoperationen zum Umwandeln eines bestimmten Formulars von einem Format in ein anderes Format dadurch ausgeführt werden, indem ausschließlich die Daten im Formular selbst verwendet werden, ohne daß zu diesem Zweck auf andere Daten, die als Klassendeskriptoren oder Klassendefinitionen bezeichnet werden, welche semantische Informationen enthalten, zugegriffen werden muß. Mit der Bezeichnung der semantischen Informationen in Klassendeskriptoren sind grundsätzlich die Namen der Formularfelder gemeint.
Die Fähigkeit, Formatoperationen ausschließlich mit den im Formular selbst enthaltenen Daten auszuführen, ist insoferne sehr wichtig, als daß dadurch jene Verzögerungen verhindert werden, die auftreten, wenn auf andere Datenobjekte zugegriffen werden muß, die sich an anderen Stellen befinden, wie zum Beispiel Klassendeskriptoren. Da Formatoperationen alleine typischerweise 25 bis 50% der Verarbeitungszeit für dient-Anwendungen ausmachen, verbessert die Verwendung selbstbeschreibender Objekte die Verarbeitung insoferne, als daß sie sie schneller macht.
Die von der Datenaustauschkomponente verwalteten selbstbeschreibenden Formulare ermöglichen auch die Implementierung allgemeiner Werkzeuge für die Datenmanipulation und die Datenanzeige. Zu solchen Werkzeugen gehören Kommunikationswerkzeuge zum Senden von Formularen zwischen Prozessen in einem maschinenunabhängigen Format. Da selbstbeschreibende Formulare erweitert werden können, das heißt, daß ihre Organisation geändert oder ausgeweitet werden kann, ohne daß dies nachteilige Auswirkungen auf die Client-Anwendungen hat, welche diese Formulare verwenden, erleichtem solche Formulare des weiteren die modulare Anwendungsentwicklung ungemein.
Da die unterste Schicht der Kommunikationsschnittstelle mit der Transportschicht des ISO-Modells verknüpft ist, und da die Kommunikationskomponente 30 mehrere Service-Disziplinen und mehrere Transportschichtprotokolle umfaßt, um mehrere Netzwerke zu unterstützen, ist es möglich, anwendungsorientierte Protokolle zu schreiben, die auf transparente Weise von einem Netzwerk zu einem anderen umschalten, falls ein Netzwerk einmal ausfallen sollte.
Ein "Service" repräsentiert eine sinnvolle Gruppe von Funktionen, die von einer Anwendung zur Verwendung durch ihre dient-Anwendungen exportiert werden. Beispiele für Services sind Wiederauffinde-Services für historische Neuheiten, wie zum Beispiel Dow Jones New, Quotron Datafeed und ein Trade Ticket Router. Anwendungen exportieren typischerweise nur ein Service, obwohl der Export vieler unterschiedlicher Services auch möglich ist.
Eine "Service-Instanz" ist eine Anwendung oder ein Prozeß, der in der Lage ist, das jeweilige Service zur Verfügung zu stellen. Für ein gegebenes Service können mehrere "Instanzen" gleichzeitig das Service zur Verfügung stellen, um dadurch den Durchsatz des Services zu verbessern oder eine Fehlertoleranz zu ermöglichen.
Obwohl Netzwerke, Services und Server traditionelle Komponenten sind, die im Stand der Technik bekannt sind, kennen verteilte Systeme des Standes der Technik nicht den Begriff eines Gegenstandsraumes oder der Datenunabhängigkeit durch die Selbstbeschreibung verschachtelter Datenobjekte. Der Gegenstandsraum unterstützt eine Form der Entkoppelung, die als gegenstandsbasierte Adressierung bezeichnet wird. Die Selbstbeschreibung von Datenobjekten, die über mehrere Ebenen verschachtelt sein können, ist neu. Das Entkoppeln von Olient-Anwendungen von den verschiedenen Kommunikationsprotokollen und den Datenformaten, die in anderen Teilen des Netzwerkes vorherrschend sind, ist ebenfalls sehr nützlich.
Der zur Implementierung gegenstandsbasierter Adressierung verwendete Adreßraum besteht aus einer hierarchischen Gruppe von Gegenstandskategorien. In der bevorzugten Ausführungsform wird eine Gegenstandsraumhierarchie mit vier Ebenen verwendet. Ein Beispiel eines typischen Gegenstandes ist "equity.ibm.composite.trade.". Die an die Kommunikationsschnittstelle gekoppelten dient-Anwendungen haben die Freiheit und Verantwortung, Konventionen bezüglich der Verwendung und Interpretation der verschiedenen Gegenstandskategorien zu errichten.
Jeder Gegenstand steht typischerweise mit einem oder mehreren Services in Verbindung, die Daten über diesen Gegenstand in Datensätzen zur verfügung stellen, die in den Systemdateien gespeichert sind. Da jedem Service in den Kommunikationskomponenten der Kommunikationsschnittstelle eine Service-Disziplin zugeordnet ist, d.h. das Kommunikationsprotokoll oder die Prozedur, die für die Kommunikation mit dem Service erforderlich ist, können die Client- Anwendungen Daten bezüglich eines bestimmten Gegenstandes anfordern, ohne zu wissen, wo die Service-Instanzen, welche die Daten über diesen Gegenstand liefern, im Netzwerk zu finden sind, indem sie Subskriptionsanforderungen erstellen, in denen nur der Gegenstand ohne der Netzwerkadresse des Services, das Informationen über diesen Gegenstand anbietet, angegeben ist. Die Subskriptionsanforderungen werden von der Kommunikationsschnittstelle in eine aktuelle Kommunikationsverbindung mit einer oder mehreren Serviceinstanzen übersetzt, welche Informationen über diesen Gegenstand anbieten.
Eine Gruppe von Gegenstandskategorien wird als Gegenstandsdomäne bezeichnet. Mehrere Gegenstandsdomänen sind erlaubt. Jede Domäne kann domänenspezifische Gegenstandscodierfunktionen für eine wirkungsvolle Darstellung von Gegenständen in Nachrichtenkopf zeilen festlegen.

DATENUNABHÄNGIGKEIT: Die Datenaustauschkomponente

Der übergeordnete Zweck der Datenaustauschkomponente, wie z.B. der Komponente 32 in Figur 1 der Kommunikationsschnittstelle, besteht darin, die dient-Anwendungen, wie zum Beispiel die Anwendung 16, von den Einzelheiten der Datendarstellung, der Datenstrukturierung und der Datensemantik abzukoppeln.
Bezug nehmend auf Figur 2 ist ein Beispiel einer Klassendefinition für eine konstruierte Klasse dargestellt, die sqwohl Format- als auch Semantikinformationen definiert, welche allen Formularinstanzen dieser Klasse gemein sind. In dem ausgewählten Beispiel trägt die Formularklasse die Bezeichnung Player_Name (Spielername) und hat eine Klassenkennung von 1000. Die Formularinstanzen dieser Klasse 1000 umfassen Daten bezüglich Namen, Alter und Weltranglistenplazierung von Tennisspielern. Jeder Klassendefinition ist eine als Klassenkennung bezeichnete Klassennummer zugeordnet, die diese Klasse auf unverwechselbare Weise kennzeichnet.
Die Klassendefinition erstellt eine Liste von Feldem nach Namen sowie die Datendarstellung des Feldinhalts. Jedes Feld enthält ein Formular, und jedes Formular kann entweder primitiv oder konstruiert sein. Primitive Klassenformulare speichern aktuelle Daten, während konstruierte Klassenformulare Felder besitzen, die andere Formulare enthalten, die entweder primitiv oder konstruiert sein können. In der Klassendefinition von Figur 2 gibt es vier Felder mit der Bezeichnung Rating (Reihung), Age (Alter), Last_Name (Familienname) und First_Name (Vorname). Jedes Feld enthält ein primitives Klassenformular, so daß jedes Feld in den Formularinstanzen dieser Klasse aktuelle Daten enthält. Zum Beispiel wird das Feld Rating (Reihung) immer eine primitive Form der Klasse 11 enthalten. Die Klasse 11 ist eine primitive Klasse mit der Bezeichnung Floating_Point (Gleitkomma), welche eine Gleitkommadatendarstellung für den Inhalt dieses Feldes beschreibt. Die primitive Klassendefinition für die Klasse Floating_Point, Klasse 11, ist in Figur 5 enthalten. Die Klassendefinition der primitiven Klasse 11 enthält den Klassennamen, Floating_Point, der auf unverwechselbare Weise die Klasse (die Klassennummer, in diesem Beispiel Klasse 11, identifiziert auch auf unverwechselbare Weise die Klasse) und eine Beschreibung der Datendarstellung des einzelnen Datenwertes identifiziert. Die Beschreibung des einzelnen Datenwertes verwendet bekannte, vordefinierte Systemdatentypen, die sowohl vom Host-Computer als auch von der Anwendung, die sich mit dieser Formularklasse beschäftigt, verstanden werden.
Zu den typischen Beschreibungen für die Datendarstellung aktueller Datenwerte gehören unter anderem Ganzzahl, Gleitkomma, ASCI-Zeichenketten oder EBCDIC- Zeichenketten, usw. Im Falle der primitiven Klasse 11 handelt es sich bei der Beschreibung des Datenwertes um Floating_Point_1/1, einer willkürlich gewählten Notation, die anzeigt, daß es sich bei den Daten, die in Formularinstanzen dieser primitiven Klasse gespeichert werden, um Gleitkommadaten mit insgesamt zwei Stellen handeln wird, wobei eine davon rechts vom Dezimalpunkt steht.
Wenden wir uns wieder der Besprechung der Player_Name Klassendefinition von Figur 2 zu, bei der das zweite Feld den Namen Age (Alter) trägt. Dieses Feld enthält Formulare der primitiven Klasse mit der Bezeichnung Integer (Ganzzahl), die mit der Klassennummer 12 verbunden ist und in Figur 5 definiert ist. Die Integer-Formularklasse, Klasse 12, hat gemäß der Klassendefinition von Figur 5 die Datendarstellungsbeschreibung Integer_3, was bedeutet, daß das Feld dreistellige Ganzzahldaten enthält. Die letzten zwei Felder der Definition der Klasse 1000 in Figur 2 sind Last_Name und First_Name (Familienname und Vorname). Beide diese Felder enthalten primitive Formen einer Klasse mit der Bezeichnung String_Twenty_ASCII, Klasse 10. Die Klassendefinition der Klasse 10 ist in Figur 5 dargestellt und legt fest, daß Formularinstanzen dieser Klasse ASCII- Zeichenketten enthalten, die 20 Zeichen lang sind.
Figur 3 zeigt eine andere konstruierte Klassendefinition mit der Bezeichnung Player_Address (Spieleradresse), Klasse 1001. Formularinstanzen dieser Klasse enthalten jeweils drei Felder mit den Bezeichnungen Street, City und State (Straße, Stadt und Land). Jedes dieser drei Felder enthält primitive Formen einer Klasse mit der Bezeichnung String_20_ASCII, Klasse 10. Wiederum ist die Klassendefinition für die Klasse 10 in Figur 5 dargestellt und legt eine Datendarstellung durch 20 Zeichen lange ASCII-Ketten fest.
Ein Beispiel für die Verschachtelung konstruierter Klassenformulare ist in Figur 4 dargestellt. Figur 4 ist eine Klassendefinition für Formularinstanzen in der Klasse mit der Bezeichnung Tournament_Entry (Turniereintritt) Klasse 1002. Jede Farmularinstanz in dieser Klasse enthält drei Felder mit den Bezeichnungen Tournament_Name, Player und Address (Turnierbezeichnung, Spieler und Adresse). Das Feld Taurnament_Name enthält Formulare der primitiven Klasse mit der Bezeichnung String_Twenty_ASCII, Klasse 10, die in Figur 5 definiert ist. Das Feld mit dem Namen Player enthält Instanzen konstruierter Formulare der Klasse mit dem Namen Player_Name, Klasse 1000, welche die in Figur 2 dargestellten Format- und Semantikeigenschaften besitzt. Das Feld mit dem Namen Address enthält Instanzen der konstruierten Form konstruierter Formulare der konstruierten Klasse mit dem Namen Player_Address, Klasse 1001, welche die in der Klassendefinition von Figur 3 angegebenen Format- und Semantikmerkmale besitzt.
Die Klassendef inition von Figur 4 zeigt, wie das Verschachteln von Formularen dadurch geschehen kann, daß jedes Feld eines Formulars selbst ein Formular ist und jedes Formular entweder primitiv sein und nur ein Feld besitzen oder konstruiert sein und mehrere Felder besitzen kann. In anderen Worten können Instanzen eines Formulars so viele Felder wie nötig besitzen, und jedes Feld kann so viele Unterfelder wie nötig besitzen. Des weiteren besitzt jedes Unterfeld so viele Unterfelder wie nötig. Diese Verschachtelung kann über eine beliebige Anzahl an Ebenen fortgeführt werden. Durch diese Datenstruktur ist es möglich, daß eine beliebige Komplexität auf einfache Weise dargestellt und bearbeitet werden kann.
Bezug nehmend auf Figur 6 ist eine Formularinstanz der Formularklasse mit der Bezeichnung "tournament_Entry" (Turniereintritt), Klasse 1002, dargestellt, wie sie als Objekt im Speicher abgelegt wird. Der Datenblock 38 enthält die konstruierte Klassennummer 1002, welche anzeigt, daß es sich hierbei um eine Formularinstanz der konstruierten Klasse mit der Bezeichnung Tournament_Enty handelt. Der Datenblock 40 zeigt an, daß diese Formularklasse drei Felder besitzt. Diese drei Felder besitzen die bei 42, 44 und 46 dargestellten Datenblöcke, welche die Klassennummern der Formulare in diesen Feldern enthalten. Der Datenblock bei 42 zeigt an, daß das erste Feld ein wie in Figur 5 dargestelltes Klassenformular 10 enthält. Ein Formular der Klasse 10 ist ein primitives Formular, das eine 20 Zeichen lange Kette von ASCII-Zeichen enthält, wie dies in der Klassendefinition für die Klasse 10 in Figur 5 festgelegt ist. Die aktuelle Kette der ASCII-Zeichen für diese bestimmte Instanz dieses Formulars ist bei 48 dargestellt und zeigt an, daß dies ein Turniereintrag für das US Open Tennisturnier ist. Der Datenblock bei 44 zeigt an, daß das zweite Feld ein Formular enthält, bei dem es sich um eine Instanz eines konstruierten Formulars der Klasse 1000 handelt. Eine Bezugnahme auf diese Klassendefinition zeigt, daß diese Klasse die Bezeichnung Player_Name (Spielername) trägt. Der Datenblock 50 zeigt, daß diese Klasse eines konstruierten Formulars vier Unterfelder enthält. Diese Felder enthalten Formulare der Klassen, die in den bei 52, 54, 56 und 58 gezeigten Datenblöcken aufgezeichnet sind. Diese Felder wären Unterfelder des Feldes 44. Das erste Unterfeld besitzt einen Datenblock bei 52, der anzeigt, daß dieses Unterfeld ein Formular der primitiven Klasse 11 enthält. Diese Formularklasse wird in Figur 5 so definiert, daß sie eine zweistellige Gleitkommazahl mit einer Dezimalstelle enthält. Die aktuellen Daten für diese Instanz des Formulars sind bei 60 dargestellt und zeigen an, daß dieser Spieler eine NTRP-wertung von 3,5 hat. Das zweite Unterfeld besitzt einen Datenblock bei 54, der anzeigt, daß dieses Unterfeld ein Formular der primitiven Klasse 12 enthält. Die Klassendefinition für diese Klasse zeigt an, daß die Klasse die Bezeichnung Integer trägt und Ganzzahldaten (Integer-Daten) enthält. Die Klassendefinition für die in Figur 2 dargestellte Klasse 1000 zeigt an, daß diese Ganzzahldaten, welche bei Block 62 dargestellt sind, das Alter des Spielers angeben. Man beachte, daß die semantischen Daten der Klassendefinition bezüglich der Feldnamen nicht in der Formularinstanz gespeichert werden. Nur Format- oder Typinformationen werden in der Formularinstanz in Form der Klassenkennung für jedes Feld gespeichert.
Das dritte Unterfeld besitzt einen Datenblock bei 56, der anzeigt, daß dieses Unterfeld ein Formular der primitiven Klasse 10 mit der Bezeichnung String_20_ASCII enthält. Dieses Unterfeld entspricht dem Feld Last_Name (Familienname) im Formular der Klasse Player_Name, Klasse 1000, das in Figur 2 dargestellt ist. Die Klassendefinition der primitiven Klasse 10 legt fest, daß Instanzen dieser primitiven Klasse eine 20 Zeichen lange ASCII-Textkette enthalten. Diese Textkette definiert den Familiennamen des Spielers. In der in Figur 6 gezeigten Instanz lautet der Familienname des Spielers Blackett, wie dies bei 64 gezeigt wird.
Das letzte Unterfeld besitzt einen Datenblock bei 58, der anzeigt, daß das Feld ein primitives Formular der primitiven Klasse 10 enthält, bei der es sich um eine 20 Zeichen lange ASCII-Textkette handelt. Dieses Unterfeld wird in der Klassendefinition der Klasse 1000 so definiert, daß es den Vornamen des Spielers enthält. Diese ASCII- Textkette ist bei 66 dargestellt.
Das dritte Feld in der Instanz des Formulars der Klasse 1002 besitzt einen Datenblock bei 46, der anzeigt, daß dieses Feld ein konstruiertes Formular der konstruierten Klasse 1001 enthält. Die Klassendefinition für diese Klasse ist in Figur 3 dargestellt und zeigt an, daß die Klasse die Bezeichnung Player_Address besitzt. Der Datenblock bei 68 zeigt an, daß dieses Feld drei Unterfelder besitzt, die Formulare der bei 70, 72 und 74 angegebenen Klassennummern enthalten. Diese Unterfelder enthalten jeweils Formulare der in Figur 5 dargestellten primitiven Klasse 10. Jedes dieser drei Unterfelder enthält daher eine 20 Zeichen lange ASCII-Textkette. Der Inhalt dieser drei Felder ist in der Klassendefinition für die Klasse 1001 definiert und trägt für die Adresse des im Feld 44 genannten Spielers die Bezeichnung Straße, Stadt bzw. Land. Diese 3 Zeichen langen Textketten sind bei 76, 78 bzw. 80 dargestellt.
In Figur 7 ist eine Aufteilung der semantischen Informationen, der Formatinformationen und der aktuellen Daten zwischen der Klassendefinition und den Instanzen der Formulare dieser Klasse dargestellt. Der Feldname und die Format- oder Typeninformationen sind, wie durch die Box 82 dargestellt, in der Klassendefinition gespeichert. Die Format- oder Typeninformationen (in Form der Klassenkennung) und die aktuellen Daten oder Feldwerte sind in der Instanz des Formulars gespeichert, wie dies durch die Box 72 dargestellt wird. Zum Beispiel handelt es sich in der Instanz des Formulars der Klasse Tournament_Entry, Klasse 1002, dargestellt in Figur 6, bei den Formatdaten für das erste Feld um die Daten, die in Block 42 gespeichert sind, während es sich bei den aktuellen Daten für das erste Feld um die bei Block 48 dargestellten Daten handelt. Im wesentlichen wird die Klassennummer oder Klassenkennung durch die Kommunikationsschnittstelle der Beschreibung für den Datentyp in den Formularinstanzen jener primitiven Klasse gleichgesetzt. Somit kann die Kommunikationsschnittstelle Formatoperationen an Instanzen eines bestimmten Formulars durchführen, indem sie nur die in der Formularinstanz selbst gespeicherten Formatdaten verwendet, ohne deswegen auf die Klassendefinition zugreifen zu müssen. Dies beschleunigt die Formatoperationen, indem jene Schritte entfallen, die für den Zugriff auf eine Klassendefinition notwendig wären, wozu unter anderem der Netzwerkzugriff und/oder der Plattenzugriff gehören, welche die Operation wesentlich verlangsamen würden. Da formatartige Operationen die Menge aller Operationen beim Austausch von Daten zwischen fremden Prozessen umfassen, erhöhen die Datenstruktur und die Programmbibliothek zur Bearbeitung der darin definierten Datenstruktur die Leistung des Datenaustausches zwischen fremden Prozessen und fremden Computern enorm. Nehmen wir zum Beispiel an, daß die Instanz des Formulars, welche in Figur 6 dargestellt ist, durch einen Prozeß erzeugt wurde, der auf einem Computer der Digital Equipment Corporation (DEC) läuft und der Text daher in ASCII-Zeichen ausgedrückt wird. Nehmen wir weiter an, daß dieses Formular an einen Prozeß gesendet werden muß, der auf einem IBM-Computer läuft, wo Zeichenketten im EBCDIC- Code ausgedrückt werden. Nehmen wir auch an, daß diese zwei Computer über ein lokales Datennetz mit einem ETHERNET - Kommunikationsprotokoll aneinander gekoppelt sind.
Um diese Übertragung durchführen zu können, müßten mehrere Formatoperationen ausgeführt werden. Diese Formatoperationen können am besten durch Bezugnahme auf Figur 1 verstanden werden, wobei davon ausgegangen wird, daß der DEC-Computer der bei 10 dargestellte Host 1 ist, und der IBM-Computer der bei 12 dargestellte Host 2.
Die erste Formatoperation zur Übertragung der Instanz des in Figur 6 gezeigten Formulars von der Anwendung 16 zur Anwendung 18 wäre eine Umwandlung von dem in Figur 6 dargestellten Format in ein paketiertes Format, das sich zur Übertragung über das Netzwerk 14 eignet. Netzwerke arbeiten typischerweise mit Nachrichten, die sich aus Datenblöcken zusammensetzen, welche aus einer Mehrzahl von Bytes bestehen, die Ende an Ende paketiert werden und denen mehrere Bytes an Kopfzeileninformation vorangestellt sind, die verschiedene Informationen wie z.B. die Nachrichtenlänge, die Bestimmungsadresse, die Quelladresse, und so weiter, enthalten, und die auch Fehlerkorrektur-Codebits enthalten, die an das Ende der Nachricht angehängt sind. Manchmal werden auch Begrenzer verwendet, um den Anfang und das Ende des aktuellen Datenblocks zu markieren.
Die zweite Formatoperation, die bei dieser hypothetischen Übertragung durchgeführt werden müßte, wäre eine Umwandlung vom paketierten Format, das für die Übertragung über das Netzwerk 14 benötigt wird, in das Format, das von der Anwendung 18 und dem Host-Computer 12 verwendet wird.
Formatoperationen werden von den Formularmanagermodulen der Kommunikationsschnittstelle durchgeführt. Zum Beispiel würde die erste Formatoperation bei dieser hypothetischen Übertragung vom Formularmanagermodul 86 in Figur 1 durchgeführt, während die zweite Formatoperation bei der hypothetischen Übertragung vom Formularmanagermodul in der Datenaustauschkomponente 88 durchgeführt würde.
In Figur 8 ist ein Flußdiagramm der Operationen dargestellt, die von den Formularmanagermodulen bei Ausführung der Formatoperationen ausgeführt werden. Weitere Einzelheiten bezüglich der verschiedenen funktionellen Fähigkeiten der Routinen in den Formularmanagermodulen der Kommunikationsschnittstelle sind in der hierin enthaltenen Funktionsbeschreibung der verschiedenen Bibliotheksroutinen der Kommunikationsschnittstelle enthalten. Der Prozeß von Figur 8 wird von den Softwareprogrammen in den Formularmanagermodulen der Datenaustauschkomponenten in der Kommunikationsschnittstelle gemäß den Lehren der Erfindung implementiert. Der erste Schritt besteht darin, einen Formatumwandlungsaufruf entweder von der Anwendung oder von einem anderen Modul in der Kommunikationsschnittstelle zu erhalten. Dieser Prozeß wird durch Block 90 und den Pfaden 92 und 94 in Figur 1 symbolisiert. Derselbe Typenauf ruf kann von der Anwendung 18 oder der Kommunikationskomponente 96 für den Host-Computer 12 in Figur 1 an das Formularmanagermodul in der Datenaustauschkomponente 88 gemacht werden, da dies eine Standard-Funktion oder ein "Standard-Werkzeug" ist, das von der Kommunikationsschnittstelle der Erfindung allen dient-Anwendungen zur Verfügung gestellt wird. Jede dient-Anwendung ist mit einer Kommunikationsschnittstelle, wie der Schnittstelle 20 in Figur 1, verknüpft.
Typischerweise erfolgen Formatumwandlungsaufrufe von den Kommunikationskomponenten, wie zum Beispiel den Modulen 30 und 96 in Figur 1, an das Formularmanagermodul durch ein Service-Disziplinmodul, welches die Aufgabe hat, ein Formular im Format 1 an eine fremde Anwendung zu schikken, die das Format 2 verwendet. Ein anderes wahrscheinliches Szenario für einen Formatumwandlungsaufruf von einem anderen Modul in der Kommunikationsschnittstelle wäre, wenn eine Service-Disziplin ein Formular von einer anderen Anwendung oder einem anderen Service erhalten hat, das sich in einem fremden Format befindet und das in das Format der dient-Anwendung umgewandelt werden muß.
Dem Formatumwandlungsaufruf sind Parameter zugeordnet, die vom Formularmanager erstellt werden. Diese Parameter legen das "von"-Format und das "zu"- oder "Ziel"-Format fest.
Block 98 repräsentiert den Prozeß des Zugriffs auf eine geeignete zielformatspezifische Tabelle für die angegebene Umwandlung, d.h. das festgelegte "von"-Format und das festgelegte "zu"-Format besitzen eine dedizierte Tabelle, die Einzelheiten über die entsprechende Zielformatklasse für jede primitive "von"-Formatklasse zur Durchführung der Umwandlung enthält. Es gibt zwei Tabellen, auf die während jeder Formatumwandlungsoperation in der bevorzugten Ausführungsform der Reihe nach zugegriffen wird. In alternativen Ausführungsformen können diese zwei Tabellen kombiniert sein. Beispiele der zwei in der bevorzugten Ausführungsform verwendeten Tabellen sind in Figur 9, 10 und 11 enthalten. Figür 9 zeigt eine spezifische Formatumwandlungstabelle für die Umwandlung vom DEC-Maschinenformat in das X.409-Format. Figur 10 zeigt eine formatspezifische Formatumwandlungstabelle für die Umwandlung vom X.409- Format in das IBM-Maschinenformat. Figur 11 zeigt eine allgemeine Umwandlungsprozedurtabelle, welche den Namen des Umwandlungsprogramms in der Kommunikatiansschnittstellenbibliothek definiert, die die jeweilige Umwandlung für jedes "von"-"zu"-Formatpaar durchführt.
Die Tabellen von Figur 9 und 10 sind möglicherweise nicht die einzigen Tabellen, die zum Senden eines Formulars von der Anwendung 16 zur Anwendung 18 in Figur 1 benötigt werden. Für die Umwandlung vom Format der Anwendung 16 in das DEC-Maschinenformat und für die Umwandlung vom IBM- Maschinenformat in das Format der Anwendung 18 können weitere formatspezifische Tabellen erforderlich sein. Das allgemeine Konzept des von den Formularmanagermodulen der Kommunikationsschnittstelle implementierten Formatumwandlungsprozesses kann jedoch unter Bezugnahme auf Figur 9, 10 und 11 erklärt werden.
Nehmen wir an, daß es sich bei der ersten Umwandlung, die beim Senden eines Formulars von Anwendung 16 zur Anwendung 18 erforderlich ist, um eine Umwandlung vom DEC- Maschinenformat in ein paketiertes Format handelt, das sich zur Übertragung über ein ETHERNET -Netzwerk eignet. In diesem Fall würde der in Schritt 90 empfangene Formatumwandlungsaufruf die Verarbeitung durch eine Softwareroutine im Formularmanagermodul aufrufen, die den durch Block 98 symbolisierten Prozeß durchführen würde.
In diesem hypothetischen Beispiel würde die geeignete formatspezifische Tabelle, auf welche diese Routine zugreifen müßte, von den "von"- und "zu"-Formatparametern im ursprünglichen Formatumwandlungsaufruf bestimmt werden, der von Block 90 empfangen wird. Dies würde zu einem Zugriff auf die in Figur 9 dargestellte Tabelle führen. Der Formatumwandlungsaufruf würde auch die Adresse des umzuwandelnden Formulars identifizieren.
Der nächste Schritt ist durch Block 100 symbolisiert. Dieser Schritt umfaßt den Zugriff auf das im ursprünglichen Formatumwandlungsaufruf identifizierte Formular und die Durchsuchung des Formulars, um das erste Feld zu finden, welches eine primitive Formularklasse enthält. In anderen Worten wird der Datensatz durchsucht, bis ein Feld gefunden wird, in dem aktuelle Daten gespeichert sind und nicht ein anderes konstruiertes Formular, das Unterfelder besitzt.
Im Falle des in Figur 6 gezeigten Formulars ist das erste Feld, in dem eine primitive Formularklasse gespeichert ist, das Feld 42. Die "von"-Spalte der Tabelle von Figur 9 würde mit Hilfe der Klassennummer 10 durchsucht, bis der entsprechende Eintrag gefunden würde. In diesem Fall zeigt der Eintrag für eine "von"-Klasse von 10 an, daß das in der Klassendefinition für die primitive Klasse 25 angegebene Format das "zu"-Format ist. Dieses Nachschlagen des "zu"-Formats mit Hilfe des "von"-Formats ist in Figur 8 durch Block 102 symbolisiert. Die in Figur 9 dargestellte Tabelle kann mit dem Code der Routine, welche den von Block 102 symbolisierten Schritt ausführt, "festverdrahtet" sein.
Alternativ dazu kann es sich bei der Tabelle von Figur 9 um eine Datenbank oder eine andere Datei handeln, die irgendwo im Netzwerkdateisystem 24 von Figur 1 gespeichert ist. In einem solchen Fall würde die Routine, welche den Schritt 102 in Figur 8 ausführt, die Netzwerkadresse und den Dateinamen für die Datei, auf die zugegriffen werden soll kennen, um auf die Tabelle von Figur 9 zuzugreifen.
Als nächstes wird der von Block 104 in Figur 8 symbolisierte Prozeß durchgeführt, indem auf die in Figur 11 dargestellte allgemeine Umwandlungsprozedurtabelle zugegriffen wird. Dies ist eine Tabelle, die das Umwandlungsprogramm im Formularmanager identifiziert, das die eigentliche Arbeit der Umwandlung einer primitiven Formularklasse in eine andere primitive Formularklasse durchführt. Diese Tabelle ist so organisiert, daß sie einen einzelnen Eintrag für jedes "von"-"zu"-Formatpaar besitzt. Jeder Eintrag in der Tabelle für ein "von"-"zu"-Paar umfaßt den Namen der Umwandlungsroutine, die die eigentliche Umwandlungsarbeit durchführt. Der durch Block 104 symbolisierte Prozeß umfaßt die Schritte des Nehmens des "von"-"zu"-Paares, das durch den Zugriff auf die formatspezifische Umwandlungstabelle in Schritt 102 bestimmt wird, und das Durchsuchen der Einträge der allgemeinen Umwandlungsprozedurtabelle, bis ein Eintrag mit einer "von"-"zu"-Entsprechung gefunden wird. In diesem Fall entspricht der dritte Eintrag von oben in der Tabelle von Figur 11 dem "von"-"zu"-Formatpaar, das beim Zugriff von Figur 9 gefunden wird. Dieser Eintrag wird gelesen, und es wird festgelegt, daß der Name der Routine, welche diese Umwandlung durchführen soll, ASCII_ETHER lautet. (In vielen Ausführungsformen würde nicht der Name, sondern die Speicheradresse der Routine in der Tabelle gespeichert werden.)
Block 106 in Figur 8 symbolisiert den Prozeß des Aufrufens des durch Schritt 104 identifizierten Umwandlungsprogramms und das Ausführen dieser Umwandlungsroutine, um den Inhalt des in Schritt 100 ausgewählten Feldes mit dem in Schritt 102 identifizierten "zu"- oder Zielformat auszutauschen. Im hypothetischen Beispiel würde die Routine ASCI-ETHER aufgerufen und von Schritt 106 ausgeführt werden. Der Aufruf an diese Routine würde die aktuellen Daten liefern, die in dem Feld, das durch den Prozeß von Schritt 100 ausgewählt wurde, gespeichert ist, d.h. Feld 42 der Instanz eines in Figur 6 dargestellten Formulars, so daß die Textkette "U.S. Open" in ein gepacktes ETHERNET -Format umgewandelt würde.
Als nächstes wird der Test bei Block 108 durchgeführt, um zu bestimmen, ob alle Felder, die primitive Formularklassen enthalten, verarbeitet wurden. Wenn dies der Fall ist, wird die Formatumwandlung des Formulars abgeschlossen, und die Formatumwandlungsroutine wird beendet, wie dies durch den Block 110 symbolisiert ist.
Wenn noch weitere Felder, die primitive Formularklassen enthalten, verarbeitet werden müssen, wird der von Block 112 symbolisierte Prozeß ausgeführt. Dieser Prozeß sucht das nächste Feld, das eine primitive Formularklasse enthält.
Danach werden die von den Blöcken 102, 104, 106 und 108 symbolisierten Schritte durchgeführt, bis alle Felder, die primitive Formularklassen enthalten, in das entsprechende "zu"-Format umgewandelt wurden.
Wie oben erwähnt wird der Prozeß der Suche nach Feldern, die primitive Formularklassen enthalten, der Reihe nach durch das umzuwandelnde Formular hindurch ausgeführt. Wenn das nächste gefundene Feld ein Formular einer konstruierten Klasse enthält, muß diese Formularklasse selbst gesucht werden, bis das erste darin enthaltene Feld mit einer primitiven Formularklasse gefunden wird. Dieser Prozeß wird durch alle Verschachtelungsebenen für alle Felder fortgesetzt, bis alle Felder verarbeitet wurden und alle im Formular gespeicherten Daten in das entsprechende Format umgewandelt wurden. Als Beispiel dafür, wie dies funktioniert, würde der durch den Block 112 in Figur 6 symbolisierte Prozeß im Formular 6 nach Verarbeitung des ersten Feldes 42 als nächstes das Feld 44 finden (auf Felder wird von dem Datenblock verwiesen, der die Klassenkennung für das in diesem Feld gespeicherte Formular enthält, obwohl das Feld sowohl die Klassenkennung als auch die aktuellen Daten oder die Felder und Unterfelder des in diesem Feld gespeicherten Formulars enthält). Man beachte, daß in der jeweiligen Formularklasse, die durch Figur 6 dargestellt ist, das zweite Feld 44 ein konstruiertes Formular enthält, das sich aus mehreren Unterfeldern zusammensetzt. Die Verarbeitung würde danach auf das konstruierte Formular der Klasse 1000 zugreifen, das vom zweiten Feld gespeichert wird, und der Reihe nach durch dieses konstruierte Formular fortgesetzt werden, bis sie das erste Feld davon findet, welches ein Formular einer primitiven Klasse enthält. Im hypothetischen Beispiel von Figur 6 wäre das erste Feld das Unterfeld, welches bei 52 durch die Klassennummer 11 bezeichnet wird. Der von Block 102 symbolisierte Prozeß würde danach die Klasse 11 in der "von"-Spalte in der Tabelle von Figur 9 durchsuchen und festlegen, daß das Zielformat von der Klassendefinition der primitiven Klasse 15 bestimmt wird. Dieses "von"-"zu"-Paar 11-15 würde danach mit den Einträgen der Täbelle von Figur 11 verglichen werden, um einen entsprechenden Eintrag zu finden. Danach würde der Prozeß von Block 106 in Figur 8 das als Float1_ETHER bezeichnete Umwandlungsprogramm ausführen, um den Datenblock bei 60 in Figur 6 in das geeignete paketierte ETHERNET -Format umzuwandeln. Danach würde der Prozeß alle Verschachtelungsebenen durchlaufen.
In Figur 12 ist ein Flußdiagramm für eine typische semantisch abhängige Operation dargestellt. Semantisch abhängige Operationen ermöglichen ein Entkoppeln von Anwendungen, indem sie erlauben, daß eine Anwendung die Daten eines bestimmten Feldes einer Formularinstanz, die von einer fremden Anwendung erzeugt wurden, erhält, soferne der Feldname bekannt ist und die Adresse der Formularinstanz bekannt ist. Die Kommunikationsschnittstelle gemäß den Lehren der Erfindung empfängt Anforderungen für eine semantisch abhängige Operation von den dient-Anwendungen in Form von Get_Field-Aufrufen (Hole Feld) in der bevorzugten Ausführungsform, wo alle Prozesse die selben Feldnamen für Datenfelder verwenden, die die selbe Bedeutung haben (und zwar unabhängig von der Organisation des Formulars oder der Datendarstellung des Feldes im Formular, das von dem fremden Prozeß erstellt wurde). In alternativen Ausführungsformen wird eine Alias- oder Synonymtabelle oder eine Datenbank verwendet. In solchen Ausführungsformen wird der Get_Field-Aufruf dazu verwendet, um auf die Synonymtabelle im Klassenmanager zuzugreifen und nach allen Synonymen im angeforderten Feldnamen zu suchen. Alle Feldnamen, die Synonyme des angeforderten Feldnamens sind, werden zurückgegeben. Danach durchsucht der Klassenmanager die Klassendefinition nach einer übereinstimmung entweder mit dem angeforderten Feldnamen oder einem der Synonyme und holt das Feld mit dem übereinstimmenden Feldnamen.
Im Hinblick auf die bevorzugten Ausführungsform können solche Get_Field-Aufrufe direkt von Client- Anwendungen an Formularklassenmanagermodule, wie z.B. das Modul 122 in Figur 1, gestellt werden, oder sie können an die Kommunikationskomponenten oder Formularmanagermodule gestellt und von diesen Modulen an den Formularklassenmanager übertragen werden. Der Formularklassenmanager erzeugt, zerstört, manipuliert, speichert und liest Formularklassendefinitionen.
Ein Get_Field-Aufruf liefert dem Formularklassenmanager die Adresse des fraglichen Formulars und den Namen des Feldes in dem entsprechenden Formular. Das Empfangen einer solchen Anforderung ist durch den Block 120 in Figur 12 symbolisiert. Block 120 symbolisiert auch den Prozeß, durch den dem Klassenmanager die Klassendefinition entweder programmatisch, d.h. durch die anfordernde Anwendung, gegeben wird, oder indem ihm die Position einer Datenbank mitgeteilt wird, in der die Klassendefinitionen einschließlich der Klassendefinition für das entsprechende Formular zu finden sind. Im Netzwerkdateisystem 24 von Figur 1 können mehrere Datenbanken oder Dateien vorhanden sein, in denen Klassendefinitionen gespeichert sind. Es ist nur notwendig, dem Formularklassenmanager die Position der jeweiligen Datei mitzuteilen, in der die Klassendefinition für das entsprechende Formular gespeichert ist.
Als nächstes greift, wie dies durch den Block 122 symbolisiert ist, das Klassenmanagermodul auf die Klassendefinition für die im ursprünglichen Aufruf identifizierte Formularklasse zu.
Danach durchsucht der Klassenmanager die Klassendefinitionsfeldnamen, um eine Entsprechung für den im ursprünglichen Aufruf angegebenen Feldnamen zu finden. Dieser Prozeß wird durch den Block 124 symbolisiert.
Nachdem das entsprechende Feld in der Klassendefinition gefunden wurde, gibt der Klassenmanager einen relativen Adreßzeiger zu dem entsprechenden Feld in den Instanzen der Formulare dieser Klasse zurück. Dieser Prozeß wird durch den Block 126 in Figur 12 symbolisiert. Der vom Klassenmanager zurückgegebene relative Adreßzeiger ist am besten durch Bezugnahme auf Figur 2, 4 und 6 zu verstehen. Nehmen wir an, die Anwendung, welche den Get_Field-Aufruf gemacht hat, wäre daran interessiert, das Alter eines bestimmten Spielers zu bestimmen. Die Get_Field-Anforderung würde die Adresse für die Instanz des Formulars der Klasse 1002 für den Spieler Blackett identifizieren, wie dies in Figur 6 dargestellt ist. In der Get_Field-Anforderung wäre auch der Name des entsprechenden Feldes, nämlich "Age" (Alter), enthalten. Der Klassenmanager würde daraufhin auf die Instanz des entsprechenden Formulars zugreifen und die Klassennummer lesen, welche den jeweiligen Klassendeskriptor oder die Klassendefinition kennzeichnet, die für diese Klasse an Formularen gültig ist. Der Klassenmanager würde dann auf den Klassendeskriptor für die Klasse 1002 zugreifen und eine Klassendefinition finden, wie dies in Figur 4 dargestellt ist. Daraufhin würde der Klassenmanager auf die Klassendefinitionen für die einzelnen Felder der Klassendefinition 1002 zugreifen und den Feldnamen in der ursprünglichen Get_Field-Anforderung mit den Feldnamen in den verschiedenen Klassendefinitionen vergleichen, aus denen sich die Klassendefinition für die Klasse 1002 zusammensetzt. In anderen Worten würde der Klassenmanager die Namen der Felder in den Klassendefinitionen für die Klassen 10, 1000 und 1001 mit dem entsprechenden Feldnamen "Age" (Alter) vergleichen. Wie in Figur 2 erkennbar ist, würde eine Entsprechung in der Klassendefinition für die Klasse 1000 gefunden werden. Für das entsprechende Datensatzformat, welches in Figur 6 dargestellt ist, wäre das "Age"-Feld der Datenblock 62, welcher der zehnte Datenblock ab Beginn des Datensatzes ist. Der Klassenmanager würde danach einen relativen Adreßzeiger von 10 in Black 126 von Figur 12 zurückgeben. Dieser relative Adreßzeiger wird zur dient-Anwendung zurückgeben, die den ursprünglichen Get_Field-Aufruf machte. Dann gibt die dient-Anwendung einen Get_Data-Aufruf an das Formularmanagermodul zurück und liefert dem Formularmanagermodul die relative Adresse des gewünschten Feldes in der entsprechenden Instanz des entsprechenden Formulars. Das Formularmanagermodul muß auch die Adresse der Instanz des gewünschten Formulars kennen, die es bereits hat, wenn der ursprüngliche Get_File-Aufruf durch das Formularmanagermodul kam und zum Formularklassenmanager übertragen wurde. Wenn das Formularmanagermodul die Adresse der entsprechenden Instanz des gewünschten Formulars nicht kennt, fordert der Formularmanager diese von der dient-Anwendung an. Nachdem er den Get_Call-Aufruf empfangen und die relative Adresse und die Adresse der Instanz des gewünschten Formulars erhalten hat, greift der Formularmanager auf diese Instanz des Formulars und auf die angeforderten Daten zu und gibt diese an die dient-Anwendung zurück. Dieser Prozeß des Empfangens des Get_Data-Aufrufs und des Zurückgebens der entsprechenden Daten wird durch Block 128 in Figur 12 symbolisiert.

DATENVERTEILUNGS- UND SERVICEPROTOKOLLENTKOPPELUNG DURCH GEGENSTANDSBASIERTE ADRESSIERUNG UND VERWENDUNG DER SERVICE-DISZIPLINPROTOKOLLSCHICHTEN

In Figur 14 ist ein Blockdiagramm der verschiedenen Softwaremodule, Dateien, Netzwerke und Computer dargestellt, die zusammenarbeiten, um zwei wichtige Formen der Entkoppelung zu implementieren. Bei diesen Formen der Entkoppelung handelt es sich um die Datenverteilungsentkoppelung und die Serviceprotokollentkoppelung. Die Datenverteilungsentkoppelung bedeutet, daß die dient-Anwendungen von der Notwendigkeit befreit werden, die Netzwerkadressen von Servern, welche die gewünschten Dienste anbieten, zu kennen. Wenn daher eine bestimmte Anwendung Informationen kennen muß, die zum Beispiel vom Dow Jones News Service zur verfügung gestellt werden, muß die dient-Anwendung nicht wissen, welche Server und welche Lokationen Daten von der ursprungsdatenversorgung des Dow Jones News Service anbieten.
Die Serviceprotokollentkoppelung bedeutet, daß die Client-Anwendungen die jeweiligen Kommunikationsprotokolle, die zur Durchquerung aller Netzwerkprotokollschichten notwendig sind, und die von den Servern, Services oder anderen Anwendungen, mit denen ein Datenaustausch erwünscht ist, verwendeten Kommunikationsprotokolle nicht kennen müssen.
Die Datenverteilungsentkoppelung wird durch das Kommunikationsmodul 30 in Figur 14 implementiert. Die Kommunikationskomponente setzt sich aus einer Bibliothek von Softwareroutinen, die einen Gegenstandsabbilder 160 implementieren, und einer Mehrzahl von Service-Disziplinen zusammen, um eine gegenstandsbasierte Adressierung zu implementieren. Die Service-Disziplinen 182, 184 und 186 sind beispielhaft für die bei der gegenstandsbasierten Adressierung involvierten Service-Disziplinen.
Die gegenstandsbasierte Adressierung ermöglicht es, daß Services durch alternative Services modifiziert oder ersetzt werden, die gleichwertige Informationen liefern, ohne daß dies Auswirkungen auf die Informationskonsumenten hätte. Diese Entkoppelung der Informationskonsumenten von den Informationslieferanten ermöglicht einen höheren Grad an Modularisierung und Flexibilität als herkömmliche serviceorientierte Modelle.
Die gegenstandsbasierte Adressierung beginnt mit einem Subskriptionsaufruf 188 an den Gegenstandsabbilder 180 durch eine dient-Anwendung 113, die auf einem Host- Comuter 10 läuft. Der Subskriptionsaufruf ist eine Anforderung von Informationen bezüglich eines bestimmten Gegenstandes. Nehmen wir an, bei dem betreffenden Gegenstand handelte es sich um equity.IBM.news. Dieser Subskriptionsauf ruf würde zwei Parameter an den Gegenstandsabbilder 180 weiterleiten. Einer dieser Parameter wäre der Gegenstand equity.IBM.news. Der andere Parameter wäre der Name einer Rückrufroutine in der dient-Anwendung 16, an welche Daten bezüglich des Gegenstandes weiterzuleiten wären. Der Subskriptionsaufruf an den Gegenstandsabbilder 180 ist ein standardmäßiger Prozeduraufruf.
Zweck des Gegenstandsabbilders ist es, die Netzwerkadresse für Services zu bestimmen, die Informationen über verschiedene Gegenstände bieten, und die entsprechenden Service-Disziplinroutinen auf zurufen, um die Kommunikation mit diesen Services herzustellen. Um die Positionen der Services zu finden, die Informationen bezüglich des im Subskriptionsaufruf enthaltenen Gegenstandes anbieten, sendet der Gegenstandsabbilder 80 eine Anforderung, die durch die Linie 190 symbolisiert ist, an eine Verzeichnis-Services- Komponente 192. Bei der Verzeichnis-Services-Komponente handelt es sich um einen separaten Prozeß, der auf einem Computer läuft, der an das Netzwerk 14 angekoppelt ist und eigentlich auf einem separaten Computer oder auf dem Host- Computer 10 selbst laufen kann. Die Verzeichnis-Service- Routine verwaltet eine Datenbank oder eine Tabelle mit Datensätzen, die als Service-Datensätze bezeichnet werden, welche angeben, welche Services Informationen über welche Gegenstände liefern, wo sich diese Services befinden, und welche Service-Disziplinen von diesen Services für die Kommunikation verwendet werden. Die Verzeichnis-Services- Komponente 192 empfängt die vom Gegenstandsabbilder 180 weitergeleitete Anforderung und verwendet den Gegenstandsparameter dieser Anforderung, um ihre Tabellen nach einer Übereinstimmung zu durchsuchen. Das heißt, die Verzeichnis-Services-Komponente 192 durchsucht ihre Service- Datensätze, bis ein Service-Datensatz gefunden wird, der ein bestimmtes Service oder Services anzeigt, die Informationen über den gewünschten Gegenstand zur Verfügung stellen. Dieser Service-Datensatz wird daraufhin zum Gegenstandsabbilder zurückgegeben, wie dies durch die Linie 194 symbolisiert ist. Die Verzeichnis-Services-Komponente kann mehrere Übereinstimmungen finden, falls mehrere Services Informationen bezüglich des gewünschten Gegenstandes liefern.
Der zum Gegenstandsabbilder zurückgegebene Service- Datensatz oder die Service-Datensätze, die durch die Linie 194 symbolisiert sind, enthalten viele Felder. Zwei in den Service-Datensätzen erforderliche Felder sind der Name des Services, das Informationen über den gewünschten Gegenstand liefert, und der Name der Service-Disziplin, die von diesem Service verwendet wird. Andere optionale Felder, die zur Verfügung gestellt werden können, sind der Name des Servers, auf dem das besagte Service läuft, und eine Position im Netzwerk jenes Servers.
Im allgemeinen liefert die Verzeichnis-Services- Komponente alle Service-Datensätze, für die eine Gegenstandsabbildung vorhanden ist, da möglicherweise keine vollständige überlappung der Informationen, die von allen Services über den Gegenstand zur Verfügung gestellt werden, gegeben ist. Des weiteren läuft jedes Service auf einem separaten Server, der über dasselbe Netzwerk an die Client- Anwendung angekoppelt sein kann, aber nicht angekoppelt sein muß. Wenn eine solche Vielzahl an Netzwerkpfaden und Services vorhanden ist, ermöglicht die Rückleitung aller Service-Datensätze mit Übereinstimmungen im Gegenstandsbereich an den Gegenstandsabbilderf daß die Kommunikationsschnittstelle die Netzwerke oder Server oder Services wechselt, wenn es zu einem Ausfall eines oder mehrerer dieser Komponenten kommen sollte.
Wie oben erwähnt errichtet der Gegenstandsabbilder 180 eine Kommunikation mit all jenen Services, die Informationen über den gewünschten Gegenstand zur Verfügung stellen. Wenn mehrere Service-Datensätze vom Verzeichnis- Services-Modul 192 zurückgegeben werden, errichtet der Gegenstandsabbilder 160 eine Kommunikation mit all diesen Services.
Bei Empfang der Service-Datensätze ruft der Gegenstandsabbilder jede einzelne identifizierte Service- Disziplin auf und leitet dieser den für diese Service- Disziplin entsprechenden Gegenstand und den entsprechenden Service-Datensatz weiter. Obwohl in Figur 14 nur drei Service-Disziplinen 182, 184 und 186 dargestellt sind, können in einem tatsächlichen System weit mehr als drei vorhanden sein.
Sollte die Verzeichnis-Services-Komponente 192 nicht vorhanden sein oder keine Übereinstimmung finden, werden keine Service-Datensätze an den Gegenstandsabbilder 180 zurückgegeben. In einem solchen Fall ruft der Gegenstandsabbilder eine standardmäßige Service-Disziplin auf und leitet sie und den Gegenstand und einen Null-Datensatz weiter.
Jede Service-Disziplin ist ein Software-Modul, das maßgeschneiderten Code enthält, der für die Kommunikation mit dem entsprechenden Service, das mit dieser Service- Disziplin im Zusammenhang steht, optimiert ist.
Jede vom Gegenstandsabbilder 120 aufgerufene Service-Disziplin überprüft die Service-Datensätze, die an sie weitergeleitet werden, und bestimmt die Position des Services, mit dem eine Kommunikation herzustellen ist. Nehmen wir an, daß in dem besprochenen hypothetischen Beispiel nur ein Service-Datensatz vom Verzeichnis-Services-Modul 192 zurückgegeben wird und daß dieser Service-Datensatz den Dow Jones News Service identifiziert, der am Server 196 läuft, und weiter die Service-Disziplin A bei 182 als für die Kommunikation mit dem Dow Jones News Service am Server 196 geeignete Service-Disziplin identifiziert. Die Service- Disziplin A leitet daraufhin eine Anforderungsnachricht an den Server 196 weiter, wie dies durch die Linie 198 identifiziert ist. Diese Anforderungsnachricht leitet den Gegenstand zum Service weiter und kann den gesamten oder teilweisen Service-Datensatz weiterleiten.
Der Server 196 verarbeitet die Anforderungsnachnaht und bestimmt, ob sie tatsächlich Informationen über den gewünschten Gegenstand liefern kann. Danach sendet er eine Antwortnachricht zurück, die durch die Linie 200 symbolisiert ist.
Nachdem die Kommunikation auf diese Weise hergestellt wurde, sendet das Service alle Informationskomponenten, die zum angeforderten Gegenstand gehören, kontinuierlich zur entsprechenden Service-Disziplin, wie dies durch den Pfad 202 symbolisiert ist. In dem hier ausgewählten Beispiel filtert der auf dem Server 196 laufende Service nur jene neuen Komponenten heraus, die zu IBM gehören, um diese bei 182 zur Service-Disziplin zu senden.
Jede Service-Disziplin kann ein anderes Verhalten aufweisen. Zum Beispiel kann die Service-Disziplin B bei 184 folgendes Verhalten aufweisen. Das am Server 196 laufende Service kann alle Informationskomponenten des Dow Jones News Service am Netzwerk 14 ausstrahlen. Alle Instanzen der Service-Disziplin B können das Netzwerk überwachen und nur jene Nachrichten herausfiltern, die zum gewünschten Gegenstand gehören. Es sind viele unterschiedliche Kommunikationsprotokolle möglich.
Die Service-Disziplin A bei 182 empfängt die Daten, die vom Service übertragen werden, und leitet sie an die genannte Rückrufroutine 204 in der dient-Anwendung 16 weiter. (Vom Abbilder 180 wurde der Name der Rückrufroutine in der ursprünglichen Nachricht an die Service-Disziplin 182 weitergeleitet, was durch die Linie 181 symbolisiert ist.) Danach führt die genannte Rückrufroutine mit den Informationen über den gewünschten Gegenstand all das aus, wozu sie programmiert wurde.
Daten fließen auf diese Weise solange zur genannten Rückrufroutine 204 weiter, bis die dient-Anwendung 16 ausdrücklich einen Aufheben-Befehl an den Gegenstandsabbilder 180 ausgibt. Der Gegenstandsabbilder 160 zeichnet alle vorhandenen Subskriptionen auf und vergleicht den Aufheben- Befehl mit den verschiedenen aktiven Subskriptionen. Wenn eine Übereinstimmung gefunden wird, wird die entsprechende Service-Disziplin über die Aufheben-Anforderung benachrichtigt, und diese Service-Disziplin sendet daraufhin eine Aufheben-Nachricht an den entsprechenden Server. Das Service beendet daraufhin die Übertragung weiterer Daten bezüglich dieses Gegenstandes zur Service-Disziplin, die die Aufheben-Anforderung gesendet hat.
Es ist auch möglich, daß eine Service-Disziplin freistehend und nicht an einen Gegenstandsabbilder gekoppelt ist. In diesem Fall werden die Service-Disziplin oder die Service-Disziplinen direkt mit der Anwendung verknüpft, und Subskriptionsaufrufe werden direkt an die Service- Disziplin gesandt. Der Unterschied liegt darin, daß die Anwendung den Namen des Services kennen muß, das die gewünschten Daten liefert, und der Service-Disziplin, die für den Zugriff auf das Service verwendet wird. Daraufhin wird auf eine Datenbank oder eine Verzeichnis-Services-Tabelle zugegriffen, um die Netzwerkadresse des identifizierten Services zu suchen, und die Kommunikation wird wie oben beschrieben errichtet. Diese Software-Architektur bietet zwar keine Datenverteilungsentkoppelung, wohl aber eine Serviceprotokollentkoppelung, wodurch sie die Anwendung von der Notwendigkeit befreit, Einzelheiten über die Kommunikationsschnittstelle mit dem Service kennen zu müssen, mit dem Daten ausgetauscht werden sollen.
Weitere Einzelheiten über die von der Kommunikationsschnittstelle ermöglichte gegenstandsbasierte Adressierung von Subskriptionsservices gemäß den Lehren der Erfindung sind in Abschnitt 4 der untenstehenden Kommunikationsschnittstellenbeschreibung enthalten. Die bevorzugte Ausführungsform der Kommunikationsschnittstelle der Erfindung wird gemäß dieser Beschreibung konstruiert.
Eine aktuelle Subskriptionsfunktion in der bevorzugten Ausführungsform erfolgt durch Ausführung der TIB_Consume_Create Bibliotheksroutine, die in Abschnitt 4 der Beschreibung beschrieben wird. Der Aufruf an TIB_Consume_Create umfaßt eine Eigenschaftenliste der Parameter, die dorthin weitergeleitet werden, von denen einer die Identität der Rückrufroutine ist, die als My_Message_Handler in Abschnitt 4 der Beschreibung beschrieben wird.
In der Beschreibung wird die gegenstandsbasierte Adressierung der Subskriptionsservicefunktion als TIBINFO bezeichnet. Die TIBINFO-Schnittstelle besteht aus zwei Bibliotheken. Die erste Bibliothek wird als TIBINFO-CONSUME für Datenverbraucher bezeichnet. Die zweite Bibliothek wird als TIBINFO-PUBLISH für Datenlieferanten bezeichnet. Eine Anwendung umfaßt die eine Bibliothek oder die andere oder beide. Dies hängt davon ab, ob sie ein Verbraucher oder ein Lieferant oder beides ist. Eine Anwendung kann gleichzeitig Verbraucher und Lieferant sein.
In Figur 15 ist ein Blockdiagramm der Beziehung der Kommunikationsschnittstelle gemäß den Lehren der Erfindung zu Anwendungen und dem Netzwerk dargestellt, das diese Anwendungen miteinander verbindet. Blöcke mit gleicher Referenzbezeichnung wie Blöcke in Figur 1 weisen ähnliche Funktionseigenschaften auf wie jene Blöcke von Figur 1.
Das Blockdiagramm in Figur 15 zeigt die Prozeßarchitektur der bevorzugten Ausführungsform. Die Softwarearchitektur, welche der in Figur 15 dargestellten Architektur entspricht, ist in Figur 16 in Blockform dargestellt.
Bezug nehmend auf Figur 15 ist die Kommunikationskomponente 30 von Figur 1 als zwei separate Funktionsblöcke 30A und 308 in Figur 15 dargestellt. Das heißt, die Funktionen der Kommunikationskomponente 30 in Figur 1 sind in der Prozeßarchitektur von Figur 15 zwischen zwei funktionalen Blöcken aufgeteilt. Eine Kommunikationsbibliothek 30A ist mit jeder dient-Anwendung 16 verknüpft, und ein Daemon-Prozeß 308 für die Kommunikation am letzten Teil ist mit dem Netzwerk 14 und der Kommunikationsbibliothek 30A verknüpft. Typischerweise ist pro Host-Prozessor ein Kommunikationsdaemon vorhanden. Dieser Host-Prozessor ist bei 230 in Figur 15 dargestellt, aber in Figur 16 nicht vorhanden. Man beachte, daß die dient-Anwendungen 16 und 18 in Figur 15 im Gegensatz zu der Situation in Figur 1 beide am selben Host-Prozessor 230 laufen. Jede dient-Anwendung ist mit ihren eigenen Kopien der verschiedenen Bibliotheksprogrammen in den Kommunikationsbibliotheken 30A und 96 und der Formularbibliothek der Datenaustauschkomponenten 32 und 88 verknüpft. Diese verknüpften Programmbibliotheken verwenden gemeinsam den Kommunikationsdaemon 30B.
Die Kommunikationsdaemons in den verschiedenen Host-Prozessoren arbeiten untereinander zusammen, um eine zuverlässige und effiziente Kommunikation zwischen den Maschinen zu gewährleisten. Bei gegenstandsadressierten Daten unterstützen die Daemons die effiziente Übertragung, indem sie eine Systemunterstützung auf niedriger Ebene für die Filterung von Nachrichten nach Gegenständen zur Verfügung stellen.
Die Kommunikationsbibliothek 30A führt zahlreiche Funktionen durch, die den einzelnen anwendungsorientierten Kommunikationsfolgen zugeordnet sind. Zum Beispiel übersetzt die Kommunikationsbibliothek Gegenstände in effiziente Nachrichtenkopfzeilen, die kompakter und leichter zu prüfen sind als ASCII-Gegenstandswerte. Die Kommunikationsbibliothek bildet auch Serviceanforderungen in Anforderungen ab, die auf bestimmte Service-Instanzen abzielen, und überwacht den Status dieser Instanzen.
Die Datenaustauschkomponente 32 der Kommunikationsschnittstelle gemäß den Lehren der Erfindung wird als Bibliothek implementiert, die als "Formularbibliothek" bezeichnet wird. Diese Bibliothek ist mit der Client- Anwendung verknüpft und bietet alle Kernfunktionen der Datenaustauschkomponente an. Die Formularbibliothek kann unabhängig von der Kommunikationsbibliothek verknüpft werden und benötigt für ihren Betrieb nicht den Kommunikationsdaemon 308.
Der Kommunikationsdaemon führt zwei Aufgaben aus. Im oben beschriebenen gegenstandsbasierten Adressiermodus, bei dem die Service-Instanz über den Gegenstand und die Netzwerkadresse, an welche Daten bezüglich dieses Gegenstandes zu schicken sind, informiert wurde, besitzt der Kommunikationsdaemon 308 die Netzwerkadresse, an welche die Daten zu schicken sind. Diese Daten werden daraufhin vom Daemon an die Kommunikationsbibliothek, welche an die Client-Anwendung gebunden ist, weitergeleitet, welche wiederum die Daten zur entsprechenden Rückrufroutine in der Client- Anwendung leitet. In einem anderen Modus filtert der Kommunikationsdaemon die Daten, die vom Netzwerk 14 einlangen, nach dem Gegenstand, wenn sich die Service-Instanzen, welche Daten liefern, in einem Rundfunk-Modus (allgemeiner Versand) befinden und Daten über viele unterschiedliche Gegenstände an alle Daemons im Netzwerk aussenden.
Die Blöcke 231, 233 und 235 in Figur 15 repräsentieren die Schnittstellenfunktionen, die von den Programmen in der Kommunikationsbibliothek 30A und der Formularbibliothek 32 implementiert werden. Die TIBINFO-Schnittstelle 233 bietet gegenstandsbasierte Adressierservices über das Kommunikationsparadigma an, welches als Subskriptionsaufruf bekannt ist. In diesem Paradigma abonniert ein Datenverbraucher ein Service oder einen Gegenstand und erhält daraufhin einen kontinuierlichen Datenstrom über das Service oder den Gegenstand, bis der Verbraucher ausdrücklich die Subskription beendet (oder ein Fehler auftritt). Ein Subskriptionsparadigma eignet sich sehr gut für Echtzeitanwendungen, die sich dynamisch ändernde Werte, wie zum Beispiel Aktienpreise, überwachen. Im Gegensatz dazu eignet sich die herkömmlichere Anfrage-/Antwort-Kommunikation schlecht für solche Echtzeit-Anwendungen, da diese von den Datenverbrauchern verlangen, Datenlieferanten "abzufragen", um über Änderungen informiert zu werden.
Die Schnittstelle 235 definiert eine programmatische Schnittstelle zur Protokoligruppe und zum Service, aus dem sich die Marktdatensubskriptionsservice- (MDSS) Unterkomponente 234 in Figur 16 zusammensetzt. Diese Service- Disziplin wird später noch umfassend beschrieben werden. Die RMDP-Schnittstelle 235 ist insoferne ein Serviceadreßprotokoll, als sie verlangt, daß die Client-Anwendung den Namen des Services, mit dem Daten ausgetauscht werden sollen, kennen muß.
In Figur 16 ist die Softwarearchitektur des Systems dargestellt. Eine verteilte Kommunikationskomponente 232 umfaßt verschiedene Protokoll-Engines 237, 239 und 241. Eine Protokoll-Engine kapselt ein Kommunikationsprotokoll ein, das eine Schnittstelle zwischen Service-Disziplin- Protokollen und den jeweiligen Netzwerkprotokollen darstellt. Die verteilte Komponente 232 ist an eine Vielzahl von Service-Disziplinen 234, 236 und 238 gekoppelt. Die Service-Disziplin 234 weist das Verhalten auf, das im folgenden als Marktdatensubskriptionsservice bezeichnet wird. Dieses Protokoll ermöglicht es, daß Datenverbraucher einen kontinuierlichen Datenstrom mit Toleranz gegenüber einzelnen Datenguellen empfangen können. Diese Protokollgruppe stellt Mechanismen für die Verwaltung der Lastausgleichsund Berechtigungspolitik zur Verfügung.
Die Service-Disziplin mit der Bezeichnung MSA, 236, besitzt ein wiederum anderes Verhalten. Die Service- Disziplin mit der Bezeichnung SASSII, 238, unterstützt, wie oben beschrieben, gegenstandsbasierte Adreßsubskriptionsservices.
Die in Figur 15 und 16 dargestellte Softwarearchitektur stellt eine alternative Ausführungsform zu der oben unter Bezugnahme auf Figur 1-14 beschriebenen Ausführungsform dar.
Normalerweise speichern Klassenmanagermodule die für die semantisch abhängigen Operationen im RAM der Host- Maschine erforderlichen Klassendefinitionen als Klassendeskriptoren. Klassendefinitionen sind die Beschreibung der semantischen Informationen und der Formatinformationen, die eine Klasse definieren. Klassendeskriptoren sind Speicherobjekte, die die Klassendefinition verkörpern. Klassendeskriptoren werden auf mindestens zwei Arten gespeichert. Im Direktzugriffsspeicher (PAM) werden Klassendeskriptoren als Formulare in einem nativen Format der Maschine und der dient-Anwendung, welche die Klassendefinition erzeugt hat, gespeichert. Auf Platte oder Band gespeicherte Deskriptoren werden als Text in ASCII-Zeichenketten gespeichert.
Wenn das Klassenmanagermodul aufgefordert wird, eine semantisch abhängige Operation auszuführen, durchsucht es seine im PAM gespeicherten Klassendeskriptoren und bestimmt, ob der entsprechende Klassendeskriptor vorhanden ist. Wenn dies der Fall ist, wird der Klassendeskriptor verwendet, um die oben unter Bezugnahme auf Figur 12 beschriebene Operation durchzuführen. Wenn der geeignete Klassendeskriptor nicht vorhanden ist, muß der Klassenmanager ihn erlangen. Dies geschieht, indem er bekannte Dateien der Klassendeskriptoren durchsucht, die in den Systemdateien 24 in Figur 1 gespeichert sind, oder indem er eine Anforderung an die fremde Anwendung, welche die Klassendefinition erstellt hat, macht, die Klassendefinition an das anfordernde Modul zu senden. Die Positionen der Dateien, welche Klassendeskriptoren speichern, sind den Client- Anwendungen bekannt, und auch die Klassenmanagermodule speichern diese Adressen. Oft enthält die Anforderung für eine semantisch abhängige Operation die Adresse der Datei, in der der entsprechende Klassendeskriptor gefunden werden kann. Wenn die Anforderung keine derartige Adresse enthält, durchsucht der Klassenmanager seine eigenen gespeicherten Klassendeskriptoren und die Dateien, welche in vom Klassenmanager gespeicherten Datensätzen bezeichnet werden, die die Positionen von Systemklassendeskriptordateien angeben.
Wenn der Klassenmanager den Klassendeskriptor von der fremden Anwendung, die ihn erzeugt hat, anfordert, sendet die fremde Anwendung eine Anforderung an ihren Klassenmanager, den entsprechenden Klassendeskriptor über das Netzwerk zum anfordernden Klassenmanager oder zum anfordernden Modul zu schicken. Der Klassendeskriptor wird daraufhin wie jedes andere Formular verschickt und von dem anfordernden Klassenmanager dazu verwendet, die angeforderte semantisch abhängige Operation auszuführen.
Wenn der Klassenmanager auf eine Datei zugreifen muß, um einen Klassendeskriptor zu erhalten, muß er auch die gepackte ASCII-Darstellung, in der die Klassendeskriptoren auf Platte oder Band gespeichert sind, in das Format eines nativen Formulars zur Speicherung im RAM umwandeln. Dies geschieht durch Zergliederung des ASCII-Textes, um die verschiedenen Feldnamen und Beschreibungen des Feldinhalts und der Klassennummern auszusondern.
Figur 13A und 13B zeigen eine Klassendefinition und die Struktur und Organisation eines Klassendeskriptors für die Klassendefinition von Figur 13A und die Speicherung im RAM als Formular. Die in Figur 13A angegebene Klassendefinition trägt die Bezeichnung Person_Class und besitzt nur zwei Felder, nämlich Last und First. Für jedes dieser Felder wird festgelegt, daß es eine 20 Zeichen lange ASCII- Textkette speichert.
Figur 13B besitzt einen Datenblock 140, der 1021 enthält, was anzeigt, daß das Formular ein konstruiertes Formular mit der Klassennummer 1021 ist. Der Datenblock bei 142 zeigt an, daß das Formular 3 Felder besitzt. Das erste Feld enthält eine primitive Klasse, für die festgelegt ist, daß sie eine ASCII-Textkette enthält, die den Klassennamen, Person_Class, im Datenblock 146 speichert. Das zweite Feld ist eine primitive Klasse, der die Nummer 2, Datenblock 148, zugeordnet ist, für die festgelegt ist, daß sie einen Boolschen Wert, Datenblock 150, enthält. Semantisch ist das zweite Feld in der Klassendefinition für die Klasse 1021 definiert, um festzulegen, ob die Formularklasse primitiv (wahr) oder konstruiert (falsch) ist. In diesem Fall ist der Datenblock 150 falsch, was anzeigt, daß die Klasse 1021 eine konstruierte Klasse ist. Das dritte Feld ist eine konstruierte Klasse, der die Klassennummer 112 zugewiesen ist, wie dies durch den Datenblock 152 dargestellt ist. Die Klassendefinition für die Klasse 1021 definiert das dritte Feld als ein konstruiertes Klassenformular, das die Namen und Beschreibungen für die Felder in der Klassendefinition angibt. Der Datenblock 154 zeigt an, daß zwei Felder in einem Formular der Klasse 112 vorhanden sind. Das erste Feld der Klasse 112 ist selbst eine konstruierte Klasse, der die Klassennummer 150, Datenblock 156, zugewiesen ist, und die zwei Unterfelder, Datenblock 158, besitzt. Das erste Unterfeld ist eine primitive Klasse 15, Datenblock 160, die in der Klassendefinition für die Klasse 150 so beschrieben wird, daß sie den Namen des ersten Feldes in der Klasse 1021 enthält. Der Datenblock 162 teilt den Namen des ersten Feldes in der Klasse 1021 mit. Das zweite Unterfeld ist eine primitive Klasse 15, Datenblock 164, und wird in der Klassendefinition der Klasse 150 (nicht dargestellt) als ein Feld beschrieben, das eine ASCI-Zeichenkette enthält, welche die Darstellung, Datenblock 166, der im ersten Feld der Klasse 1021 gespeicherten aktuellen Daten beschreibt. Das zweite Feld der Klasse 112 wird in der Klassendefinition der Klasse 112 als ein Feld beschrieben, das ein konstruiertes Formular der Klasse 150, Datenblock 168, enthält, das zwei Felder, Datenblock 170, besitzt, die den Namen des nächsten Feldes in der Klasse 1021 mitteilen und den Darstellungstyp der in diesem zweiten Feld gespeicherten aktuellen Daten beschreiben.

BESCHREIBUNG

Nun folgt eine ausführlichere Beschreibung der verschiedenen Bibliotheksprogramme und der Gesamtstruktur und Funktionsweise einer Ausführungsform der Kommunikationsschnittstelle gemäß den Lehren der Erfindung.
Information Driven Architecture , Teknekron Information BUS , TIB , TIBINFO , TIBFORMS , SubjectBased Addressing und RMDP sind Warenzeichen von Teknekron Software Systems, Inc.

INHALT

1. Einleitung
2. Architektur des Teknekron Information Bus
3. Reliable Market Data Protocol: RMDP
4. Gegenstandsadressiertes Subskriptionsservice: TIBINFO
5. Datenaustauschkomponente: TIBFORM
6. Anhang: 'man' Seiten

1. Einleitung

Die Teknekron Information Bus Software ist eine verteilte Softwarekomponente, welche dazu geschaffen ist, den Austausch von Daten zwischen Anwendungen, die in einer verteilten Echtzeitumgebung ausgeführt werden, zu erleichtern. Sie wird auf Kommunikationsprotokolle des Industriestandards (TCP/IP) und Datenaustauschstandards (z.B. X.400) aufgesetzt.
Dieses Dokument beschreibt eine "Vorabversion" der TIB Anwendungsprogrammierschnittstelle (Application Programmatic Interface - API) und enthält Schnittstellenbeschreibungen aller TIB-Kernkomponenten. Es wurde nur zu Informationszwecken veröffentlicht. Der Leser sollte beachten, daß Änderungen an den hierin beschriebenen Schnittstellen vorbehalten sind. Wenngleich Teknekron keine größeren Änderungen an der hierin enthaltenen Schnittstellenbeschreibung vorwegnimmt, wird doch erwartet, daß kleinere Änderungen als Ergebnis des Verteilungsprozesses vorgeschlagen und implementiert werden.
Das Dokument ist wie folgt gegliedert. Abschnitt 2 enthält einen Architektur-Überblick über TIB . Abschnitt 3 beschreibt das Reliable Market Data Protokoll (zuverlässiges Marktdatenprotokoll). Dieses Allzeckprotokoll eignet sich besonders gut für die Anforderungen seitenbasierter Marktdatenservices. Weiter wird es auch oft für die Verteilung von Bulletins und Berichten verwendet. Abschnitt 4 beschreibt TIBINFO, eine Schnittstelle, welche Subject-based Addressing (gegenstandsbasierte Adressierung) unterstützt. Abschnitt 5 beschreibt eine Komponente und ihre Schnittstelle, die einen sehr flexiblen und umfassenden Datenaustauschstandard unterstützt. Diese Komponente wird als TIBFORMS bezeichnet. Der Anhang enthält (UNIX-ähnliche) Handbuchseiten für die Kernschnittstellen.

2. Architektur-überblick

2.1 Einleitung

Der Teknekron Information Bus (TIB ) setzt sich aus zwei Hauptkomponenten zusammen: der (anwendungsorientierten) Datenkommunikationskomponente, und der Datenaustauschkomponente. Diese sind in Figur 2.1 dargestellt. Darüber hinaus wurde eine Gruppe von Präsentationswerkzeugen und eine Gruppe von Unterstützungsdienstwerkzeugen rund um diese Komponenten erstellt, um den Anwendungsentwickler beim Schreiben von TIB -basierten Anwendungen zu unterstützen.
Die (anwendungsorientierte) Datenkommunikationskomponente implementiert ein umfangreiches Rahmenwerk zur Implementierung von Kommunikationsprotokollgruppen hoher Ebene. Es wurden zwei Protokollgruppen implementiert, die für die Bedürfnisse fehlertoleranter Echtzeitanwendungen, die über Nachrichten kommunizieren, maßgeschneidert sind. Insbesondere implementieren die Gruppen Subskriptionsservices, die eine Kommunikationsunterstützung für die Uberwachung sich dynamisch ändernder Werte über ein Netzwerk zur Verfügung stellen. Subskriptionsservices implementieren ein Kommunikationsparadigma, das sich für die Verteilung von Marktdaten von zum Beispiel Quotron oder Telerate gut eignet.
Eine der Protokollgruppen unterstützt ein herkömmliches, serviceorientiertes, kooperatives Verarbeitungsmodell. Die andere Protokollgruppe unterstützt direkt ein neuartiges, informationsorientiertes, kooperatives Verarbeitungsmodell durch Implementierung gegenstandsbasierter Adressierung. Unter Verwendung dieses Adressierschemas können Anwendungen durch eine Allzweckschnittstelle Informationen nach Gegenständen anfordern. Die gegenstandsbasierte Adressierung ermöglicht die Entkoppelung von Informationsverbrauchern von Informationserzeugern, wodurch die Modularität und Erweiterbarkeit des Systems erhöht wird.
Die anwendungsorientierten Protokoligruppen sind auf eine allgemeine Gruppe von Kommunikationseinrichtungen aufgesetzt, die als verteilte Kommunikationskomponente bezeichnet werden, welche als Unterschicht in Figur 2.1 dargestellt sind. Diese Schicht bietet ihren Clients nicht nur zuverlässige Kommunikationsprotokolle, sondern auch Positionstransparenz und Netzwerkunabhängigkeit.
Die Schicht wird auf standardmäßige Transportschichtprotokolle (z.B. TCP/IP) aufgesetzt und ist in der Lage, mehrere Transportprotokolle zu unterstützen. Die Datenaustauschkomponente implementiert eine leistungsfähige Art der Darstellung und Übertragung von Daten. Alle Daten werden in selbsbeschreibende Datenobjekte, sogenannte TIB -Formulare oder einfach Formulare, eingekapselt. Da TIB -Formulare selbstbeschreibend sind, erlauben sie die Implementierung allgemeiner Werkzeuge für die Manipulation und Darstellung von Daten. Zu solchen Werkzeugen gehören Kommunikationswerkzeuge zum Senden von Formularen zwischen Prozessen in einem maschinenunabhängigen Format. Da ein selbstbeschreibendes Formular erweitert werden kann, ohne daß dadurch nachteilige Auswirkungen auf die Anwendungen, welche dieses verwenden, entstehen, erleichtern Formulare die Entwicklung modularer Anwendungen sehr.
Die zwei Hauptkomponenten von TIB wurden so konstruiert, daß Anwendungsprogrammierer sie unabhängig voneinander oder gemeinsam verwenden können. Zum Beispiel sind Formulare nicht nur für Kommunikationsanwendungen von Nutzen, die Daten gemeinsam nutzen, sondern auch für nichtkommunizierende Anwendungen, welche die allgemeinen Werkzeuge und modularen Programmiertechniken nutzen möchten, die von Formularen unterstützt werden. Solche Anwendungen benötigen natürlich nicht die Kommunikationsservices von TIB . Auf ähnliche Weise müssen Anwendungen, die zum Beispiel eine gegenstandsbasierte Adressierung verwenden, keine Formulare übertragen, sondern können stattdessen jede beliebige Datenstruktur übertragen. Man beachte, daß die Implementierung der Kommunikationskomponente sehr wohl Formulare verwendet, daß sie aber nicht von Anwendungen verlangt, diese zu benutzen.

2.2 Systemmodell

Das von TIB unterstützte Systemmodell besteht aus Anwendern, Anwendergruppen, Netzwerken, Services, Service- Instanzen (oder Servern) und Gegenständen.
Der Begriff eines Anwenders, der einen menschlichen "Endanwender" repräsentiert, ist in den meisten Systemen zu finden. Ein Anwender wird durch eine Anwenderkennung identifiziert. Die TIB Anwenderkennung ist normalerweise die selbe wie die Anwenderkennung (oder Anmeldekennung), die vom darunterliegenden Betriebssystem unterstützt wird, aber dies muß nicht immer der Fall sein.
Jeder Anwender ist ein Mitglied exakt einer Gruppe. Der dahinterstehende Gedanke ist der, daß sich eine Gruppe aus Anwendern mit ähnlichen Servicezugriffsmustern und Zugriffsrechten zusammensetzt. Zugriffsrechte auf ein Service oder ein Systemobjekt sind auf der Ebene der Anwender und auf der Ebene der Gruppen zuteilbar. Der Systemadministrator ist für die Zuteilung der Anwender zu den Gruppen verantwortlich.
Ein Netzwerk ist ein logisches Konzept, welches durch die darunterliegende Transportschicht definiert und von TIB unterstützt wird. Eine Anwendung kann Daten über jedes beliebige Netzwerk, an dem ihr Host-Computer angeschlossen ist, senden oder empfangen. Es unterstützt auch alle Gateway-Funktionen und Zwischennetzwerkweiterleitungen, die von den darunterliegenden Transportschichtprotokollen unterstützt werden.
Da die unterste Schicht der TIB -Kommunikationskomponente mehrere Netzwerke unterstützt, können anwendungsorientierte Protokolle geschrieben werden, die auf unsichtbare Weise von einem Netzwerk auf ein anderes umschalten, falls es zu einem Netzwerkausfall kommen sollte.
Ein "Service" repräsentiert eine sinnvolle Gruppe von Funktionen, die von einer Anwendung zur Verwendung durch ihre dient-Anwendungen exportiert werden. Beispiele für Services sind Wiederauffinde-Services für historische Neuheiten, ein Quotron Datafeed und ein Trade Ticket Router. Eine Anwendung exportiert typischerweise nur ein Service, obwohl sie viele unterschiedliche Services exportieren kann.
Eine Service-Instanz ist ein Anwendungsprozeßf der in der Lage ist, das jeweilige Service zur verfügung zu stellen. (Manchmal werden diese auch als "Server-Prozesse" bezeichnet.) Für ein gegebenes Service können mehrere Instanzen gleichzeitig das Service zur Verfügung stellen, um dadurch die Leistung zu verbessern oder eine Fehlertoleranz zu ermöglichen. Anwendungsorientierte Kommunikationsprotokolle in TIB können den Begriff eines "fehlertaleranten" Services durch Schaffung einer automatischen Umschaltung von einer ausgefallenen Service-Instanz auf eine funktions fähige, welche das selbe Service bietet, implementieren.
Netzwerke, Services und Server sind traditionelle Komponenten eines Systemmodells und werden in den meisten verteilten Systemen auf die eine oder andere Art und Weise implementiert. Auf der anderen Seite ist der Begriff eines Gegenstandes für das von TIB implementierte Informationsmodell neu.
Der Gegenstandsraum besteht aus einer hierarchischen Gruppe von Gegenstandskategorien. Die aktuelle Version von TIB unterstützt eine Hierarchie mit 4 Ebenen, wie dies durch den folgenden, gut ausgebildeten Gegenstand dargestellt wird: "equity.ibm.composite.trade." TIB schreibt keine Politik bezüglich der Interpretation der unterschiedlichen Gegenstandskategorien vor. Stattdessen besitzen die Anwendungen die Freiheit und Verantwortung, Konventionen bezüglich der Verwendung und Interpretation der verschiedenen Gegenstandskategorien selbst zu errichten.
Jeder Gegenstand ist typischerweise einem oder mehreren Services zugewiesen, die Daten über diesen Gegenstand erzeugen. Die gegenstandsbasierten Protokollgruppen von TIB sind verantwortlich dafür, daß die Anforderung einer Anwendung nach Daten über einen Gegenstand in Kommunikationsverbindungen zu einer oder mehreren Service-Instanzen übersetzt wird, welche Informationen über diesen Gegenstand zur verfügung stellen.
Eine Gruppe von Gegenstandskategorien wird als Gegenstandsdomäne bezeichnet. TIB unterstützt mehrere Gegenstandsdomänen. Diese Tatsache ist zum Beispiel beim Wechel von einer Domäne auf eine andere von Nutzen. Jede Domäne kann domänenspezifische Gegenstandscodierfunktionen für eine wirkungsvolle Darstellung von Gegenständen in Nachrichtenkopfzeilen festlegen.

2.3 Prozeßarchitektur

Die Kommunikationskomponente von TIB ist ein echtes verteiltes System, deren Funktionen zwischen einer vorderen TIB -/Kommunikationsbibliothek, die mit jeder Anwendung verknüpft ist, und einem hinteren TIB -/Kommunikationsdaemonprozeß aufgeteilt ist, wobei hier typischerweise einer pro Host-Prozessor vorhanden ist. Diese Frozeßarchitektur ist in Figur 2.2 dargestellt. Man beachte, daß diese funktionelle Aufteilung zwischen TIB Bibliothek und TIB Daemon für die Anwendung vollkommen unsichtbar ist. In der Tat weiß die Anwendung mit Ausnahme bestimmter Fehlerrückgabecodes überhaupt nicht um die Existenz des TIB -Daemons.
Die TIB -Daemons kooperieren untereinander, um eine zuverlässige und effiziente Kommunikation zwischen den Maschinen zu gewährleisten. Bei gegenstandsadressierten Daten unterstützen sie die effiziente Übertragung, indem sie eine Systemunterstützung auf niedriger Ebene für die Filterung von Nachrichten nach Gegenständen zur Verfügung stellen.
Die TIB /Kommunikationsbibliothek führt zahlreiche Funktionen durch, die den einzelnen anwendungsorientierten Kommunikationsgruppen zugeordnet sind. Zum Beispiel übersetzt die Bibliothek Gegenstände in effiziente Nachrichtenkopfzeilen, die kompakter und leichter zu prüfen sind als ASCII-Gegenstandswerte. Sie bildet auch Serviceanforderungen in Anforderungen ab, die auf bestimmte Service- Instanzen abzielen, und überwacht den Status dieser Instanzen.
Die Datenaustauschkomponente von TIB wird als Bibliothek implementiert, die als TIB /Formularbibliothek bezeichnet wird und mit der Anwendung verknüpft ist. Diese Bibliothek bietet alle Kemfunktionen der Datenaustauschkomponenten und kann unabhängig von der TIB /Kommunikationsbibliothek verknüpft werden. Die TIB /Formularbibliothek benötigt den TIB /Kommunikationsdaemon nicht.

2.4 Kommunikationskomponente

Die TIB Kommunikationskomponente besteht aus 3 Unterkomponenten: der verteilten Kommunikationskomponente (DCC) niedriger Ebene, und den beiden anwendungsorientierten Kommunikationsprotokollgruppen hoher Ebene - dem Market Data Subscription Service (MDSS) und dem Subject-Addressed Subscription Service (SASS).
Die Protokollgruppen hoher Ebene sind rund um ein Kommunikationsparadigma, das als Subskription bezeichnet wird, maßgeschneidert. In diesem Paradigma "subskribiert" ein Datenverbraucher ein Service oder einen Gegenstand und erhält daraufhin einen kontinuierlichen Datenstrom über das Service oder den Gegenstand, bis der Verbraucher ausdrücklich die Subskription beendet (oder ein Fehler auftritt). Ein Subskriptionsparadigma eignet sich sehr gut für Echtzeitanwendungen, die sich dynamisch ändernde Werte, wie zum Beispiel Aktienpreise, überwachen. Im Gegensatz dazu eignet sich das herkömmlichere Anfrage-/Antwort -Kommunikationsparadigma schlecht für solche Echtzeit-Anwendungen, da diese von den Datenverbrauchern verlangen, Datenlieferanten "abzufragen", um über Änderungen informiert zu werden.
Der wichtigste Unterschied zwischen den zwei Protokollen hoher Ebene besteht darin, daß das MDSS serviceorientiert und das SASS gegenstandsorientiert ist. Daher unterstützt zum Beispiel MDSS zusätzlich zu Subskriptionen auch das Senden von Operationen und Nachrichten an Services, wohingegen SASS keine ähnlichen Funktionen unterstützt.

2.4.1 Market Data Subscription Service (Markdaten-Subskriptionsservice)

2.4.1.1 Uberblick

MDSS ermöglicht es, daß Datenverbraucher einen kontinuierlichen Datenstrom mit einer Fehlertoleranz gegenüber Fehlern einzelner Datenguellen empfangen können. Diese Protokollgruppe stellt Mechanismen für die Verwaltung der Lastausgleichs- und Berechtigungspolitik zur Verfügung.
Zwei Eigenschaften unterscheiden die MDSS-Protokolle von den typischen Client-/Server-Protokollen (z.B. RPC). Zum ersten werden Subskriptionen ausdrücklich unterstützt, wodurch Änderungen an angeforderten Werten automatisch an Clients verteilt werden. Zum zweiten fordern Clients ein Service an (oder subskribieren es), was im Gegensatz zu einem Server steht, und es liegt in der Verantwortung der MDSS-Komponente, die Anforderung des Client an einen verfügbaren Server weiterzuleiten. Das MDSS ist danach dafür verantwortlich, die Serververbindung zu überwachen und sie wieder herzustellen, falls sie ausfällt, wobei, falls notwendig, ein anderer Server verwendet wird.
Das MDSS wurde entsprechend konstruiert, um die folgenden wichtigen Aufgaben zu erfüllen:
(1) Fehlertoleranz. Durch Unterstützung einer automatischen Umschaltung zwischen redundanten Services, durch explizite Unterstützung doppelter (oder dreifacher) Netzwerke, und durch Verwendung der fehlertoleranten Übertragungsprotokolle, die in der DCC implementiert sind (wie z.B. der "zuverlässigen Rundfunk-Protokolle"), gewährleistet das MDSS die Integrität einer Subskription im Falle aller möglichen Ausfälle bei einzelnen Punkten. Ein ungünstiger Fehler kann vorübergehend eine Subskription stören, aber das MDSS erkennt Fehler rechtzeitig und sucht rasch nach einem alternativen Kommunikationspfad und/oder einem alternativen Server. Auch die Fehlerbehebung erfolgt automatisch.
(2) Lastausgleich. Das MDSS versucht, die Last über die gesamten für ein Service in Betrieb stehenden Server auszugleichen. Wenn ein Server ausfällt oder wieder in Betrieb geht, gleicht es die Last automatisch erneut aus. Darüber hinaus unterstützt MDSS eine Serverzuweisungspolitlkf die versucht, die Verwendung der knappen Ressourcen, wie z.B. der "Slots" in einem Seitenpufferspeicher oder die Bandbreite der externen Kommunikationsleitung, zu optimieren.
(3) Netzwerkeffizienz. Das MDSS unterstützt das in der DCC implementierte intelligente Mehrfach-Aussenden- Protokoll. Dieses Protokoll versucht, die begrenzten Ressourcen der Netzwerkbandbreite und der Prozessor-1/0- Bandbreite durch Schaffung einer automatischen, dynamischen Umschaltung von Punkt-zu-Punkt-Kommunikationsprotokollen auf Rundfunk-Protokolle zu optimieren. Zum Beispiel kann das Protokoll Daten von Telerate Seite 8 durch Punkt-zu- Punkt-Verteilung an die ersten fünf Subskribenten liefern und später alle Subskribenten auf Rundfunk-Verteilung umstellen, wenn der sechste Subskribent dazukommt.
(4) Kommunikationsschnittstelle hoher Ebene. Das MDSS implementiert eine einfache, leicht handzuhabende Anwendungsentwicklungsschnittstelle, welche den Großteil der Komplexität der Programmierung eines verteilten Systems verdeckt, einschließlich der Suche nach Servern, der Errichtung von Kommunikationsverbindungen, der Reaktion auf Ausfälle und der Wiederherstellung und des Lastausgleichs.

2.4.1.2 Funktionalität

Das NDSS unterstützt die folgenden Kemfunktionen:
get (holen): MDSS errichtet für die festgelegten Services eine fehlertolerante Verbindung zu einem Server und "holt" (d.h. lädt) den aktuellen Wert für die angegebe ne Seite ader das angegebene Datenelement. Die Verbindung ist subskriptionsbasiert, so daß Aktualisierungen der angegebenen Seite automatisch weitergeleitet werden.
halt (stoppen): "stoppt" die Subskription für das angegebene Service.
"derive" (ableiten): sendet einen Modifizierer an den Server, der die Subskription potentiell ändern könnte.
Das MDSS-Protokoll wurde besonders für die Unterstützung seitenorientierter Markdatenversorgung optimiert, und dieser Schwerpunkt spiegelt sich auch in der Wahl der Funktionsbezeichnungen wider. Die Protokollgruppe selbst ist jedoch recht allgemein gehalten und unterstützt die Verteilung beliebiger Datenarten. Daher eignet sich die Protokollgruppe auch für andere Zusammenhänge und wird von diesen benutzt (z.B. - Datenverteilung in einer elektronischen Anzeigetafel).

2.4.2 Subject-Addressed Subscription Service (SASS) (Gegenstandsadressiertes Subskriptionsservice)

2.4.2.1 Überblick

Das SASS ist eine ausgeklügelte Protokollgruppe, die Anwendungsentwicklern eine Kommunikationsschnittstelle sehr hoher Ebene bietet, welche das informationsorientierte, kooperative Verarbeitungsmodell voll unterstützt. Dies wird durch die Verwendung gegenstandsbasierter Adressierung erzielt.
Die allgemeine Idee hinter der gegenstandsbasierten Adressierung und ihrer Implementierung durch das SASS ist sehr einfach. Wann immer eine Anwendung Daten benötigt, und insbesondere Daten, die einen sich dynamisch ändernden Wert repräsentieren (Z.B. einen Aktienkurs), subskribiert die Anwendung diese Daten einfach, indem sie den entsprechenden Gegenstand angibt. Um zum Beispiel alle Trade Tickets über IBM zu erhalten, kann die Anwendung folgende Subskription erstellen: "trade_ticket.IBM". Nachdem eine Anwendung einen bestimmten Gegenstand subskribiert hat, ist es Aufgabe des SASS, eine oder mehrere Service-Instanzen auszuwählen, welche Informationen über diesen Gegenstand anbieten Das SASS stellt daraufhin die entsprechenden Kommunikationsverbindungen her und benachrichtigt (falls gewünscht) die Service-Instanzen, welche die Informationen anbieten.
Das SASS wurde entsprechend konstruiert, um mehrere wichtige Aufgaben zu erfüllen:
(1) Entkoppelung der Informationsverbraucher von den Informationsanbietern. Durch die Anwendung gegenstandsbasierter Adressierung können Informationsverbraucher Informationen auf eine Weise anfordern, die unabhängig von der Anwendung ist, welche die Informationen herstellt. Daher kann die herstellende Anwendung durch eine neue Anwendung, welche dieselben Informationen zur Verfügung stellt, modifiziert oder verdrängt werden, ohne daß dies Auswirkungen auf die Verbraucher der Information hätte.
(2) Effizienz. Die Unterstützung der Ausfilterung von Nachrichten nach Gegenständen ist in die niedrigen Ebenen des TIB -Daemons eingebaut, wo diese Aufgabe sehr effizient durchgeführt werden kann. Das SASS unterstützt auch das Filtern von Daten auf der Erzeugerseite: Daten, die im Moment für keine Anwendung von Interesse sind, können einfach weggelassen werden, bevor sie in das Netzwerk gestellt werden, wodurch Netzwerkbandbreite und Prozessor-1/0 -Bandbreite gespart wird.
(3) Kommunikationsschnittstelle hoher Ebene. Die SASS-Schnittstelle verringert die Komplexitäten der Programmierung einer verteilten Anwendung auf drei Arten. Zum ersten fordert die Verbraucheranwendung Informationen nicht nach Server oder Service, sondern nach Gegenstand an. Das Festlegen von Informationen auf dieser Ebene ist leichter und natürlicher als auf der Service-Ebene. Sie isoliert auch das Programm von Änderungen in den Service-Anbietern (z.B. eine Umschaltung von IDN auf Ticker 3 für Aktienkurse). Zum zweiten stellt das SASS alle Daten durch eine einfache, gleichförmige Schnittstelle dar - ein Programmierer, der Informationen benötigt, die von drei Services angeboten werden, muß nicht drei servicespezifische Protokolle lernen, wie das bei einem herkömmlichen Verarbeitungsmodell der Fall wäre. Zum dritten automatisiert das SASS viele der schwierigen und fehlerträchtigen Aufgaben, wie z.B. das Suchen nach einer geeigneten Service-Instanz, oder die Errichtung der richtigen Kommunikationsverbindung.

2.4.2.2 Funktionalität

Einem Datenverbraucher bietet das SASS drei grundlegende Funktionen:
"Subscribe" (Subskribieren): wenn der Verbraucher Informationen auf Echtzeitbasis über einen oder mehrere Gegenstände abruft. Die SASS-Komponente errichtet alle notwendigen Kommunikationsverbindungen, um zu gewährleisten, daß alle Daten, die dem bzw. den angegebenen Gegenständen entsprechen, zum Verbraucher geliefert werden. Der Verbraucher kann angeben, daß die Daten entweder asynchron (unterbrechungsgesteuert) oder synchron geliefert werden. Eine Subskription kann dazu führen, daß die Service-Instanz des Erzeugers über die Subskription informiert wird. Dies geschieht immer dann, wenn der Erzeuger eine Anmeldeprozedur für seinen Service errichtet hat. Diese Benachrichtigung des Erzeugers über eine beliebige, festgesetzte Anmeldeprozedur ist für den Verbraucher unsichtbar.
e "cancel" (Aufheben): ist das Gegenteil von "Subscribe". Die SASS-Komponente schließt taktvoll jeden dedizierten Kommunikationskanal und benachrichtigt den Ersteller, falls eine geeignete Anmeldeprozedur für das Service vorhanden ist.
"receive" (empfangen) : "receive" (empfangen) und "callbacks" (Rückrufe) sind zwei unterschiedliche Arten für Anwendungen, Nachrichten zu empfangen, die ihren Subskriptionen entsprechen. Rückrufe sind asynchron und unterstützen den ereignisgesteuerten Programmierstil - ein Stil, der sich besonders gut für Anwendungen eignet, die einen Echtzeit-Austausch von Daten benotigen. "Receive" unterstützt eine herkömmliche synchrone Schnittstelle für den Nachrichtenempfang. Für einen Datenerzeuger stellt das SASS eine komplementäre Gruppe von Funktionen zur Verfügung.
Man beachte, daß eine Anwendung gegenüber dem SASS sowohl ein Erzeuger als auch ein Verbraucher sein kann, und daß dies nicht selten der Fall sein kann.

2.4.3 Distributed Communication Component (Verteilte Kommunikationskomponente)

2.4.3.1 Überblick

Die Distributed Communication Component (DCC, verteilte Kommunikationskomponente) stellt TIB -Protokollen höherer Ebene Kommunikationsservices zur Verfügung. Insbesondere bietet sie mehrere Arten fehlertransparenter Protokolle.
Die DCC besitzt mehrere wichtige Aufgaben:
(1) Die Schaffung eines einfachen, stabilen und gleichförmigen Kommunikationsmadells. Diese Aufgabe bietet mehrere Vorteile.
Zum ersten bietet sie eine erhöhte Programmiererproduktivität, indem sie die Entwickler von Komplexitäten einer verteilten Umgebung abschirmt: das Suchen eines Zielprozesses, das Errichten einer Kommunikation mit diesem, und das Bestimmen, wann etwas falsch gelaufen ist, sind Aufgaben, die am besten von einer fähigen Kommunikationsinfrastruktur durchgeführt werden, und nicht vom Programmierer. Zum zweiten verkürzt die DCC die Entwicklungszeit nicht nur dadurch, daß sie die Produktivität des Programmierers erhöht, sondern auch, indem sie die Integration neuer Merkmale vereinfacht. Schließlich erweitert sie die Konfigurierbarkeit, indem sie dafür sorgt, daß Anwendungen nichts über die physikalische Verteilung anderer Komponenten wissen müssen. Dies verhindert, daß Entwickler Abhängigkeiten aufgrund einer bestimmten physikalischen Konfiguration einbauen. (Solche Abhängigkeiten würden nachfolgende Neukonfigurationen erschweren.)
(2) Portabilität durch Einkapselung wichtiger Systemstrukturen. Diese Aufgabe erlangt Bedeutung, wenn eine Migration auf eine neue Hardware- oder Softwareumgebung erforderlich wird. Der Aufwand zur Abschirmung der Anwendungen von den spezifischen, darunterliegenden Kommunikationsprotokollen und Zugriffsverfahren zahlt sich in diesen Fällen besonders aus. Durch Isolierung der benötigten Änderungen in einen kleinen Abschnitt des Systems (in diesem Fall, die DCC) können die Anwendungen nahezu ungeändert portiert werden, und die Investitionen des Unternehmens in die Anwendungen werden geschützt.
(3) Effizienz. Diese ist besonders in dieser Komponente von Bedeutung. Um diese zu erreichen, wird die DCC auf weniger aufwendige, "verbindungslose" Transportprotokolle in standardmäßigen Protokollgruppen (z.B. TCP/IP und OSI) aufgesetzt. Auch wurde die DCC sorgfältig zur Vermeidung des aufwendigsten Problems bei Protokollen entworfen, nämlich der starken Vermehrung von Daten"kopier"operationen.
Die DCC erfüllt diese Aufgaben durch Implementierung einer Servicesschicht über den allgemeinen Services, die von der gekauften Software zur Verfügung gestellt werden. Anstatt grundlegende Funktionen, wie zuverlässigen Datentransfer oder Flußkontrollmechanismen, neu zu erfinden, konzentriert sich die DCC darauf, die Anwendungen von den Eigenarten eines beliebigen Betriebssystems abzuschirmen. Als Beispiele dafür können die hardware-orientierten Schnittstellen der MS-DOS-Umgebung oder die Pro-Prozeß- Dateideskriptoreinschränkung von Unix genannt werden. Durch Schaffung eines einzigen, vereinheitlichten Kommunikationswerkzeugs, das auf einfache Weise in vielen Hardware- und Softwareumgebungen repliziert werden kann, erfüllt die DCC die obigen Aufgaben.

2.4.3.2 Funktionalität

Die DCC implementiert mehrere unterschiedliche Übertragungsprotokolle, um die verschiedenen Interaktionsparadigmen, Fehlertoleranzanforderungen und Leistungsanforderungen zu erfüllen, die von den Protokollen hoher Ebene gestellt werden. Zwei der interessanteren Protokolle sind das zuverlässige Rundfunk-Protokoll und das intelligente Mehrfach-Aussenden-Protokoll.
Standardmäßige Rundfunk-Protokolle sind nicht zuverlässig und nicht in der Lage, verlorene Nachrichten zu entdecken. Die zuverlässigen DCC-Rundfunk-Protokolle stellen sicher, daß alle betriebsfähigen Hosts entweder jede ausgesandte Nachricht empfangen, oder den Verlust der Nachricht bemerken. Im Gegensatz zu den sogenannten zuverlässigen Rundfunk-Protokollen werden verlorene Nachrichten auf einer begrenzten, periodischen Basis neuerlich übertragen.
Das intelligente Mehrfach-Aussenden-Protokoll ermöglicht einen zuverlässigen Datenstrom zu mehreren Bestimmungsorten. Der neuartige Aspekt dieses Protokolls liegt darin, daß es dynamisch von Punkt-zu-Punkt-Übertragung auf Rundfunk-Übertragung umschalten kann, um die Netzwerk- und Prozessorlast zu optimieren. Das Umschalten von Punkt-zu- Punkt auf Rundfunk (und umgekehrt) ist für Protokolle auf höheren Ebenen unsichtbar. Dieses Protokoll ermöglicht die Unterstützung einer viel größeren Anzahl an Verbrauchern, als dies mit Punkt-zu-Punkt oder Rundfunk alleine möglich wäre. Das Protokoll wird innerhalb der DCC auf andere Protokolle aufgesetzt.
Derzeit tauschen alle DCC-Protokolle Daten nur in diskreten Einheiten, d.h. Nachrichten, aus (im Gegensatz zu vielen Transportprotokollen). Die DCC garantiert, daß die Nachrichten, die von einem einzelnen Prozeß stammen, in der gesandten Reihenfolge empfangen werden.
Die DCC enthält fehlertolerante Nachrichtenübertragungsprotokolle, welche die erneute Übertragung im Falle einer verlorenen Nachricht unterstützen. Das Paket garantiert eine "höchstens-einmal"-Semantik im Hinblick auf die Nachrichtenlieferung und unternimmt alle Anstrengungen, um eine "exakt-einmal"-Semantik zu gewährleisten.
Die DCC besitzt keine freiliegenden Schnittstellen, die von Anwendungsentwicklern verwendet werden könnten.

3. RELIABLE MARKET DATA PROTOCOL (Zuverlässiges Marktdatenprotokoll)

3.1 Einleitung

Das Reliable Market Data Protokoll (RMDP) definiert eine programmatische Schnittstelle zur Protokollgruppe und den Services, welche die Market Data Subscription Service (MDSS) TIB Unterkomponente umfassen. Mit Hilfe von RMDP können Markdatenverbraucher einen kontinuierlichen Datenstrom auf der Basis einer Subskriptionsanforderung für ein gegebenes Service empfangen. RMDP toleriert Ausfälle einzelner Server, indem es Merkmale für den automatischen Neuanschluß an alternative Server bietet, welche das selbe Service anbieten. Alle Mechanismen zur Erkennung eines Serverausfalls und zur Fehlerbehebung sowie zur Verfolgung verfügbarer Server sind in der RMDP-Bibliothek implementiert. In der Folge können Anwendungsprogramme auf sehr einfache und naive Weise geschrieben werden.
Das Protokoll stellt Mechanismen für die Verwaltung der Lastausgleichs- und Berechtigungspolitik zur Verfügung. Betrachten wir als Beispiel einen Börsenraum mit drei Telerate-Leitungen. Um die Verwendung der verfügbaren Bandbreite dieser Telerate-Leitungen zu maximieren, kann der Systemadministrator bestimmte allgemein verwendete Seiten bestimmten Servern "zuweisen", d.h. Seite 5 wird Server A zugewiesen, Seite 405 Server B, usw. Jedem Anwender (oder jeder Anwendergruppe) würde ein "Standard"-Server für Seiten zugewiesen, die nicht ausdrücklich zuvor zugeordnet sind. (Diese Zuweisungen sind im TIB Services-Verzeichnis aufgezeichnet.)
Um Fehler zu berücksichtigen, werden Seiten oder Anwender Prioritätslisten von Servern zugewiesen. Wenn es zu einem Hardware- oder Softwareausfall bei einem Server kommt, sucht das RMDF den nächsten Server auf der Liste und stellt mit diesem eine Verbindung her. Wenn ein Server seinen Betrieb wieder aufnimmt, teilt er sein Vorhandensein allen RMDP-Clients mit, und das RMDP verbindet die ursprünglichen Clients wieder mit dem Server. (Durch die automatische Wiederverbindung wird verhindert, daß manche Server überbelastet werden, während manche untätig sind.) Bis auf Statusnachrichten sind die Ausfalls- und Wiederherstellungsverbindungen für die Anwendung unsichtbar.
Die MDSS-Protokollgruppe einschließlich RMDP wird auf die DCC aufgesetzt und verwendet die in dieser Komponente implementierten zuverlässigen Kommunikationsprotokolle. Insbesondere verwendet die MDSS-Gruppe die darin vorhandenen zuverlässigen Rundfunk-Protokolle und die intelligenten Mehrfach-Aussenden-Protokolle. RMDP unterstützt sowohl LANS als auch Weitverkehrsnetze (WANS). RMDP unterstützt auch zweifache (oder mehrfache) Netzwerke auf transparente Weise.
RMDP ist ein "serviceadressiertes" Protokoll: ein komplementäres Protokoll, TIBINFO, unterstützt "die gegenstandsbasierte Adressierung".

3.2 Programmatische Schnittstelle

RNDP-Programme sind ereignisgesteuert. Alle RMDP- Funktionsaufrufe sind nicht blockierend: selbst wenn der Aufruf zu einer Kommunikation mit einem Server führt, kehrt der Aufruf sofort zurück. Server-Antworten sowie Fehlernachrichten werden zu einem späteren Zeitpunkt durch eine von der Anwendung zur verfügung gestellte Rückrufprozedur zurückgegeben.
Die wichtigste, in RMDP implementierte Aufgabenabstraktion ist die eines Rstream, eines "zuverlässigen Stromes" von Daten, der mit einer bestimmten Subskription für ein angegebenes Service im Zusammenhang steht. Wenngleich aufgrund von Ausfällen und Wiederherstellungen unterschiedliche Server die Subskriptionsdaten zu unterschiedlichen Zeiten liefern können, implementiert der Rstream die Abstraktion eines einzelnen, vereinheitlichten Datenstroms. Außer für kurze Zeitperioden während der Ausfalls- und Wiederherstellungsneuverbindung ist ein Rstream mit exakt einem Server für das angegebene Service verbunden. Eine Anwendung kann so viele Rstreams wie nötig öffnen, wobei die Anzahl nur durch den verfügbaren Speicher begrenzt ist.
Ein Rstream ist bidirektional - insbesondere kann der RMDP-Client Steuerungsbefehle und Nachrichten über den Rstream an den angeschlossenen Server senden. Diese Befehle und Nachrichten können Antworten oder Fehlernachrichten vom Server auslösen, und in einem Fall führt ein Befehl dazu, daß eine "abgeleitete" Subskription erzeugt wird. Unabhängig von der Ursache werden alle Daten und Fehlernachrichten (seien sie lokal oder auf einem anderen Server erzeugt) über den entsprechenden Rstream zum Client geliefert.
Die RMDP-Schnittstelle ist eine schmale Schnittstelle, die aus nur sechs Funktionen besteht, die im folgenden beschrieben werden:
void
rmdp_Setprop (property, value)
rmdp_prop_t property:
caddr_t value:
Werden verwendet, um die Werte der RMDP- Eigenschaften einzustellen. Diese Aufrufe müssen vor dem Aufruf von rmdp_Init() durchgeführt werden. Erforderliche Eigenschaften sind in der untenstehenden Liste mit ? gekennzeichnet. Andere Eigenschaften sind optional. Die derzeit verwendeten Eigenschaften sind:
*RMDP_CALLBACK
Zeiger zur Rückruffunktion. Siehe untenstehende Beschreibung des Rückrufs.
RMDP_SERVICE_MAP
Die Bezeichnung des Services-Verzeichnisses, das anstelle des standardmäßigen Verzeichnisses verwendet werden soll.
RMDP_GROUP
Die Anwendergruppe, die zur Bestimmung der richtigen Serverliste verwendet wird. Sollte das Präfix '+' besitzen. Standard ist die Gruppe '+' (d.h. die Null-Gruppe).
RMDP_RETRY_TIME
Die Anzahl an Sekunden, die der Client zwischen aufeinanderfolgenden Versuchen zum selben Server wartet, z.B. im Falle von "Zwischenspeicher voll". Standardwert ist 30.
RNDP_QUIET_TIME
Zeit in Sekunden, die ein Strom "ruhig" sein kann, bevor das Protokoll annimmt, daß der Server gestorben ist und die "Jagd" auf einen anderen Server beginnt. Standardwert ist 75.
RMDP_VERITY_TIME
Zeit in Sekunden zwischen aufeinanderfolgenden Anrufen des Servers durch den Client. Standardwert ist 60.
RMDP_APP_NAME
Name der Anwendung, z.B. "telerate", "reuters", usw. Wenn diese Eigenschaft gesetzt ist, werden die relevanten Einträge vom Service-Verzeichnis im Zwischenpuffer gespeichert.
void
rmdp_Init():
Dies initialisiert die internen Datenstrukturen und muß vor allen Aufrufen von rmdp_Get() aufgerufen werden.
RStream
rmdp_Get(service, request, host)
char *service. *request, *host:
Wird verwendet, um einen Datenstrom für ein bestimmtes "Service" und eine Subskriptionsanforderung ("request") zu erhalten. Für die standardmäßigen Marktdatenservices (Standard Market Data Services) lautet die Anforderung auf den Namen einer Seite (z.B. "5", "AANN") Wenn 'Host' gleich nicht-NULL ist, verwendet das RMDP nur den Server am angegebenen Host. In diesem Fall wird keine neuerliche Verbindung zu alternativen Servern versucht, wenn ein Server ausfällt. Wenn 'host' gleich NULL ist, frägt das RMDP das TIB Services-Verzeichnis ab, um eine Liste von alternativen Servern für die Anforderung zu finden. 'rstream' ist ein durchscheinender Wert, der für einen Verweis auf den Strom verwendet wird. Alle Daten, die zur Rückruffunktion der Anwendung geleitet werden, werden durch diesen Wert identifiziert.
Ein Fehler wird angezeigt durch Rstream rstream ==
NULL.
RStream
rmdp_Derive(rstream, op)
RStreamold:
char *op:
Dies erzeugt eine neue Subskription und daher einen neuen 'Rstream' von einer bestehenden Subskription. 'command' ist eine Zeichenkette, die zum Server gesandt wird, wo sie entsprechend interpretiert wird, um die spezifische Ableitung zu bestimmmen.
Die standardmäßigen Markdatenserver verstehen die folgenden Befehle: "n" für nächste-Seite (next-page), "p" für vorige-Seite (previous-page), und "t XXXX" für Zeit- Seite (time-page).
Abgeleitete Ströme können im Falle eines Server- Ausfalls nicht wiederhergestellt werden. Wenn sie erfolgreich sindf wird ein Rstream zurückgegeben, andernfalls wird NULL zurückgegeben.
void
rmdp-Message(rstream, msg)
Rstreamrstream:
char *msg:
Sendet die Zeichenkette 'msg' zu dem vom 'rstream' verwendeten Server. Die Nachrichten werden direkt zum Server weitergeleitet und in keiner Weise vom Zustand des Stromes beeinflußt. Zu den Nachrichten, die von standardmäßigen Marktdatenservern verstanden werden, gehören "rr < PAGE NAME> " zur neuerlichen Anforderung einer Seite, und "q a" zur Anforderung der Netzwerkadresse des Servers. Einige Nachrichten lösen eine Antwort vom Server aus (wie zum Beispiel Anfragen). In diesem Fall wird die Antwort an alle Ströme geliefert, die an den Server angeschlossen sind.
void
rmdp_Halt (rstream)
Rstreamrstream:
Stoppt den 'rstream' taktvoll.
void
callback(rstream, msgtype, msg, act, err)
Rstreamrstream;
mdp_msg_t msgtype;
char *msg
mdp_act_t act;
mdp_err_t err;
Dies ist die Rückruffunktion, die bei rmdp_Setprop(RMDP_CALLBACK, callback) angemeldet wurde. 'rstream' ist jener Strom, zu dem die Nachricht gehört. 'msgtype' kann jeden beliebigen der unten angeführten Werte annehmen (siehe "RMDP Nachrichtentyp"). 'msg' ist eine Zeichenkette, die v1100 kompatible Escape-Sequencen enthalten kann, wie in MDSS. (Wird jedoch NICHT mit einem A[[ ... E eingeleitet. Diese Rolle wird vom Parameter 'msgtype' übernommen.)
Die letzten beiden Parameter sind nur von Bedeutung, wenn 'msgtype' gleich MDP_MSG_STATUS ist. 'act' kann jeden Wert annehmen, der in "RMDP Action Type" vorkommt (siehe unten), aber eine besondere Handlung ist nur dann nötig, wenn act == 'MDP_ACT_CANCEL' ist. Letzteres zeigt an, daß der Strom abgebrochen wird und nicht mehr gültig ist. Es liegt nun an der Anwendung, die richtige Maßnahme zu treffen. In beiden Fällen kann 'err' einen der Werte annehmen, die in "RMDP Errortype" enthalten sind (siehe unten), und liefert eine Beschreibung des Status.
RMDP Nachrichtentypen (mdp_msg_t)
Die Nachrichtentypen sind unten angeführt. Diese Typen sind im darunterliegenen (unzuverlässigen) Marktdatenprotokoll (MDP) definiert und werden in das RMDP exportiert.
RMDP Maßnahmentyp (mdp_act_t)
Die Maßnahmentypen sind unten angeführt. Diese Maßnahmentypen informieren die RMDP-Clients über Aktivitäten, die in den Protokollen niedrigerer Ebene auftreten. Allgemein gesprochen handelt es sich dabei um Nachrichten "zur Information", die keine zusätzlichen Maßnahmen vom RMDP- Client erfordern. Die Ausnahme dabei ist die Maßnahme "MDP_ACT_CANCEL", für die es keine Wiederherstellung gibt. Diese Typen sind im darunterliegenen (unzuverlässigen) Narktdatenprotokoll (MDP) definiert und werden in das RMDP exportiert.
RMDP Fehlerarten (mdp_err_t)
Fehlerbeschreibung für Protokollierung oder Berichterstellung an Endanwender. Diese Typen sind im darunterliegenden (unzuverlässigen) Marktdatenprotokoll (MDP) definiert und werden in das RMDP exportiert.
MDP_ERR_OK = 0
MDP_ERR_LOW = 1
NDP_ERR_QUIET = 2
MDP_ERR_INVAL = 3
MDP_ERR_RESRC = 4
NDP_ERR_INTERNAL = 5
MDP_ERR_DELAY = 6
NDP_ERR_SYS = 7
MDP_ERR COMM = 8

4. Gegenstandsadressiertes Subskriptionsservice: TIBINFO

4.1 Einleitung

TIBINFO definiert eine programmatische Schnittstelle zu den Protokollen und Services, welche die TIB - Unterkomponente umfassen, die die gegenstandsadressierten Subkriptionsservices (SASS) zur Verfügung stellen. Die TIBINFO-Schnittstelle besteht aus den folgenden Bibliotheken: TIBINFO-CONSUME für Datenverbraucheranwendungen, und TIBINFO-PUBLISH für Datenpublikationsanwendungen. Eine Anwendung umfaßt die eine Bibliothek oder die andere oder beide. Dies hängt davon ab, ob sie ein Verbraucher oder ein Lieferant oder beides ist. Eine Anwendung kann gleichzeitig Verbraucher und Erzeuger sein.
Durch ihre Unterstützung der gegenstandsbasierten Adressierung unterstützt TIBINFO ein informationsorientiertes Modell der kooperativen Verarbeitung durch Schaffung eines Verfahrens für Verbraucheranwendungen zur Anforderung von Informationen auf eine Art und Weise, die vom Service (oder den Services), das die Informationen erzeugt, unabhängig ist. Daraus ergibt sich, daß Services durch alternative Services modifiziert oder ersetzt werden können, die gleichwertige Informationen liefern, ohne daß dies Auswirkungen auf die Informationsverbraucher hätte. Diese Entkoppelung der Informationsverbraucher von den Informationslieferanten ermöglicht einen höheren Grad an Modularisierung und Flexibilität als herkömmliche serviceorientierte Verarbeitungsmodelle.
Damit die gegenstandsbasierte Adressierung in einer Echtzeit-Umgebung nutzbringend anzuwenden ist, muß sie wirkungsvoll implementiert werden. Unter Berücksichtigung dieser Aufgabe wurde die Unterstützung für die gegenstandsbasierte Adressierung in die niedrigen Ebenen der verteilten Kommunikationskomponente eingebaut. Insbesondere wird das Filtern der Nachrichten nach Gegenstand innerhalb des TIB - Daemons selbst durchgeführt.

4.2 Begriffe

Gegenstand

Der Gegenstandsraum ist hierarchisch. Derzeit wird eine Hierarchie mit 4 Ebenen des folgenden Formats unterstützt:
major[.minor[.qualifierl[.qualifier2]]]
wobei '[' und ']' Metazeichen sind, die eine optionale Komponente begrenzen. major, minor, qualifier1 und gualifier2 werden als Gegenstandskennzeichnungen bezeichnet. Eine Gegenstandskennzeichnung ist eine Zeichenkette, die aus den druckbaren ASCII-Zeichen außer '.', '?' und '*' besteht. Eine Gegenstandskennzeichnung kann auch eine leere Zeichenkette sein. In diesem Fall entspricht sie jeder Gegenstandskennzeichnung in dieser Position. Der komplette Gegenstand, einschließlich den '.' Separatoren, darf 32 Zeichen nicht überschreiten. Beim Schreiben der Gegenstände ist die Groß- und Kleinschreibung zu beachten.
Einige Beispiele für gültige Gegenstände sind unten angeführt. Die Kommentare beziehen sich auf die Interpretation von Gegenständen auf der Verbraucherseite. (Die Semantik auf der Seite der Publikationsanwendung ist leicht unterschiedlich.)
equity. ibm. composite . quote
equity..composite.quote Abgielch mit kleinerem Gegenstand
equity. ibm Abgleich mit qualifien und qualifier2
equity.ibm. gleich wie oben
Innerhalb von TIBINFO und dem SASS werden Gegenstände nicht interpretiert. Daher besitzen Anwendungen die Freiheit, Konventionen über den Gegenstandsraum zu erstellen. Es sollte beachtet werden, daß die SASS-Komponenten zuerst versuchen, die größeren und kleineren Gegenstandskennzeichnungen übereinzustimmen. Obwohl Anwendungen die Konvention erstellen können, daß "equity.ibm" und "..equity.ibm" gleichwertige Gegenstände sind, werden Subskriptionen von "equity.ibm" auf wirkungsvollere Art verarbeitet.

Strom (Stream)

Ein Strom ist eine Abstraktion für die Gruppierung von Subskriptionen. Die Subskriptionen eines Stroms verwenden eine gemeinsame Gruppe von Eigenschaften, und zwar bemerkenswerterweise die selbe Nachrichtenroutine (d.h. "Rückruf"-Routine) und die selbe Fehlerroutine. Alle Subskriptionen eines Stroms können einfach durch zerstörung des Stroms "abgebrochen" werden.
Ein Strom belastet das System mit geringem Overhead-Aufwand. Ströme können daher frei erzeugt und zerstört werden.

Protokoll-Engines, Service-Disziplinen und Gegenstandsabbilder

Die SASS- und DCC-Komponenten implementieren viele unterstützende Services, um die Funktionaltität in TIBINFO zur Verfügung zu stellen. Dazu gehören Gegenstandsabbilder für eine effizientere Handhabung von Gegenständen, Service- Disziplinen für die Kontrolle der Interaktion mit Servern, und Protokoll-Engines für die Implementierung zuverlässiger Kommunikationsprotokolle. TIBINFO stellt eine Schnittstelle für die Einrichtung von Eigenschaften dieser Komponenten zur Verfügung. Daher kann zum Beispiel durch Einstellung der entsprechenden Einstellungen das Verhalten des Gegenstandsabbilders durch die TIBINFO-Schnittstelle festgelegt werden. Da sich diese Eigenschaften in Konfigurationsdateien befinden, können konfigurations- und ortsabhängige Parameter für die oben genannten Komponenten durch TIBINFO unterstützt werden.
In der Zukunft können die Eigenschaftsdef initionen für TIBINFO und für die darunterliegenden Komponenten vergrößert werden, um Erweiterungen zu unterstützen. Die Verwendung von Eigenschaften führt zu Flexibilität und Erweiterbarkeit innerhalb der Grenzen einer stabilen, funktionellen Schnittstelle.

4.3 Beschreibung

Die TIBINFO-Schnittstelle ist eine leicht zu verwendende Schnittstelle hoher Ebene. Bei den publizierten Daten kann es sich um ein Formular oder eine uninterpretierte Bytekette handeln. Nachrichten können entweder in synchroner Weise oder auf eine asynchrone Weise, die sich für die ereignisgesteuerte Programmierung eignet, empfangen werden. Die folgenden Funktionen reichen aus, um ausgeklügelte verbraucheranwendungen mit Hilfe ereignisgesteuerter Programmierung zu schreiben.

Tib_stream *tib_consume_create(property-list, TIB_EOP)

Erzeugt einen TIBINFO-Strom, der mehrere Subskriptionen über die "subscribe"-Funktion unterstützt. Die Eigenschaftenlisten ist eine (möglicherweise leere) Liste von Eigenschaften-Wertpaaren, wie dies dargestellt wird durch tib_consume_create(TIB_PROP_MSGHANDLER, my-handler, TIB_PROP_ERRHANDLER, my-err-handler. TIB_EOP);
Gültige Eigenschaften werden im folgenden definiert. TIB_EQP ist ein Literal, welches das Ende der Eigenschaftenliste signalisiert.
void tib destroy(stream)
Tib_stream *stream:
Fordert Ressourcen ein, die vom spezifischen Strom verwendet werden.
Tib_errorcode tib_subscribe(stream, subject, clientdata)
Tib_stream *stream:
Tib-subject *subject:
caddr_t clientdata.
Informiert die TIB darüber, daß die Client- Anwendung an Nachrichten interessiert ist, welche den angezeigten Gegenstand enthalten. Wenn dem Strom ein "messagehandler" (eine Nachrichtenroutine) zugewiesen ist, wird sie immer dann aufgerufen, wenn eine Nachricht, die der Subskription entspricht, einlangt. Entsprechende Nachrichten werden auf einer FIFO-Basis (first in/first-aut) gesendet. Der Wert der Client-Daten wird in jeder Nachricht, welche dem Gegenstand der Subskription entspricht, zurückgegeben. Man beachte, daß mehrfache Subskriptionen desselben Gegenstandes am selben Strom undefiniert sind.
void tib cancel(stream)
Tib_stream *stream;
Bricht die Subskription des angegebenen Gegenstandes der dient-Anwendung ab.
void my_message_handler(stream.msg)
Tib_stream *stream;
Tib_message *message;
Dies ist die Rückruffunktion, die beim Strom angemeldet wurde. Formulare werden unpaketiert zurückgeschickt. Die Funktion kann durch die unten beschriebenen Makros auf die gesamte Nachrichtenstruktur verweisen.
Die folgenden Funktionen reichen aus, um Erzeugeranwendungen zu schreiben. Es werden zwei Publiakationsfunktionen zur Verfügung gestellt, um die unterschiedlichen Datentypen zu unterstützen, die durch die TIB-INFO Schnittstelle übertragen werden können.
tib_publish_create(property-list, TIB_EOP)
Wird verwendet, um einen TIBINFO-Strom für die Publikation von Datensätzen zu erzeugen. Die property-list (Eigenschaftenliste) ist eine (möglicherweise leere) Liste von Eigenschaftenwertpaaren, wie dies dargestellt wird durch
tib_ublish_create(TIB_PROP_ERRHANDLER,my_handler,TIB_EOP).
Gültige Eigenschaften werden im folgenden definiert. TIB_EOP ist eine Konstante, welches das Ende der Eigenschaftenliste signalisiert.
tib destroy (stream)
Tib_stream stream;
Fordert Ressourcen ein, die vom spezifischen Strom verwendet werden.
Tib_errorcode tib_publish_form(stream, subject, form)
Tib_stream *stream;
Tib_subject *subject;
Form form;
Akzeptiert ein einzelnes, unpaketiertes Formular, paketiert es und publiziert es.
Tib_errorcode tib_publish_buffer(stream, subject, length, form)
Tib_stream *stream;
Tib_subject *subject;
short length;
Form form;
Akzeptiert einen Byte-Zwischenspeicher festgesetzter Länge und publiziert ihn.
Die restlichen Funktionen sind Kontrollfunktionen, die sowohl für die Verbraucher- als auch für die Publikationsseite gelten.
void Tib_batch()
Kann vor der Initiierung mehrerer Subskriptionen verwendet werden. Informiert die TIB -Bibliothek darüber, daß sie eine Bearbeitung der Subskriptionen bis zu einem tib_unbatch aufschieben kann. Dadurch kann die TIB - Bibliothek versuchen, die Ausführung der Anforderungen zu optimieren. Man beachte, daß keine Garantien über die Bestellung oder zeitliche Abfolge einer gestapelten ("batched") Anforderung abgegeben werden können. Insbesondere (i) können Anforderungen vor dem Erhalt der tib_unbatch Funktion ausgeführt werden, und (ii) sind die Auswirkungen einer Änderung der Eigenschaften in der Mitte einer gestapelten Anforderungsfolge undefiniert. Stapelund Entstapelanforderungen (batch und unbatch) können verschachtelt werden. (Man beachte, daß die Verwendung von tib_batch völlig freigestellt ist und die Semantik eines richtigen Programms in keiner Weise ändert.)
Tib_errorcode tib_stream_set(stream, property, value)
Tib_stream *stream;
Tib_property *property;
caddr_t value;
Wird verwendet, um einstellbare Eigenschaften eines Stromes dynamisch zu verändern. Diese Eigenschaften werden im folgenden beschrieben. Man beachte, daß manche Eigenschaften nur vor der Stromerzeugung (über tib_default_set) oder während der Stromerzeugung eingestellt werden können.
caddr_t tib_stream_get(stream, property)
Tib_stream *stream;
Tib_property *property;
Wird zum Empfangen des aktuellen Wertes der angegebenen Eigenschaft verwendet.
Tib_errorcode tib-default-set( property, value)
Tib_stream *stream:
Tib_property *property:
caddr_t value:
Wird verwendet, um die anfänglichen Eigenschaften eines Stromes zu verändern. Während der Stromerzeugung werden die Standard-Werte als Anfangswert im neuen Strom verwendet, wann immer ein Eigenschaftenwert in der Erzeugungsargumentenliste nicht ausdrücklich festgelegt ist.
Tib_errorcode tib_default_get( property)
Tib_stream *stream:
Tib_property *property:
Wird zum Empfangen des Standard-Wertes der angegebenen Eigenschaft verwendet.
tib_unbatch()
Informiert TIBINFO darüber, "batching"-Funktionen (Stapelungsfunktionen) zu beenden und eventuell noch ausständige auszuführen.

TIBINIFO-Attribute

Die von TIBINFO und den erlaubten Werten definierten Eigenschaften werden im folgenden angeführt und auf den entsprechenden "man"-Seiten in ihren Einzelheiten beschrieben. Die letzte Gruppierung der Eigenschaften ermöglicht es dem Programmierer, standardmäßige Eigenschaftenwerte und Hinweise an die darunterliegenden Systemkomponenten zu senden - insbesondere an die Netzwerk-Protokoll-Engines, den TIB Gegenstandsabbilder, und verschiedene Service- Disziplinen.

TIBINFO-Nachrichtenstruktur

Auf die Komponenteninformationen einer TIBINFO- Nachricht kann durch die folgenden Makros zugegriffen werden:
tib_msg_clientdata(msg)
tib_msg_subject (msg)
tib_msg_size (msg)
tib_msg_value(msg)
Die folgenden Makros geben TRUE (1) (WAHR) oder FALSE (0) (FALSCH) zurück:
tib_msg_is_buffer (msg)
tib_msg_is_form (msg)

5. TIB Formulare

5.1 Einleitung

Das Formular-Paket stellt die Werkzeuge zum Erzeugen und Manipulieren selbstbeschreibender Datenobjekte, wie z.B. Formulare, zur Verfügung. Formulare besitzen eine ausreichend große Ausdrucksfähigkeit, Flexibilität und Effizienz, um alle Daten zu beschreiben, die zwischen den unterschiedlichen TIB -Anwendungen sowie zwischen den wichtigsten Software-Modulen einer jeden Anwendung ausgetauscht werden.
Das Formulare-Paket stellt seinen Clients eine Datenabstraktion zur Verfügung. Daher muß sich die Software, die ein Formulare-Paket verwendet, im Gegensatz zu einem Fall, bei dem eine Datenabstraktion für jeden unterschiedlichen Datentyp, der ausgetauscht wird, verwendet wird, nur mit einer einzigen Datenabstraktion beschäftigen. Die Verwendung von Formularen als einzige Möglichkeit, Anwenderdaten auszutauschen, erleichtert (i) die Integration neuer Software-Module, die mit anderen Software-Modulen kommunizieren, und (ii) die modulare Erweiterung bestehender Datenformate, ohne den darunterliegenden Code zu modifizieren. Dies führt zu einer Software, die leichter zu verstehen, zu erweitern und zu warten ist.
Formulare sind die wichtigsten gemeinsam verwendeten Objekte in der Infrastruktur der TIB-Kommunikation und der TIB-Anwendungen; daher gehören sie zu den wichtigsten Abstraktionen von TIB.
Die wichtigsten Aufgaben bei der Erstellung der Formular-Pakete waren:
o Erweiterbarkeit - Es ist wünschenswert, die Definition einer Formularklasse ohne Neukompilierung der Anwendung ändern zu können, und neue Formularklassen in das System einführen zu können.
o Wartbarkeit - Änderungen an der Formularklassendefinition können viele Workstations beeinflussen; derartige Änderungen müssen daher systematisch verbreitet werden.
o Ausdrucksfähigkeit - Formulare müssen in der Lage sein, komplexe Objekte zu beschreiben; daher sollten Formularpakete viele allgemeine Typen wie z.B. Ganzzahl (Integer), Real (real), Zeichenkette (String), usw. sowie Sequenzen dieser Typen unterstützen.
o Effizienz - Formulare sollten das am häufigsten verwendete Objekt zum Senden von Informationen zwischen Prozessen sein - sowohl für Prozesse auf der selben Workstation, als auch für Prozesse auf unterschiedlichen Workstations. Daher sollten Formulare so konstruiert sein, daß sie der Kommunikationsinfrastruktur ermöglichen, Informationen auf effiziente Weise zu senden.
Man beachte, daß sich unsere Verwendung des Begriffs "Formular" von der normalerweise gebräuchlichen Verwendung des Begriffes in Datenbankensystemen und sogenannten "Formularverwaltungssystemen" unterscheidet. In diesen Systemen ist ein "Formular" ein Format zur Darstellung eines Datenbank- oder Dateisatzes. (Typischerweise erstellt ein Anwender in solchen Systemen ein Formular und importiert einen Datenbank-Satz in das Formular.)
Unser Formular-Begriff ist fundamentaler, ähnlich solch grundlegenden Begriffen wie Datensatz oder Datengruppe. Unser Begriffleitet seine Bedeutung von der ursprünglichen Bedeutung der lateinischen Wurzel 'forma' ab. Webster definiert dies als: "Die Form und Struktur einer Sache im Gegensatz zu ihrem Material". Formulare können instantiiert werden, sie können bearbeitet werden, als Argumente weitergeleitet werden, über ein Netzwerk gesandt werden, oder in Dateien und Datenbanken gespeichert werden. Ihr Inhalt kann auch in vielen unterschiedlichen Formaten dargestellt werden. Es können "templates" (Vorlagen) verwendet werden, um festzulegen, wie ein Formular darzustellen ist. Ein einzelnes Formular (präziser, eine Formularklasse) kann viele "templates" haben, da es möglicherweise auf viele unterschiedliche Arten dargestellt werden muß. Verschiedene Anwender können zum Beispiel unterschiedliche Formate zur Darstellung eines Formulars verwenden wollen.

5.2 Beschreibung

Formulare sind selbstbeschreibende Datenobjekte. Jedes Formular enthält einen Verweis auf seine Formularklasse, die das Formular vollständig beschreibt. Formulare enthalten auch Metadaten, die das Formularpaket in die Lage versetzen, die meisten Operationen durchzuführen, ohne zu diesem Zweck auf die damit in Verbindung stehende Formularklassen-Definition zuzugreifen.
Jedes Formular ist ein Element einer spezifischen Farmularklasse. Alle Formulare innerhalb einer Klasse besitzen die selben Felder und Feldbezeichnungen (tatsächlich sind alle definierenden Attribute der Formulare einer spezifischen Klasse ident). Jede Formularklasse trägt eine Bezeichnung, und zwei Klassen werden als unterschiedlich angesehen, wenn sie unterschiedliche Bezeichnungen tragen (selbst wenn die Klassen idente Definitionen besitzen). Auch wenn die Formular-Software einzelnen Formularbezeichnungen eine spezielle Bedeutung oder verarbeitungsunterstützung zuweist, können Anwendungen, welche diese verwenden, dies sehr wohl tun. (In der Tat wird erwartet, daß bestimmte Formularbezeichnungskonventionen errichtet werden.)
Es gibt zwei Hauptklassifikationen von Formularen: primitive im Gegensatz zu konstruierten Formularen, und Formulare mit fixer Länger im Gegensatz zu solchen mit variabler Länge.
Primitive Formulare werden zur Darstellung primitiver Datentypen, wie z.B. Ganzzahlen, Fließkommazahlen, Zeichenketten usw. verwendet. Primitive Formulare enthalten Metadaten in der Formular-Kopfzeile und der Informationskopfzeile sowie die Daten des entsprechenden Typs, wie z.B. Ganzzahlen, Zeichenketten, usw.
Konstruierte Formulare enthalten Unterformulare. Ein konstruiertes Formular enthält andere Formulare, die wiederum Unterformulare enthalten können.
Formulare mit fixer Länge sind einfach Formulare mit einer fixen Länge; so beanspruchen z.B. alle Formulare einer Klasse mit fixer Länge die selbe Anzahl an Bytes. Ein Beispiel für ein primitives Formular fixer Länge ist die Ganzzahl-Formularklasse: Ganzzahlenformulare benötigen immer 6 Bytes. (2 Bytes für die Formular-Kopfzeile und 4 Bytes für die Ganzzahlen-Daten).
Formulare variabler Größe enthalten Daten variabler Größe; primitive Formulare variabler Größe enthalten Daten variabler Größe, wie z.B. Zeichenketten variabler Länge; konstruierte Formulare variabler Größer enthalten eine variable Anzahl an Unterformularen einer einzigen Klasse. Solche Formulare ähneln einer Datengruppe von Elementen des selben Typs.

5.3 Klassenkennungen

Wenn eine Klasse definiert wird, wird ihr eine Kennung zugewiesen. Diese Kennung ist Teil einer jeden Formularinstanz der Klasse und wird zur Identifizierung der Formularklasse verwendet. Diese Kennung ist zusätzlich zur Bezeichnung vorhanden. Klassenkennungen müssen innerhalb ihres verwendungsrahmens einzigartig sein. Klassenkennungen sind 2 Byte lang: Bit 15 wird gesetzt, wenn die Klasse eine Klasse fixer Länge ist; andernfalls wird dieses Bit gelöscht; Bit 14 wird gesetzt, wenn die Klasse eine primitive Klasse ist; andernfalls wird dieses Bit gelöscht.

5.4 Semantik der Zuweisung

Um Werte eines Formulars (oder eine Formularsequenz) zuzuweisen und zu laden, wird die "Kopier"-Semantik verwendet. Beim Zuweisen eines Wertes zu einem Formular (Formularfeld oder einem Sequenzelement) wird der Wert des
Formulars an den zugewiesenen Ort kopiert - es wird kein Zeiger zum gegebenen Wert errichtet.
Clients, die an einer Zeigersemantik interessiert sind, sollten Formular des allgemeinen Typs Form Pointer und die Funktion Form_set_data_pointer verwenden. Formulare des Typs Form Pointer enthalten nur einen Zeiger zu einem Formular; daher wird für die Zuweisung eine Zeigersemantik verwendet. Man beachte, daß die C-Programmiersprache die Zeigersemantik für die Datengruppenzuweisung unterstützt.

5.5 Referenzierung eines Formularfeldes

Auf ein Unterformular oder ein Feld eines konstruierten Formulars kann durch dessen Feldbezeichnung oder durch dessen Feldkennung (letztere wird vom Formular-Paket erzeugt) zugegriffen werden. Die Bezeichnung eines Unterformulars, das kein direkter Abkömmlung eines gegebenen Formulars ist, setzt sich aus dem Pfadnamen aller Felder, getrennt durch einen Punkt, zusammen, die das angeforderte Unterformular enthalten. Man beachte, daß dies der Namenskonvention der Datensätze der C-Sprache ähnelt.
Eine Feldkennung kann geholt werden, wenn die Bezeichnung des Feldes gegeben ist und die Funktion Form_class_get_field_id verwendet wird. Die direkten Felder eines Formulars können durch Verwendung von Form_field_id_first durchquert werden, um die Kennung des ersten Feldes zu erhalten, und durch nachfolgenden Aufruf von Form_field_id_next, um die Kennungen der einzelnen nachfolgenden Felder zu erhalten.
Der Zugriff auf ein Feld durch dessen Bezeichnung ist komfortabel, der Zugriff durch dessen Kennung ist schnell. Die meisten Funktianen des Formular-Paketes referenzieren ein Formularfeld über dessen Kennung und nicht über dessen Bezeichnung.

5.6 Formularklassen-Definitionssprache

Formularklassen können mit Hilfe der "Formularklassen-Definitionssprache" beschrieben werden, die unten dargestellt ist. Selbst komplexe Formulare können innerhalb der einfachen, unten dargestellten Sprachmerkmale beschrieben werden. Der große Vorteil einer formalen Sprache besteht jedoch darin, daß sie ein umfangreiches Rahmenwerk bietet: durch Hinzufügen neuer Sprachenkonstrukte kann die Beschreibungsleistung der Sprache enorm vergrößert werden, ohne dadurch ältere Beschreibungen inkompatibel zu machen.
Eine Beschreibung einer Formularklasse umfaßt die Beschreibung einiger Klassenattribute, wie zum Beispiel der Klassenbezeichnung, und eine Liste der Spezifikationen für die einzelnen Felder der Klasse. Drei Beispiele werden im folgenden dargestellt:
Um eine Klasse zu beschreiben, muß die Klassenbezeichnung, eine Aussage über fixe oder variable Größe und eine Liste der Felder vorhanden sein. Bei primitiven Klassen müssen auch der Datentyp und die Größe beschrieben werden. Für alle anderen Attribute sind keine Angaben nötig; für diese werden Standardwerte gesetzt. Um ein Klassenfeld zu definieren, muß entweder die Bezeichnung oder die Kennung der Feldklasse angegeben werden. Folgende Formularklassenattribute können beschrieben werden:
Die Klassenbezeichnung.
CLASS_ID - Einzigartige, kurze Ganzzahl-Kennung der Klasse. Wird standardmäßig auf einen vom Paket angegebenen Wert gesetzt.
IS_FIXED - Beschreibt, ob die Klasse eine fixe oder variable Größe besitzt. Erwartet einen Boolschen Wert. Dieses Attribut ist erforderlich.
IS_PRIMITIVE - Beschreibt, ob es sich um eine primitive oder konstruierte Klasse handelt. Erwartet einen Boolschen Wert. Wird standardmäßig auf FALSCH (FALSE) gesetzt.
FIELDS_NUM - Eine Ganzzahl, die die Anfangszahl der Felder im Formular beschreibt. Wird standardmäßig auf die Anzahl der beschriebenen Felder gesetzt.
DATA_TYPE - Eine von den Clients festgelegte Ganzzahl, die anzeigt, um welchen Datentyp es sich handelt. Wird hauptsächlich zur Definition primitiver Klassen verwendet. Besitzt keinen Standard-Wert.
DATA_SIZE - Die Größe des Formulardatenabschnittes. Wird hauptsächlich zur Definition primitiver Klassen verwendet. Besitzt keinen Standard-Wert.
FIELDS - Zeigt den Beginn der Felderdefinition der Klasse an.
Folgende Feldattribute können beschrieben werden:
Der Feldname der Klasse.
FIELD_CLASS_ID - Die Klassenkennung für die Formulare, die im Feld enthalten sein sollen. Man beachte, daß die Klassenbezeichnung für den selben Zweck verwendet werden kann.
FIELD_OLASS_NAME - Die Klassenbezeichnung für die Formulare, die im Feld enthalten sein sollen.
Hier ein Beispiel der Definition von drei Klassen:
Man beachte, daß Formulare variabler Länge Felder einer einzigen Klasse enthalten. "integer" und "string_30", die in den obigen Beispielen verwendet werden, sind zwei primitive Klassen, die innerhalb des Formularklassen- Paketes selbst definiert sind.

5.7 Formularklassen sind Formulare

Formularklassen werden als Formulare implementiert. Dies bedeutet, daß Funktionen, die Formulare als Argument akzeptieren, auch Formularklassen akzeptieren. Einige der nützlicheren Funktionen bei Formularklassen sind:
Form_ack, Form_unpack - Kann zum Packen und Entpacken von Formularklassen verwendet werden.
Form_copy - Kann zum Kopieren von Formularklassen verwendet werden.
Form_show - Kann zum Drucken von Formularklassen verwendet werden.

5.8 Typen

typedef Formclass

Eine Formularklassen-Handhabe

typedef Formclass_id

Eine Formularklassen-Kennung.

typedef Formclass_attr

Ein Formularklassen-Attributtyp. Folgende Attribute werden unterstützt:
FORMCLASS_SIZE - Die Größe der Formularinstanzen der Klasse.
FORMCLASS_NAME - Die Klassenbezeichnung.
FORMCLASS_ID - Eine zwei Byte lange, einzigartige Kennung.
FORMCLASS_FIELDS_NUM - Die Anzahl der (direkten) Felder in der Klasse. Dies gilt nur für Klassen fixer Länge. Die Anzahl der Felder in einer Klasse mit variabler Länge ist bei jeder Instanz verschieden; daher ist sie in jeder Formularinstanz enthalten.
FORMCLASS_INSTANCES_NUM - Die Anzahl der Formularinstanzen der jeweiligen Klasse.
FORMCLASS_15_FIXED - True (Wahr), wenn es sich um ein Formular fixer Länge handelt. False (Falsch), wenn es sich um ein Formular variabler Länge handelt.
FORMCLASS_15_PRIMITIVE - True (Wahr), wenn es sich um ein Formular primitiven Typs handelt. False (Falsch), wenn es sich um ein Formular konstruierten Typs handelt, d.h. wenn das Formular Unterformulare besitzt.
FORMCLASS_DATA_TYPE - Dieser Feldwert wird vom Benutzer der Formulare zugewiesen, um den Datentyp der primitiven Formulare zu kennzeichnen. In der aktuellen Anwendung verwenden wir die Typenkonstanten, wie sie vom spezifizierten Typ Farm_data_type in den Dateiformularen definiert werden.
FORMCLASS_DATA_SIZE - Dieses Feld enthält die Datengröße der primitiven Formulare in Bytes. Zum Beispiel hat die primitive Klasse Short die Datengröße Zwei.
Da sie den C-Typ short enthält, der in zwei Bytes enthalten ist.

typedef Formclass_field_attr

Ein Formularklassenfeld-Attributtyp. Folgende Formularklassenfeld-Attribute werden unterstützt:
FORMCLASS_FIELD_NAME - Die Bezeichnung des Klassenfeldes.
FORMCLASS_FIELD CLASS ID - Die Klassenkennung des Formulars des Feldes.

typedef Form

Eine Formular-Handhabe.

typedef Form_field_id

Eine Kennung für ein Feld eines Formulars. Kann Felder in jeder Ebene eines Formulars identifizieren. Eine Feldkennung kann mit Hilfe der Funktion Form_dass_get_field_name von einer Feldbezeichnung geholt werden. Eine form_field_id wird manipuliert durch die Funktionen: Form_field_id_first und Form_field_id_next.

typedef Form_attr

Ein Formular-Attributtyp. Folgende Formular- Attribute werden unterstützt:
FORM_CLASS_ID - Die Klassenkennung des Formulars.
FORM_DATA_SIZE - Die Größe der Daten des Formulars. Verfügbar nur für konstruierte, nicht primitive Formulare, oder für primitive Formulare variabler Größe. Für primitive Formulare fixer Länge ist dieses Attribut über die Formularklasse verfügbar.
FORM_FIELDS_NUM - Die Anzahl der Felder in dem jeweiligen Formular. Verfügbar nur für konstruierte, nicht primitive Formulare. Für primitive Formulare ist dieses Attribut über die Formularklasse verfügbar.

typedef Form_data

Der Datentyp, der in primitiven Formularen enthalten ist.

typedef Form_pack_format

Beschreibt die möglichen Formularpaketierungstypen. Folgende Paketierungsformate werden unterstützt:
FORM_PACK_LIGHT - Leichte Paketierung; wird hauptsächlich für die Zwischenprozeßkommunikation zwischen Prozessen der selben Maschine verwendet. Ist effizienter als andere Paketierungstypen. Die leichte Paketierung besteht aus der reihenweisen Anordnung des jeweiligen Formulars, aber sie übersetzt die Formulardaten nicht in ein maschinenunabhängiges Format.
FORM-PACK-XDR - Ordnet das Formular reihenweise an, während es die Daten in ein maschinenunabhängiges Format übersetzt. Das verwendete maschinenunabhängige Format ist das XDR-Format von Sun.

5.9 Prozedurale Schnittstelle zum Formularklassenpaket

Das Formularklassenpaket ist für die Erzeugung und Bearbeitung von Formularklassen verantwortlich. Das Formularpaket verwendet diese Beschreibungen zur Erzeugung und Bearbeitung von Instanzen gegebener Formularklassen. Eine Instanz einer Formularklasse wird wenig überraschend als Formular bezeichnet.

Formclass_create

Erzeugt eine Klassen-Handhabe gemaß der gegebenen Argumentliste. Wenn das Attribut CLASS_CFILE beschrieben ist, sollte diesem eine cfile-Handhabe und ein Pfadname folgen. In diesem Fall sucht formclass_create die Beschreibung für die Formularklasse in der beschriebenen Konfigurationsdatei. Die Beschreibung wird zu einer internen Datenstruktur kompiliert, die vom Formularpaket verwendet wird.
Formclass_create gibt einen Zeiger zur Klassendatenstruktur zurück. Wenn Syntaxfehler in der Klassebeschreibungsdatei vorhanden sind, setzt die Funktion die Fehlernachrichtenmarke und gibt NULL zurück.

Formclass_destroy

Die von der gegebenen Klassen-Handhabe angegebene Klassenbeschreibung wird zerlegt und der Speicher wieder beansprucht.
Wenn es lebende Instanzen der Klasse gibt, wird die Klasse nicht zerstört, und der Fehlerwert wird auf "FORMCLASS_ERR_NON_ZERO_INSTANCES_NUM" aktualisiert.

Formclass-get

Bei einer Handhabe zu einer Formularklasse und einem Attribut einer Klasse (Z.B. einem der Attribute des Typs Formclass_attr), gibt Formalass_get den Wert an das Attribut zurück. Bei einem unbekannten Attribut wird der Fehlerwert aktualisiert auf "FORMCLASS_ERR_UNKNOWN_ATTRIBUTE".

Formclass_get_handle_by_id

Bei einer Formularklassenkennung gibt Formclass_get_handle_by_id die Handhabe an den geeigneten Klassendeskriptor zurück. Ist die angeforderte Klassenkennung unbekannt, gibt Formalass_get_handle_by_id NULL zurück, setzt aber keine Fehlermarke.

Formclass_get_handle_by_name

Bei einer Formularklassenbezeichnung gibt Formclass_get_handle_by_name die Handhabe an den geeigneten Klassendeskriptor zurück. Ist die angeforderte Klassenbezeichnung unbekannt, gibt Formclass_get_handle_by_name NULL zurück, setzt aber keine Fehlermarke.

Formclass_get_field_id

Bei einer Handhabe zu einer Formularklasse und einer Feldbezeichnung gibt diese Funktion die Formularkennung zurück, die für einen raschen Zugriff auf das Formular verwendet wird. Wenn die angegebene Feldbezeichnung nicht existiert, aktualisiert sie die Fehlervariable zu FORMCLASS_ERR_UNKNOWN_FIELD_NAME.

Formclass_field_get

Gibt den Wert des Attributs des angeforderten Feldes zurück. Wenn in dieser Prozedur eine ungültige Kennung angegeben wird, aktualisiert sie die Fehlervariable auf FORMCLASS_ERR_UNKNOWN_FIELD_ID.

Formclass_iserr

Gibt TRUE (Wahr) zurück, wenn die Fehlermarke der Formularklasse eingeschaltet ist, ansonsten FALSE (Falsch).

Formclass_errno

Gibt die Fehlernummer der Formularklasse zurück. Wenn kein Fehler vorhanden ist, gibt sie FORMCLASS_OK zurück. Für eine Liste der unterstützten Fehlerwerte siehe die Datei Formularklassen.

5.10 Das Formularpaket

Form_create

Erzeuge ein Formular (d.h. eine Instanz) der durch den Parameter festgelegten Formularklasse und gib eine Handhabe an das erzeugte Formular zurück.

Form_destroy

Das angegebene Formular wird durch Beanspruchung seines Speichers "zerstört".

Form_get

Bei einer Handhabe zu einem Formular und einem gültigen Attribut (Z.B. einem der Werte des angeführten Typs Form_attr) gibt Form_get den Wert des angeforderten Attributs zurück.
Das Attribut FORM_DATA_SIZE wird nur für Formulare variabler Größe unterstützt. Für Formulare fixer Größe wird diese Information in der Klassenbeschreibung verwahrt und nicht bei jeder Formularinstanz.
Bei Anforderung von FORM_DATA_SIZE von einem Formular fixer Länge wird die Fehlermarke auf FORM_ERR_NO_SIZE_ASTTR_FOR_FIXED_LENGTH_FORM gesetzt.
Das Attribut FORM_FIELDS_NUM wird nur für konstruierte Formulare unterstützt. Bei Anforderung von FORM_FIELDS_NUM von einem primitiven Formular wird die Fehlermarke auf FORM_ERR_ILLEGAL_ATTR_FOR_PRIMITIVE_FORM gesetzt.
Ist das jeweilige Attribut nicht bekannt, wird die Fehlermarke auf FORM_ERR_UNKNOWN_ATTR gesetzt. Wird die Fehlermarke anders gesetzt als auf FORM_OK, gibt Form_get NULL zurück.

Form_set_data

Setzt den Datenwert des Formulars auf den angegebenen Wert. Es wird angenommen, daß das gegebene Datenargument ein Zeiger zu den Daten ist, d.h. ein Zeiger zu einer Ganzzahl, oder ein Zeiger zu einer Datenstruktur. Für Zeichenketten erwarten wir jedoch einen Zeiger zu einem Zeichen.
Man beachte, daß wir die Kopie-Semantik für Zuweisungen verwenden.

Form_get_data

Gib einen Zeiger zum Datenabsahnitt eines Formulars zurück. Im Falle eines Formulars einer primitiven Klasse handelt es sich bei den Daten um den aktuellen Wert des Formulartyps. Wenn es sich bei dem Formular nicht um das einer primitiven Klasse handelt, d.h. wenn die Anzahl der Felder nicht gleich Null ist, ist der Wert des Formulars eine Handhabe zur Feldreihenfolge des Formulars.
Achtung: die zurückgegebene Handhabe zeigt auf die Datenstruktur des Formulars und sollte nicht geändert werden. Wenn der zurückgegebene Wert modifiziert werden soll, sollte er in einen privaten Speicher kopiert werden.

Form_set_data_pointer

Bei einem Formular variabler Größe weist Form_set_data_pointer den gegebenen Zeiger den Punkten des Formulardatenabschnittes zu. Form_set_data_pointer stellt einen Kopiervorgang mit Zeigersemantik im Gegensatz zur Kopier-Semantik zur Verfügung.
Wenn es sich bei dem gegebenen Formular um ein Formular fixer Länge handelt, wird die Fehlermarke auf FORM_ERR_CANT_ASSIGN_POINTER_TO_FIXED_FORM gesetzt.

Form_field_Set_data

Dies ist eine komfortable Routine, die dem Aufruf von Form_field_get und der darauffolgenden Verwendung des geholten Formulars zum Aufruf von Form_set_data entspricht. Präziser: form_field_Set_data(form, field_id, form_data, size) == form_Set_data(form_field_get (form, field_id), form_data, size), plus Fehlerüberprüfung.

Form_field_get_data

Man beachte, daß wir die Kopier-Semantik für Zuweisungen verwenden.
Dies ist eine komfortable Routine, die dem Aufruf von Form_field_get und der darauffolgenden Verwendung des geholten Formulars zum Aufruf von Form_get_data entspricht. Präziser: form_field_get_data(form, field_id, form_data, size) form_get_data(form_field_get (form, field_id), form_data, size) plus Fehlerüberprüfung.
Achtung: die zurückgegebene Handhabe zeigt auf die Datenstruktur des Formulars und sollte nicht geändert werden. Wenn der zurückgegebene Wert modifiziert werden soll, sollte er in einen privaten Speicher kopiert werden.

form_field_id_first

Form_field_id_first setzt die gegebene field-id, um das erste direkte Feld der gegebenen Formular-Handhabe zu identifizieren.
Man beachte, daß der Speicher für die gegebene field_id von den Clients des Formularpakets und nicht vom Formularpaket zugewiesen (und freigegeben) werden sollte.

form_field_id_next

Form_field_id_next setzt die gegebene field-id, um das nächste direkte Feld der gegebenen Formular-Handhabe zu identifizieren. Aufrufen von Form_field_id_next muß ein Aufruf von Form_field_id first vorangehen.
Man beachte, daß der Speicher für die gegebene field_id von den Clients des Formularpakets und nicht vom Formularpaket zugewiesen (und freigegeben) werden sollte.

Form_field_set

Setzt das gegebene Formular oder die Formularsequenz als gegebenen Formularfeldwert. Man beachte, daß wir die Kopie-Semantik für zuweisungen verwenden.
Wird eine nichtexistente Feldkennung (field_id) angegeben, so wird die Fehlermarke auf FORM_ERR_ILLEGAL_ID gesetzt.

Form_field_get

Gibt eine Handhabe an den Wert des angeforderten Feldes zurück. Der zurückgegebene Wert ist entweder eine Handhabe zu einem Formular oder zu einer Formularsequenz.
Achtung: die zurückgegebene Handhabe zeigt auf die Datenstruktur des Formulars und sollte nicht geändert werden. Wenn der zurückgegebene Wert modifiziert werden soll, sollte er mit Hilfe der Form_copy-Funktion in einen privaten Speicher kopiert werden.
Wird eine nichtexistente Feldkennung (field_id) angegeben, so wird die Fehlermarke auf FORM_ERR_ILLEGAL_ID gesetzt, und Form_field_get gibt NULL zurück.

Form_field_append

Form_field_append hängt das gegebene append-form- Argument an das Ende der base-form Formularsequenz an. Form_field_append gibt die Kennung (id) des angehängten neuen Feldes zurück.

Form_field_delete

Form_field_delete löscht das gegebene Feld aus der gegebenen base_form.
Wird eine nichtexistente Feldkennung (field_id) angegeben, so wird die Fehlermarke auf FORM_ERR_ILLEGAL_ID gesetzt, und Form_field_delete gibt NULL zurück.

Form_pack

Form_pack gibt einen Zeiger zu einem Byte-Strom zurück, der das paketierte Formular enthält, das gemäß dem angeforderten Format und Typ paketiert wurde.
Wenn es sich bei dem angeforderten Pakettyp um FORM_PACK_LIGHT handelt, ordnet Form_pack das Formular der Reihe nach an, aber die Formulardaten werden nicht in eine maschinenunabhängige Darstellung übersetzt. Daher eignet sich ein leicht paketiertes Formular zur Übertragung zwischen Prozessen auf der selben Maschine.
Wenn es sich bei dem angeforderten Pakettyp um FORM_PACK_XDR handelt, ordnet Form_pack das Formular der Reihe nach an und übersetzt die Formulardarstellung auch in eine maschinenunabhängige Darstellungsform, bei der es sich um XDR von Sun handelt. Daher eignen sich Formulare, die mit einem XDR-Format paketiert wurden, zur Übertragung über ein Netzwerk über Maschinengrenzen hinweg.
Formularklassen werden als Formulare implementiert, daher kann Form_pack dazu verwendet werden, sowohl Formularklassen als auch Formulare zu paketieren.

Form_unpack

Bei einer externen Darstellung des Formulars erzeuge eine Formularinstanz gemäß der gegebenen Klasse und entpacke die externe Darstellung in die Instanz.
Formularklassen werden als Formulare implementiert, daher kann Form_unpack dazu verwendet werden, sowohl Formularklassen als auch Formulare zu entpacken.

Form_copy

Kopiere die Werte des Quellformulars in das Bestimmungsformular. Wenn die Formulare zu unterschiedlichen Klassen gehoren, wird kein Kopieren durchgeführt, und der Fehlerwert wird auf FORM_ERR_ILLEGAL_CLASS aktualisiert.
Formularklassen werden als Formulare implementiert, daher kann Form_copy dazu verwendet werden, sowohl Formularklassen als auch Formulare zu kopieren.

Form_show

Gib eine ASCII-Zeichenkette zurück, welche die Liste der Feldbezeichnungen und der dazugehörigen Werte für die angegebenen Felder enthält. Die Zeichenkette eignet sich für die Darstellung an einem Terminal oder zum Drucken (z.B. enthält sie Neuzeilenzeichen). Die zurückgegebene Zeichenkette wird von der Funktion zugeteilt und muß vom Anwender freigegeben werden. (Diese Funktion ist bei der Fehlersuche sehr hilfreich.)
Formularklassen werden als Formulare implementiert, daher kann Form_show dazu verwendet werden, sowohl Formularklassen als auch Formulare zu drucken.

Form_iserr

Gibt TRUE (Wahr) zurück, wenn die Fehlermarke gesetzt ist, ansonsten FALSE (Falsch)

Form_errno

Gibt die Fehlernummer der Formularklasse zurück. Wenn kein Fehler vorhanden ist, gibt sie FORMCLASS_OK zurück. Die möglichen Fehlerwerte sind in den Dateiformularen definiert.

GLOSSAR

Es folgt nun eine Liste der Definitionen einiger der in dieser Beschreibung der Erfindung verwendeten Wörter und Phrasen.
Format oder Typ: Die Datendarstellung und Datenorganisation eines strukturellen Datensatzes, d.h., eines Formulars.
Fremd: Ein Computer oder ein Softwareprozeß, der ein anderes Format oder einen anderen Datensatz verwendet als der Formatdatensatz eines anderen Computers oder Softwareprozesses.
Formular: Ein Datensatz oder Datenobjekt, dessen Struktur durch Einschluß von Feldern, welche Klassendeskriptornummern enthalten, die Klassendeskriptoren oder Klassendefinitionen entsprechen, selbstbeschreibend ist. Diese Klassendeskriptoren beschreiben eine Formularklasse, deren Instanzen zur Gänze die selbe interne Darstellung, die selbe Organisation und die selben semantischen Informationen aufweisen. Dies bedeutet, daß alle Instanzen, d.h. Vorkommnisse von Formularen dieser Klasse, die selbe Anzahl an Feldern der selben Bezeichnung haben, und daß die Daten in den entsprechenden Feldern die selbe Darstellung aufweisen und jedes entsprechende Feld das gleiche bedeutet. Formulare können entweder primitiv oder konstruiert sein. Ein Formular ist primitiv, wenn es nur eine einzelne Dateneinheit speichert. Ein Formular ist konstruiert, wenn es mehrere interne Komponenten, die als Felder bezeichnet werden, besitzt. Jedes Feld ist selbst ein Formular, das entweder primitiv oder konstruiert ist. Jedes Feld kann Daten oder die Klassenkennung, d.h. die Klassennummer, eines anderen Formulars speichern.
Klasse/Klassendeskriptor/Klassendefinition: Eine Definition der Struktur und Organisation einer bestimmten Gruppe von Datensätzen oder "Formularen", die alle die selbe interne Darstellung, die selbe Organisation und die selben semantischen Informationen besitzen. Ein Klassendeskriptor ist ein Datensatz oder "Objekt" im Speicher, das die Daten speichert, die alle diese Parameter der Klassendefinition definieren. Die Klasse ist die Bezeichnung der Gruppe von Formularen, und die Klassendefinition ist die Information über die allgemeinen Merkmale der Gruppe. Klassen können entweder primitiv oder konstruiert sein. Eine primitive Klasse enthält eine Klassenbezeichnung, die auf einzigartige Weise die Klasse kennzeichnet (dieser Bezeichnung ist eine Klassennummer oder Klassenkennung zugewiesen) und eine Beschreibung der Darstellung eines einzelnen Datenwertes. Die Beschreibung der Darstellung verwendet gut bekannte Primitiven, die der Host-Computer und die dient- Anwendungen verstehen, wie z.B. string_20 ASCII, Fließkomma, Ganzzahlen, string_20 EBCDIC usw. Eine konstruierte Klassendefinition umfaßt einen einzigartigen Namen und definiert nach Namen und Inhalt mehrere Felder, die in dieser Art Formular vorkommen. Die Klassendefinition beschreibt die Organisation und Semantik oder das Formular durch Beschreibung der Feldnamen. Die Feldnamen verleihen den Feldem Bedeutung. Jedes Feld wird durch Angabe eines Feldnamens und der Formularklasse seiner Daten beschrieben, da jedes Feld selbst ein Formular ist. Bei einem Feld kann es sich um eine Liste von Formularen der selben Klasse anstatt eines einzelnen Formulars handeln. Eine konstruierte Klassendefinition enthält keine aktuellen Daten, obwohl ein Klassendeskriptor dies in Form von Daten tut, welche die Organisation und Semantik dieser Formularart definieren. Alle aktuellen Daten, die Instanzen von Formularen definieren, werden in Formularen von primitiven Klassen gespeichert, und der in primitiven Klassen gespeicherte Datentyp wird in der Klassendefinition der primitiven Klasse beschrieben. Zum Beispiel besitzt die primitive Klasse mit der Bezeichnung "Age" (Alter) ein Feld des Typs integer_3, das in der Klassendefinition für die Altersklasse der Formulare definiert ist. Formularinstanzen dieser Klasse enthalten dreistellige Ganz zahlenwerte.
Feld: Eine Komponente (?) in einer Instanz eines Formulars, die eine oder mehrere Komponenten (?) besitzen kann, welche jeweils anders bezeichnet sind und jeweils etwas anderes bedeuten. Felder sind "primitiv", wenn sie aktuelle Daten enthalten, und sie sind "konstriert", wenn sie andere Formulare enthalten, wie z.B. Gruppierungen anderer Felder. Ein Datensatz oder ein Formular, das mindestens ein Feld enthält, welches ein anderes Formular enthält, wird als verschachtelt bezeichnet. Das zweite im konstruierten Feld aufgezeichnete Formular eines ersten Formulars besitzt seine eigenen Felder, die ebenfalls primitiv oder konstruiert sein können. Somit sind unendlich komplexe Verschachtelungsschichten möglich.
Prozeß: Eine Instanz eines Softwareprogramms oder Softwaremoduls, das auf einem Computer ausgeführt wird.
Semantische Information: Die Namen und Bedeutungen der verschiedenen Felder in einem Formular im Hinblick auf Formulare.
Verschachtelt: Eine Datenstruktur, bestehend aus Datensätzen mit mehreren Feldern, von denen ein jeder selbst andere Datensätze mit mehreren Feldern enthalten kann.
Primitives Feld: Ein Feld oder ein Formular oder ein Datensatz, in dem aktuelle Daten gespeichert werden.
Konstruiertes Feld: Ein Feld, das ein anderes Formular oder einen anderen Datensatz enthält.
Formatoperation: Eine Operation zum Umwandeln eines Formulars von einem Format in ein anderes Format.
Semantisch abhängige Operation: Eine Operation, die zumindest Zugriff auf die semantischen Informationen der Klassendefinition für ein bestimmtes Formular erfordert, um einem anfordernden Prozeß Daten von jenem Formular zu liefern.
Anwendung: Ein Software-Programm, das auf einem Computer läuft, aber nicht zu den Betriebssystemprogrammen zählt.
Entkoppelung: Das Befreien eines Prozesses, eines Softwaremoduls oder einer Anwendung von der Notwendigkeit, die Kommunikationsprotokolle, Datenformate und Positionen aller anderen Prozesse, Computer und Netzwerke kennen zu müssen, mit denen Daten ausgetauscht werden sollen.
Klasse: Eine Definition einer Gruppe von Formularen, wobei alle Formulare in der Klasse das selbe Format und die selbe Semantik besitzen.
Schnittstelle: Eine Bibliothek von Softwareprogrammen oder Softwaremodulen, die durch eine Anwendung oder ein anderes Modul der Schnittstelle aufgerufen werden kann, die Unterstützungsfunktionen zur Ausführung von Tasks bieten. Im Falle der vorliegenden Erfindung bietet die Kommunikationsschnittstelle eine Programmbibliothek, die die gewünschte Entkoppelung zwischen fremden Prozessen und Computern implementiert, um eine vereinfachte Programmierung von Anwendungen zum Austausch von Daten mit fremden Prozessen und Computern zu ermöglichen.
Subskriptionsanforderung: Eine Anforderung für Daten bezüglich eines bestimmten Gegenstandes, welche nicht den Quellserver oder die Quellserver, den Prozeß oder die Prozesse oder die Position derselben beschreibt, von dem die Daten bezüglich dieses Gegenstandes erhalten werden können.
Service-Datensatz: Ein Datensatz, der Felder enthält, welche die wichtigen Merkmale einer Anwendung beschreibt, die das angegebene Service liefert.
Serverprozeß: Ein Anwendungsprozeß, der die Funktionen der Daten zur Verfügung stellt, die von einem bestimmten Service, wie zum Beispiel Telerate, Dow Jones News Service, usw., beschrieben werden.
Service-Disziplin oder Service-Protokoll: Das Protokoll für die Kommunikation mit einem bestimmten Server- Prozeß, einer Anwendung oder einem lokalen Datennetz.
Client-Anwendung: Eine Anwendung, die mit den Bibliotheken der Kommunikationsschnittstelle gemäß den Lehren der Erfindung oder auf andere Art und Weise mit einem Service verknüpft ist.
Transportschicht: Eine Schicht des standardmäßigen ISO-Modells für Netzwerke zwischen Computern, mit denen die Kommunikationsschnittstelle der Erfindung verknüpft ist.
Transportschichtprotokoll: Das in einem bestimmten Netzwerk jeweils implementierte Kommunikationsprotokoll oder die Kommunikationsdisziplin.
Service: Eine sinnvolle Gruppe von Funktionen oder Daten, die eine Anwendung exportieren kann, damit sie von dient-Anwendungen verwendet wird. In anderen Worten ist ein Service eine allgemeine Klasse von Anwendungen, die eine bestimmte Tätigkeit durchführen, wie z.B. Anwendungen, die Dow Jones News Informationen liefern.
Service-Instanz: Ein Prozeß, der auf einem bestimmten Computer läuft und der in der Lage ist, das angegebene Service zur Verfügung zu stellen (wird auch manchmal als Server-Prozeß bezeichnet)
Server: Ein Computer, auf dem ein bestimmter Prozeß läuft, um etwas auszuführen, wie zum Beispiel Dateien, die in einem Massenspeicher gespeichert sind, oder Rohdaten von einer Informationsquelle, wie zum Beispiel Telerate, an ein Netzwerk oder einen anderen Computer bzw. eine andere Workstation zuzuführen, damit diese an andere Prozesse, die an den Server angekoppelt sind, verteilt werden können.
Gegenstandsraum: Eine hierarchische Gruppe von Gegenstandskategorien.
Gegenstandsdomäne: Eine Gruppe von Gegenstandskategorien (siehe auch Gegenstandsraum).
Klassendefinition: Die Beschreibung einer Formularklasse.
Klassendeskriptor: Ein Speicherobjekt, das die Formularklassendefinition speichert. Im Klassenmanager wird sie als Formular gespeichert. Auf Platte wird sie als ASCI-Zeichenkette gespeichert. Grundsätzlich handelt es sich um eine bestimmte Darstellung oder ein Format einer Klassendefinition. Es kann sich um eine ASCII-Datei oder eine Formularart der Darstellung handeln. Wenn der Klassenmanager keinen Klassendeskriptor besitzt, den er benötigt, frägt er die fremde Anwendung, welche die Klassendefinition erzeugt hat, nach dem Klassendeskriptor. Darauf erhält er einen Klassendeskriptor im Format eines Formulars, wie es von der fremden Anwendung erzeugt wird. Alternativ dazu sucht der Klassenmanager nach einer Datei oder nach Dateien, die für ihn von der Anwendung identifiziert werden, welche die semantisch abhängige Operation anfordert, oder die in Datensätzen identifiziert sind, die vom Klassenmanager gewartet werden. Die in diesen Dateien gespeicherten Klassendefinitionen liegen im ASCII-Textformat vor. Der Klassenmanager wandelt danach den so gefundenen ASCII-Text in einen Klassendeskriptor im Format eines nativen Formulars um, indem er den ASCII-Text in die verschiedenen Feldnamen und Beschreibungen für den Inhalt der einzelnen Felder zergliedert.
Natives Format/Formular: Das ursprüngliche Format eines Formulars oder die Formularstruktur einer Anwendung und ihres Host-Computers.
Kennung: Eine einzigartige Kennung für ein Formular, einen Datensatz, eine Klasse, ein Speicherobjekt usw. Die in dieser Patentbeschreibung den Klassen zugewiesenen Klassennummern sind Beispiele für Kennungen.
Handhabe: Ein Zeiger zu einem Objekt, Datensatz, einer Datei, einem Klassendeskriptor, einem Formular usw. Dieser Zeiger definiert im wesentlichen einen Zugriffspfad zum Objekt. Absolute, relative und Offset-Adressen sind Beispiele für Handhaben.
Klassendatenstruktur: Alle in einem Klassenmanager gespeicherten Daten bezüglich einer bestimmten Klasse. Der Klassendeskriptor ist der wichtigste Teil dieser Datenstruktur, aber es können auch weitere Informationen vorhanden sein.
Konfigurationsdatei: Eine Datei, die Daten speichert, welche die Eigenschaften und Attribute oder Parameter der verschiedenen Softwarekomponenten, Sätze und Formulare beschreibt.
Attribut einer Formularklasse: Eine Eigenschaft der Formularklasse, die angibt, ob die Klasse zum Beispiel primitiv oder konstruiert ist. Größe ist ein anderes Attribut.

Claims

1. Eine Einrichtung zum übertragen von Daten zwischen Anwendungen (16, 18), die auf unterschiedlichen computern (10, 196) laufen, welche durch ein Kommunikationsnetzwerk oder einen anderen Datenübertragungsweg (14) verbunden sind, die Einrichtung umfaßt:

(a) Mittel (180) zum Empfangen einer Subskriptions- Anf orderung von wenigstens einer der Anwendungen nach Informationen über einen bestimmten Gegenstand und Abbilden des besagten Gegenstandes auf ein oder mehrere Service-Disziplin-Mittel (182, 184, 186), die geeignet sind, mit einer Daten-Publikationsanwendung zu kommunizieren, welche Daten über den besagten Gegenstand enthält;

(b) Mittel (181) zum Aufrufen von einem oder mehreren Service-Disziplin-Mitteln, die durch besagte Abbildungsmittel bestimmt werden zum Zugriff auf einen Service, der sich auf besagten Gegenstand in besagter Publikationsanwendung bezieht, und zum Herstellen einer Kommunikationsverbindung (202) über besagtes Netzwerk oder besagten anderen Datenübertragungsweg zur Benutzung durch besagte Daten-Publikationsanwendung für die Kommunikation von Daten über besagten Gegenstand; und

(c) Mittel (184) zum Beendigen besagter Kommunikationsverbindung, wenn besagte Subskriptions-Anforderung aufgehoben wird.

2. Die Einrichtung nach Anspruch 1, worin besagte Abbildungsmittel (180) Mittel enthalten zum Bestimmen der Netzwerkadresse für den Service, der Informationen über den besagten Gegenstand liefert.

3. Die Einrichtung nach Anspruch 1, umfassend Mittel, die durch besagte Aufrufmittel ausgewählt werden zum Filtern von Daten, welche durch besagte Daten-Publikationsanwendung nach Gegenständen publiziert werden, so daß nur Daten über den angeforderten Gegenstand durch die hergestellte Kommunikationsverbindung zu besagtem anfordernden Programm geliefert werden.

4. Die Einrichtung nach Anspruch 3, worin eine der besagten Service-Disziplinen (184) die besagte Filterfunktion ausführt.

5. Die Einrichtung nach Anspruch 1, worin in besagte Service-Disziplin-Mittel ein geeignetes Übertragungs protokoll eingekapselt ist zum Zugriff auf den Service, auf den sich die bestimmte Service-Disziplin bezieht.

6. Die Einrichtung nach Anspruch 1, umfassend Rückrufmittel in besagter wenigstens einer der Anwendungen, zu der die Information über den Gegenstand übertragen wird, besagte Rückrufmittel werden gegenüber den besagten Abbildungsmitteln durch einen Namen identifiziert, der in besagter Subskriptions-Anforderung enthalten ist, und worin besagte Abbildungsmittel eine geeignete Service-Disziplin (182) bestimmen, welche die zur Weiterleitung zu besagten Rückrufmitteln zu übertragenden Daten empfängt.

7. Die Einrichtung nach Anspruch 1, umfassend Service- Verzeichnis-Mittel (192) zum Verwalten einer Sammlung von Service-Datensätzen, die anzeigen, welche Services Informationen über welche Gegenstände liefern, wo sich Services befinden und welche besonderen Service-Disziplin- Mittel von den Services zur Kommunikation benutzt werden, besagte Verzeichnis-Mittel sprechen auf eine Suchanforderung von besagten Abbildungsmitteln an, die Parameter des Gegenstandes enthalten für ein Durchsuchen der Service-Datensätze, bis ein Service-Datensatz gefunden ist, der einen bestimmten Service oder Services über den gewünschten Gegenstand anzeigt, und für ein Rückübertragen des gefundenen Datensatzes zu besagten Abbildungsmitteln.

8. Die Einrichtung nach Anspruch 7, worin besagter Service-Datensatz für jeden der besagten Services Daten enthält, die den Namen des Informationen über den gewünschten Gegenstand liefernden Service, den Namen der von diesem Service benutzten Service-Disziplin-Mittel und den Namen des Computers anzeigen, auf dem dieser Service läuft.

9. Die Einrichtung nach Anspruch 7, worin besagte Service- Verzeichnis-Mittel als ein separater Prozeß betrieben werden, der auf einem mit besagtem Netzwerk oder anderen Datenübertragungsweg verbundenen Computer läuft.

10. Die Einrichtung nach Anspruch 1, weiter umfassend Datenaustausch-Mittel (20), die mit besagten Service- Disziplin-Mitteln verbunden sind zur Anpassung besagter Service-Disziplin-Mittel an ein Übertragungsprotokoll des besagten Netzwerks oder anderen Datenübertragungswegs zum Herstellen einer Kommunikationsverbindung über besagtes Netzwerk oder anderen Datenübertragungsweg.

11. Die Einrichtung nach Anspruch 5, worin besagte Datenaustausch-Mittel umfassen:

Mittel (122) zum Erzeugen und Verändern selbstbeschreibender Datensätze oder Formulare, die sowohl Daten als auch Klassen-Identifikationsdaten entsprechend einer oder mehrerer Klassendefinitionen enthalten, welche die Namen und die Organisation von Feldern in besagten Formularen sowie das Datenformat zur Darstellung der Daten in besagten Feldern definieren; und

Mittel (86) zur Umsetzung des Formats des Formulars in einem der besagten ersten Anwendung eigenen Format in das Format der besagten zweiten Anwendung für eine Übertragung zu besagter zweiten Anwendung.

12. Eine Einrichtung zur Übertragung von Daten in einer Umgebung, die einen oder mehrere Computer (230) und ein Netzwerk zur Kopplung besagter Computer durch einen oder mehrere Datenübertragungswege (14) umfaßt und die ein Transportschichten- Protokoll und wenigstens einen Datenpublikationsprozeß aufweist, der in wenigstens einem der besagten Computer ausgeführt wird, um wenigstens eine Serviceinstanz zu implementieren, die zum Übertragen von Daten über besagtes Netzwerk oder anderen Datenübertragungsweg geeignet ist, besagte Einrichtung umfaßt:

(a) wenigstens einen Anwendungsprozeß (16, 18), der durch wenigstens einen der besagten Computer (230) ausgeführt wird zum Durchführen verschiedener Operationen einschließlich der Anforderung von Daten nach einem Gegenstand;

(b) Abbildungsmittel (233, 30A) zum Abbilden des besagten Gegenstandes auf eine Adresse von einer oder mehreren Serviceinstanzen; Service-Disziplin-Mittel (234, 236, 238) zum Empfangen einer Subskriptionsanforderung von wenigstens einem der besagten Anwendungsprozesse zum Erhalt von Daten von wenigstens einer spezifizierten Serviceinstanz und zum Ausführen der Operationen für die Herstellung einer Kommunikationsverbindung zu besagter Serviceinstanz über besagtes Netzwerk oder besagten anderen Datenübertragungsweg unter Benutzung geeigneter Übertragungsprotokolle zur Kommunikation mit besagter Serviceinstanz, um besagte Daten zu erhalten, immer wenn Daten durch besagte Serviceinstanz veröffentlicht werden, und zur automatischen Übertragung der besagten Daten zu besagtem Anwendungsprozeß, der besagte Daten anfordert, bis besagter Anwendungsprozeß die besagte Subskriptions anforderung aufhebt;

(c) wenigstens ein Protokoll-Engine-Programm-Mittel (237, 239, 241), das auf wenigstens einem der besagtem Computer ausgeführt wird und mit besagten Service- Disziplin-Mitteln gekoppelt ist zur Anpassung besagter Service-Disziplin-Mittel an besagtes Transportschichten- Protokoll zur Herstellung der besagten Kommunikationsverbindung über besagtes. Netzwerk oder besagten anderen Datenübertragungsweg.

13. Die Einrichtung nach Anspruch 12, worin besagte Service- Disziplin-Mittel konfiguriert sind zur Herstellung einer Punkt-zu-Punkt-Kommunikation zwischen dem besagten wenigstens einen Datenpublikationsprozeß und dem besagten wenigstens einem Anwendungsprozeß.

14. Ein Verfahren zum Übertragung von Daten zwischen Anwendungen (16, 18), die auf unterschiedlichen Computern (10, 196) laufen, welche durch ein Kommunikationsnetzwerk oder einen anderen Datenübertragungsweg (14) verbunden sind, umfassend die Schritte:

(a) Erzeugen einer Anforderung von Informationen über einen Gegenstand durch eine der Anwendungen (16);

(b) Abbilden des besagten Gegenstandes auf eine oder mehrere Service-Disziplinen (182, 186), die geeignet sind, mit einer Daten-Publikationsanwendung zu kommunizieren, welche Daten über besagten Gegenstand enthält;

(c) Aufrufen einer oder mehrerer der besagten Service- Disziplinen zum Herstellen einer Kommunikationsverbindung (202) über besagtes Netzwerk oder besagten anderen Datenübertragungsweg, das oder der durch besagte Daten-Publikationsanwendung benutzt wird für die Publikation von Daten über besagten Gegenstand; und

(c) Beendigen besagter Kommunikationsverbindung, wenn besagte Subskriptions-Anforderung aufgehoben wird.

15. Das Verfahren nach Anspruch 14, worin besagter Abbildungsschritt den Schritt umfaßt, die Netzwerkadresse für den Service zu bestimmen, der Informationen über den besagten Gegenstand liefert.

16. Das Verfahren nach Anspruch 14, umfassend den Schritt der Filterung von Daten, die durch besagte Daten-Publikationsanwendung nach Gegenständen publiziert werden, so daß nur Daten über den angeforderten Gegenstand durch die hergestellte Kommunikationsverbindung zu besagtem anfordernden Programm geliefert werden.

17. Das Verfahren nach Anspruch 14, worin eine der besagten Service-Disziplinen (184) den besagten Schritt der Filterung ausführt.

18. Das Verfahren nach Anspruch 14, worin in besagter Service-Disziplin ein geeignetes Übertragungsprotokoll eingekapselt ist zum Zugriff auf den Service, auf den sich die bestimmte Service-Disziplin bezieht.

19. Das Verfahren nach Anspruch 14, umfassend den Schritt des Einschließens eines Rückrufprogramms in besagte wenigstens eine der Anwendungen, zu der die Informationen über den Gegenstand übertragen werden, besagtes Rückrufprograinm wird gegenüber besagten Abbildungsmitteln durch einen Namen identifiziert, der in besagter Subskriptions- Anforderung enthalten ist, und worin besagter Abbildungsschritt den Schritt der Bestimmung einer geeigneten Service-Disziplin (182) enthält, welche die zur Weiterleitung zu besagtem Rückrufprogramm zu übertragenden Daten empfängt.

20. Das Verfahren nach Anspruch 14, umfassend den Schritt: Verwalten einer Sammlung von Service-Datensätzen, die anzeigen, welche Services Informationen über welche Gegenstände liefern, wo sich die Services befinden und welche Service-Disziplin von den Services zur Kommunikation benutzt werden, Durchsuchen der Sammlung von Service-Datensätzen in Beantwortung einer Suchanforderung, die durch besagten Abbildungsschritt erzeugt wird und Parameter des Gegenstandes enthält, bis ein Service-Datensatz gefunden ist, der einen bestimmten Service oder Services über den gewünschten Gegenstand anzeigt, und Rückübertragen des gefundenen Datensatzes zu besagten Abbildungsmitteln.

21. Das Verfahren nach Anspruch 20, worin besagter Service-Datensatz für jeden der besagten Services Daten enthält, die den Namen des Informationen über den gewünschten Gegenstand liefernden Service, den Namen der von diesem Service benutzten Service-Disziplin und den Namen des Computers anzeigen, auf dem dieser Service läuft.

22. Das Verfahren nach Anspruch 20, worin besagter Schritt zur Verwaltung und zum Betrieb des Service-Datensätze als ein separater Prozeß konfiguriert ist, der auf einem mit besagtem Netzwerk oder besagten anderen Datenübertragungsweg verbundenen Computer läuft.

23. Das Verfahren nach Anspruch 14, weiter umfassend den Schritt des Austausches von Daten in Beantwortung der besagten aufgerufenen einen oder mehreren Service- Disziplin(en) zur Anpassung der besagten aufgerufenen einen oder mehreren Service-Disziplin(en) an ein Übertragungsprotokoll des besagten Netzwerks oder anderen Datenübertragungswegs zum Herstellen einer Kommunikationsverbindung über besagtes Netzwerk oder anderen Datenübertragungsweg.

24. Das Verfahren nach Anspruch 23, worin besagter Schritt des Austausches von Daten die Schritte enthält:

Erzeugen und Verändern selbstbeschreibender Datensätze oder Formulare, die sowohl Daten als auch Klassen-Identifikationsdaten entsprechend einer oder mehrerer Klassendefinitionen enthalten, welche die Namen und die Organisation von Feldern in besagten Formularen sowie das Datenformat zur Darstellung der Daten in besagten Feldern definieren; und

Umsetzung des Formats des Formulars in einem der besagten ersten Anwendung eigenen Format in das Format der besagten zweiten Anwendung für eine Übertragung zu besagter zweiten Anwendung.

25. Ein Verfahren zur Übertragung von Daten in einer Umgebung, die einen oder mehrere Computer (230) und ein Netzwerk zur Kopplung besagter Computer durch einen oder mehrere Datenübertragungswege (14) umfaßt und die ein Transportschichten-Protokoll und wenigstens einen Datenpublikationsprozess enthält, der in wenigstens einem der besagten Computer ausgeführt wird, um wenigstens eine Serviceinstanz zu implementierenf die zum übertragen von Daten über besagtes Netzwerk oder einen anderen Datenübertragungsweg geeignet ist, das Verfahren umfaßt die Schritte:

(a) Anforderung von Daten nach einem Gegenstand von wenigstens einen Anwendungsprozeß (16, 18), der in wenigstens einem der besagten Computer ausgeführt wird;

(b) Abbilden des besagten Gegenstandes auf eine Adresse von einer oder mehreren Serviceinstanzen zur Bezeichnung von wenigstens einer Serviceinstanz;

(c) Empfangen einer Subskriptionsanforderung von wenigstens einem der besagten Anwendungsprozesse zum Erhalt von Daten von wenigstens einer spezifizierten Serviceinstanz (234, 236, 238) und zum Ausführen der Operationen für die Herstellung einer Kommunikationsverbindung zu besagter Serviceinstanz über besagtes Netzwerk oder besagten anderen Datenübertragungsweg unter Benutzung geeigneter Übertragungsprotokolle zur Kommunikation mit besagter Serviceinstanz, um besagte Daten zu erhalten, immer wenn Daten durch besagte Serviceinstanz veröffentlicht werden, und zur automatischen Übertragung der besagten Daten zu besagtem Anwendungsprozeß, der besagte Daten anfordert, bis besagter Anwendungsprozeß die besagte Subskriptionsanforderung aufhebt; und

(d) Anpassung besagter Service-Disziplin an besagtes Transportschichten-Frotokoll (237, 239, 241) zur Herstellung der besagten Kommunikationsverbindung über besagtes Netzwerk oder besagten anderen Datenübertragungsweg.

26. DaS Verfahren nach Anspruch 25, worin besagte Service- Disziplin konfiguriert ist zur Herstellung einer Punkt-zu-Punkt-Kommunikation zwischen dem besagten wenigstens einen Datenpublikationsprozeß und dem besagten wenigstens einen Anwendungsprozeß.