Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

29.03.1991 - 

Viele Schnittstellen mit offenen Systemen gemeinsam

BS2000 hat sich in Richtung Interoperabilität entwickelt

Rechnerleistung ist heute an vielen Stellen im Unternehmen installiert. Jeder dieser Rechner verwaltet spezielle Betriebsmittel, die aber auch an anderer Stelle im Unternehmen benötigt werden. Auf unterschiedlichen Rechnern laufen unterschiedliche Anwendungen, deren Leistungen oft von vielen Teilen des Unternehmens in Anspruch genommen werden.

Alle diese Rechner sind miteinander durch Einbindung in entsprechende Netzwerk-Architekturen gekoppelt. Außerdem wurden zunehmend PCs oder Workstations installiert, deren Rechner- und Datenspeicherkapazität in den letzten Jahren dramatisch zugenommen hat. Dieser technologische Fortschritt erlaubt und erfordert neue Anwendungskonzepte, die davon ausgehen, daß die Zahl und Vielfalt der Instanzen, die bestimmte Abläufe optimal ausführen können, zunimmt.

Es ist sinnvoll, daß die Arbeit durch diejenige Instanz durchgeführt wird, die sie am besten leisten kann oder die die dafür notwendigen Ressourcen hat. Das führt dazu, daß mehrere Instanzen zusammenarbeiten (kooperieren), um einen Auftrag eines Endbenutzers optimal zu erledigen. Dies nennt man kooperative Verarbeitung oder Cooperative Processing. Zur Verdeutlichung dieser Betrachtungsweise seien einige markante Beispiele für Cooperative Processing beschrieben.

Einige Voraussetzungen müssen erfüllt sein

Ein Programm auf einem PC kooperiert mit einer Software auf einem zentralen Mainframe oder Abteilungsrechner, indem es selbst die Ergebnisse auf dem Bildschirm grafisch aufbereitet, den Auftrag zur Ermittlung der Ergebnisse jedoch an das Programm auf dem Mainframe weitergibt, auf dem die Daten zur Ermittlung des Ergebnisses zur Verfügung stehen. Bei diesem Beispiel handelt es sich um Cooperative Processing auf Anwendungsprogrammebene.

Auch auf der Systemebene gibt es Cooperative Processing von Instanzen auf unterschiedlichen Rechnern. Zum Beispiel können ein verteilter Transaktionsmonitor oder ein verteiltes Datenbank-System so implementiert sein, daß sie über mehrere Rechner verteilt sind und zur Erledigung eines Auftrages (einer verteilten Transaktion, eines Zugriffs auf verteilte Datenbanken) zusammenarbeiten.

Voraussetzung für Cooperative Processing ist also die Existenz mehrerer Rechner, die so gekoppelt sind, daß auf ihnen ablaufende Programme miteinander kommunizieren können. Hier sei auf das OSI-Schichtenmodell und die entsprechenden ISO-Protokolle verwiesen. Wir können heute feststellen, daß durch die weltweite Implementierung dieser Protokolle die Kommunikationsmöglichkeiten zwischen heterogenen Systemen weit fortgeschritten sind.

Neben diesen ISO-Protokollen gibt es auf dem Markt noch die wichtigen privaten Netzwerk-Architekturen wie zum Beispiel Transdata, SNA und Decnet, die einerseits jeweils innerhalb der Systemfamilien der jeweiligen Hersteller eine freie Kommunikation ermöglichen, andererseits durch Bereitstellung von entsprechenden Gateways die Koppelung der unterschiedlichen Netzwerk-Architekturen erlauben.

Je mehr Komfort der Systemanbieter für Cooperative Processing zur Verfügung stellt, um so einfacher wird die Implementierung entsprechend verteilter Lösungen. In diesem Sinne erwartet man heute neben der Möglichkeit einer Programm-zu-Programm-Kommunikation Produkte wie:

- Transaktionsmonitor mit der Fähigkeit der verteilten Transaktionsverarbeitung zur Implementierung von verteilten OLTP-Anwendungen (Transaktionsanwendungen),

- verteilte Datenbank-Systeme mit der Möglichkeit, Daten auf unterschiedliche Systeme zu verteilen und diese Verteilung für das Anwendungsprogramm transparent zu halten.

Wie aus den bisherigen Ausführungen erkennbar wird stellt zwar der Systemanbieter Produkte für das Cooperative Processing zur Verfügung. Es ist aber für den Nutzer wichtig durch die Wahl einer geeigneten Anwendungsarchitektur diese Produkte optimal und wirtschaftlich zu nutzen. Deshalb beschäftigt sich das nächste Kapitel etwas ausführlicher mit diesem Thema.

Bei der Definition der Anwendungsarchitektur geht man davon aus, daß beim Entwurf einer Anwendung durch Modularisierung darauf geachtet wird, daß verschiedene Funktionsbereiche der Anwendung logisch sauber zu trennen sind. Natürlich kann man sich unterschiedliche "Schnitte" vorstellen, zum Beispiel Trennung von auftragsbezogener Verarbeitung und Zugriff auf systemnahe Komponenten wie Datenbank-System und Transaktionsmonitor. Eine weitere Trennlinie könnte man ziehen zwischen Verarbeitung und Präsentation. Auf der Basis des zuletzt genannten Beispiels soll die Zielarchitektur für Anwendungen erläutert werden (Abbildung 1).

Bei Cooperative Processing erledigt jede der beteiligten Instanzen die Arbeit, für die sie am besten geeignet ist. Dies soll an einem Beispiel beleuchtet werden, wo die Verarbeitung (Datenbankzugriffe und Ausführung von Algorithmen) auf einem Verarbeitungsrechner (zum Beispiel BS2000- oder Sinix-Rechner) und die Präsentation auf einem programmierbaren grafischen Arbeitsplatz-System (zum Beispiel MS-DOS, OS/2, Unix-Workstation) erfolgt.

Der Teil der Anwendung, der die Verarbeitung durchführt, soll AWv genannt werden. Er ist dafür verantwortlich, den Auftrag des Endbenutzers (zum Beispiel Umsatzstatistik) durch Datenzugriff und entsprechende Berechnungen auszuführen und die Ergebniszahlen bereitzustellen. Diese Zahlen müssen an die zweite Komponente der Anwendung, die die Präsentation durchführt und die AWp genannt wird, übergeben werden. Da sich diese zweite Instanz AWp auf einem anderen Rechner befindet, wird die rechnerübergreifende Programm- zu Programm-Kommunikation genutzt, um die Daten zu senden. AWp nimmt die Ergebnisdaten entgegen und bereitet sie zum Beispiel unter Verwendung von OSF/Motif so auf, daß ein Torten- oder Balkendiagramm der Umsatzstatistik entsteht.

Damit ist zweierlei erreicht worden: Der Verarbeitungsrechner ist entlastet und die neuen Fähigkeiten des Arbeitsplatz-Systems mit seiner Rechnerleistung und den Grafikmöglichkeiten werden genutzt, um die Arbeit des Endbenutzers möglichst effektiv zu gestalten.

Zur einfachen Darstellung und Beschreibung wurde die Aufteilung AWv und AWp gewählt. Selbstverständlich lassen sich die Konzepte fortschreiben. AWv läßt sich in weitere Teile zerlegen, von denen gegebenenfalls einer wieder auf einem anderen Rechner ablaufen kann. Insbesondere ist es sinnvoll, AWp um lokale Vorverarbeitung (wie Plausibilitätsprüfungen) zu ergänzen und lokale Tools, etwa ein Spreadsheet, zu integrieren.

AWp wird damit zur Präsentations- und Steuerungskomponente.

In der Literatur wird für die hier beschriebene Architektur derzeit der Begriff Client-Server-Architektur verwendet, der in der zweiten Hälfte der 80er Jahre im Rahmen der Standardisierung der allgemeinen Büroservices eingeführt wurde. Der Client ist in der Regel am Arbeitsplatz installiert, und organisiert für den Endbenutzer den Zugang zu einem oder mehreren Services (Mail, Print, Directory, Filing and Retrieval etc.). Die hier beschriebene Anwendungsarchitektur für Cooperative Processing ist nichts anderes als die Verallgemeinerung dieses Ansatzes.

Abbildung 2 stellt dar, welche Möglichkeiten im BS2000, eingebunden in eine Landschaft heterogener Systeme, bezüglich Cooperative Processing existieren. Das Basisprodukt dafür ist der TP-Monitor UTM mit seiner Komponente UTM-D (Distribution), der auf BS2000 und Sinix gleichermaßen -zur Verfügung steht. Er unterstützt die transaktionsgesicherte Kooperation von Anwendungsprogrammen (AW), wobei die AW auf BS2000-Rechner und Sinix-Rechner verteilt sein können.

Es ist möglich, daß eine Transaktion über das gesamte Netz verteilt ist. Dabei können aus einer lokalen Verarbeitung im Rahmen einer Transaktion beliebig viele Unteraufträge sequentiell oder parallel an andere Systeme erteilt werden. In den verschiedenen Anwendungsprogrammen können unterschiedliche Datenbank-Systeme wie Sesam/SQL, UDS/SQL und Informix, aber auch Adabas und Oracle genutzt werden. Im Fehlerfall sorgt UTM für das Zurücksetzen der gesamten Transaktion im Netz und koordiniert dieses Zurücksetzen auch mit Sesam/SQL, UDS/SQL und Informix.

In UTM und UTM-D sind auch Protokolle implementiert, die eine Zusammenarbeit mit den TP-Monitoren IMS/DC und CICS auf MVS- und VSE-Systemen ermöglichen. Somit sind die Möglichkeiten eines Cooperative Processing auch auf diese IBM-Systeme ausgedehnt. Derzeit wird im UTM an der Implementierung des Protokolls OSI-TP (Protokoll für Transaction Processing) gearbeitet, das im Rahmen von ISO und X/Open verabschiedet wird, so daß in Zukunft UTM das Werkzeug für verteilte Transaktionsverarbeitung mit allen Systemen wird, die diese offenen Protokolle unterstützen. Dies ist ein weiterer Schritt zur Öffnung des BS2000 und zu seiner Einbindung in große heterogene Netze.

Die BS2000-Datenbank-Systeme Sesam/SQL und UDS/SQL unterstützen mit den Zusatzprodukten Sesam-DCN und UDS-D verteilte Datenbanken (Abbildung 2), das heißt, Programme können auf Daten zugreifen, die sich auf einem beliebigen BS2000-Rechner im Netz befinden. Dies gilt für den homogenen Fall, Sesam verwaltet also Sesam-Datenbanken und UDS verwaltet UDS-Datenbanken. Innerhalb einer solchen DB-Transaktion sind sowohl Retrieval als auch Updates auf einem, mehreren oder allen betroffenen Rechnern im Netz erlaubt und die Datenbank-Systeme sorgen im Fehlerfall dafür, daß alle Veränderungen einer Transaktion im ganzen Netz gleichzeitig zurückgesetzt werden. Außerdem werden diese Rücksetzaktionen des TP-Monitors UTM synchronisiert.

Für Sinix wird mit Informix-Star ein verteiltes Datenbank-System angeboten, das in seiner derzeitigen Ausprägung das Update von Datenbanken nur an einem Rechner zuläßt (wie zum Beispiel auch Oracle). Wird in einem heterogenen Rechnernetz die Funktionalität eines verteilten Datenbank-Systems benötigt, so steht für BS2000 und Sinix das Produkt Oracle oder Oracle Corporation zu Verfügung.

Auch das Produkt Adabas der Software AG wird demnächst verteilte Datenbanken im BS2000 unterstützen.

In offenen Systemen sind Schnittstellen und Services vorhanden, die es erlauben, Anwendungen so zu entwickeln,

- daß sie sich auf unterschiedliche Systeme portieren lassen (Portabilität),

- daß sie mit Anwendungen auf anderen Systemen kooperieren können (Interoperabilität) und

- daß Endbenutzer in der Lage sind, auf konsistente Art mit ihnen zu arbeiten (konsistente Benutzerschnittstellen).

Über die Fähigkeiten des BS2000 bezüglich Cooperative Processing wurde ausführlich berichtet (Interoperabilität). Durch die empfohlene Anwendungsarchitektur werden Verarbeitung und Präsentation getrennt. Die Präsentation kann auf das Arbeitsplatz-System ausgelagert werden und läßt sich dort (mit OSF/Motif, Windows oder Presentation Manager) so gestalten, daß sie dem Endbenutzer ein einheitliches Erscheinungsbild liefert (konsistente Benutzerschnittstellen). Die Siemens-Nixdorf Informationssysteme AG stellt hierzu den SNI-Styleguide für den Entwurf von Anwendungsoberflächen zur Verfügung.

Zum Punkt Portabilität von Anwendungen hat Siemens Nixdorf im Rahmen seines Systemkonzepts strategische Schnittstellen (SIA: System Interfaces for Applications) festgelegt, die auf den Plattformen BS2000, Sinix, OS/2 und MS-DOS angeboten werden und damit die Portabilität von Anwendungen zwischen diesen Plattformen ermöglichen. Hier seien die wichtigsten dieser Schnittstellen aufgezählt.

Ein Anwendungsprogramm ist in einer Programmiersprache geschrieben (3GL und 4GL), greift auf Dateien oder Datenbanken zu, hat TP-Monitor-Aufrufe, kommuniziert im Rahmen eines Cooperative Processing mit anderen Programmen auf dem gleichen oder auf einem anderen System, nimmt gegebenenfalls die Dienste eines Standardservices wie Electronic Mail über die Programmschnittstellen in Anspruch, greift eventuell auf das Data Dictionary zu und hat eine ausgelagerte Präsentationskomponente auf dem Arbeitsplatz-System.

Die strategische Schnittstellenmenge SIA wurde entsprechend definiert. Dazu gehören die Programmiersprachen Cobol, Fortran und C als 3GL, Drive als 4GL, die Datenbank-Sprache SQL, die TP-Monitorschnittstelle KDCS (DIN-Norm, noch keine internationaler Standard) mit den entsprechenden Erweiterungen für verteilte Transaktionsverarbeitung, die Schnittstelle CPIC für die Programm-zu Programm-Kommunikation (in der Literatur als LU6.2 Schnittstelle bezeichnet), die Data-Dictionary-Schnittstelle IDDS (hier ist noch kein internationaler Standard definiert) und die Programmschnittstellen oder Ocis-Services. Für die Präsentation sind OSF/Motif (Sinix-Workstation), Windows (MS-DOS) und Presentation Manager (PM) enthalten.

Diese Schnittstellen - zum Teil befinden sie sich noch in der Entwicklung - werden einheitlich auf BS2000 und Sinix und zum Teil auf OS/2 beziehungsweise MS-DOS angeboten.

Vergleicht man diese Schnittstellenmenge mit der von Systemen, über deren Offenheit Einigkeit herrscht, so stellt man fest, daß es viele Gemeinsamkeiten gibt. So sind Cobol, Fortran, C, SQL und CPIC X/Open- und SAA-Standards. Für andere Interfaces gibt es weder eine internationale Norm noch X/Open-Definitionen.

Faßt man die Diskussion zusammen, so läßt sich sagen, daß sich BS2000 in den letzten Jahren stark in Richtung auf ein offenes System entwickelt hat, das Interoperabilität in heterogener Systemumgebung und in einem beträchtlichen Ausmaß auch Portabilität von Anwendungen ermöglicht.