Rechenzentren gelten bei vielen Anwendern als Mainframe-lastige Dinosaurier. Matthias Seeger* ueberlegt jedoch, wie die Vorzuege von Client-Server-Architekturen unter RZ-Bedingungen genutzt werden koennen.

Wir schreiben 1994. Der Markt ist gepraegt von Schlagworten wie Imaging, Objektorientierung, Broker-Technologie, Workflow- Management, Client-Server etc. Der Begriff "Rechenzentrum" taucht nur selten auf - und dann ausschliesslich im Zusammenhang mit Downsizing oder Outsourcing.

In welcher Form und mit welchen Funktionen koennte das Rechenzentrum (RZ) dennoch weiterbestehen? Oder werden die neuen Plattformen, auf denen die Business-Applikationen laufen, so leicht bedienbar, der Endanwender so selbstaendig, dass die Institution RZ ueberfluessig wird? Oder ist Systems-Management eine solche Selbstverstaendlichkeit, dass schon aus diesem Grund niemand darueber redet? Die Beantwortung derartiger Fragen wird durch folgende Aspekte erschwert:

- Rechenzentren sind in betriebliche Organisationen eingebettet. Das "normierte RZ" ist daher eine Illusion.

- In der gesamten DV gilt eine "Halbwertszeit" von zirka drei Jahren, das heisst die Haelfte aller Produkte, Aussagen, Wahrheiten verliert nach dieser Zeit ihre Gueltigkeit.

Verteilte Verarbeitung praegt das RZ 2000

Im folgenden sollen daher einige laengerfristige Trends in der DV- Welt skizziert werden, die ueber kurzfristige Modeerscheinungen hinauszugehen scheinen. Sie charakterisieren das Umfeld, fuer das heute betriebswirtschaftliche Anwendungen entwickelt und eingesetzt werden und in dem das "RZ 2000" seinen Platz finden muss.

Diese Tendenzen zeichnen sich zur Zeit ab:

- heterogene, dreistufige Systemlandschaften, bestehend aus Host, Abteilungsrechner und Workstations (vgl. Abbildung 1);

- inkompatible Betriebssysteme (Mainframe, Unix, DOS);

- verteilte Daten; lokal verfuegbar; synchrone und asynchrone Konsolidierung;

- verteilte kooperative Verarbeitung;

- Trennung von Benutzer-Schnittstellen (GUI), Programmfunktionalitaet und Daten;

- Aufkommen von Standards

(SQL, ODBC, DCE/DME, CORBA,) und De-facto-Standards (Windows, OLE);

- Orientierung von DV-Funktionen auf den Endanwender (RZ als Dienstleister) sowie

- lokale, teilautonome betriebliche Organisationseinheiten.

Zusammengefasst: Ehemals monolithische Strukturen werden hard- und softwaretechnisch aufgebrochen; der Anwender steht mehr und mehr im Mittelpunkt, weniger die unterstuetzende Technik. Probleme hierbei sind die Integration der bestehenden Altanwendungen (Investitionsschutz) sowie die IS-strategische Konsolidierung der Einzelfunktionen (also keine DV-Inselloesungen).

Die Software-Architektur, die auf diesen Prinzipien aufbaut und sich immer weiter durchsetzt, traegt den Stempel "Client-Server". In dieser Verarbeitungsform geht die Initiative von den funktionsanfordernden Instanzen (den Clients) aus, Funktionsanbieter sind die Server (zum Beispiel Datenbanken, Drucker, Archivsysteme, Hintergrundautomaten).

Die Verbindung uebernehmen Komponenten der Middleware. Hierbei wird nicht nur die Connectivity hergestellt, sondern es werden weitergehende Services fuer die Client-Server-Kommunikation nutzbar gemacht.

Wie bei jedem Dienstleister, der mit seinen Anwendern Service- Level-Agreements trifft, so basiert auch Client-Server- Verarbeitung auf der Definition und Beachtung festgelegter Servicepunkte. Erst hierdurch wird es zum Beispiel moeglich, die Anzahl der Clients und Server, die gleiche Leistungen fordern beziehungsweise gleiche Leistungen anbieten, beliebig zu variieren oder aber ueber beliebige Netzwerktopologien zu verteilen. Abbildung 2 fasst Gruende fuer den Erfolg der Client-Server- Verarbeitung zusammen:

- die Modularisierung von Funktionen und die dadurch erreichte Flexibilitaet fuer deren geografische Verteilung (Daten, Netz, Anwendung, Praesentationsschicht);

- die DV-Infrastruktur passt sich der betrieblichen Organisation an, nicht umgekehrt;

- der Endanwender fordert mehr Services und

- durch die Austauschbarkeit der Komponenten koennen preisliche Vorteile genutzt werden.

Dabei ist Client-Server-Verarbeitung keine Fiktion, sie funktioniert bereits in der Entwicklung moderner Business- Applikationen. Folgende Bausteine sind identifizierbar:

- Mit 4GL-Systemen lassen sich portable, funktional maechtige Anwendungen mit netzwerkweitem Zugriff auf beliebigen Datenhaltungssystemen realisieren. Die Trennung von Datenzugriff, Programmfunktionalitaet und Praesentation ist Realitaet.

- Endanwendergerechte Praesentationsschichten sorgen fuer Akzeptanz und integrieren unterschiedlichste Anwendungssysteme.

- Datenbank-Server arbeiten als Repositories und bieten Daten netzwerkweit an. Sie sorgen fuer eine performante, konsistente Datenhaltung mit normiertem Zugriff.

- Offene SW-Architekturen erlauben die Interoperabilitaet zwischen Produkten auch verschiedener Hersteller. Sie ermoeglichen ausserdem die Integration bestehender Altanwendungen und garantieren die Skalierbarkeit der Verarbeitungskomponenten.

Aufgaben des System-Managements

Versteht man unter System-Management die Zusammenfassung aller produktionserhaltenden Massnahmen, so wird in einem solchen Szenario sowohl ihr Umfang als auch ihre Bedeutung fuer ein Unternehmen zunehmen, denn:

- Die Anzahl und die Heterogenitaet der funktionalen Komponenten steigt.

- Neue Aufgaben zur Produktionssicherung in heterogenen Netzwerken kommen hinzu (zum Beispiel Softwareverteilung, Lizenzfragen, Sicherheitsaspekte).

- Client-Server funktioniert nicht nur online und synchron.

- Die Systempflege durch den Endanwender ist in der Summe zu teuer. Das bestaetigt auch die Untersuchung von der Gartner Group aus 12/93.

Was nuetzt es einem Unternehmen, hochwertige Applikationen schnell, komfortabel, preisguenstig und unter Einbeziehung der spaeteren Anwender erstellt zu haben, wenn sich deren produktiver Einsatz nicht adaequat sichern laesst. Erst hier entsteht doch der Mehrwert. Und hier ergibt sich auch die grosse Chance, am Wissen und an der Erfahrung traditioneller Rechenzentren zu partizipieren, wenn es um die Sicherung des produktiven Einsatzes von Anwendungen geht. Denn diese Forderung bleibt auch in den neuen Hard- und Softwarelandschaften bestehen.

Abstrahiert man einmal von den einzelnen Aufgaben auf deren gemeinsame Funktionalitaet, lassen sich folgende Forderungen an das kuenftige System-Management stellen:

1. Der Zugriff auf alle Plattformen auf denen Client-Server- Verarbeitung stattfindet muss gegeben sein. Dies umfasst sowohl das passive Lesen von Systemdaten und -ereignissen als auch das aktive Schreiben/Steuern.

2. Einzelfunktionen muessen zu einem "Single System Image" integriert werden (keine umstaendlichen Logon/Logoff-Prozeduren, einheitliche Syntax, hoher Bedienkomfort).

3. Hard- und Softwarekomponenten muessen beruecksichtigt werden, da der Benutzer nur am Funktionieren seiner Anwendung interessiert ist.

4. Neue Anforderungen und Funktionen muessen sich evolutionaer integrieren lassen, ohne dass die bisherige Verarbeitung grundlegend geaendert werden muesste.

5. Die DV-Produktion muss zu jedem Zeitpunkt gesichert sein.

Wenn Client-Server das zukuenftige Szenario und System-Management zur Produktionssicherung notwendig ist, was liegt dann naeher, als System-Managament mit den Mitteln und strukturellen Prinzipien der Client-Server-Verarbeitung durchzufuehren? Das heisst also:

- gleiche Bausteine zu verwenden;

- Funktionen zu modularisieren beziehungsweise zu kapseln und sie netzwerkweit ueber definierte Schnittstellen aufrufbar zu machen;

- offene Architekturen zur Integration und fuer kuenftige Erweiterungen zu verwenden.

Welche Bausteine ergeben sich hieraus fuer ein System-Management?

1. Betriebssystem-Server machen die Funktionen und Daten von Betriebssystemen und deren Subsystemen auf einer logischen Ebene verfuegbar. Sie funktionieren analog zu den bewaehrten Datenbankservern. Fuer den Client-Zugriff garantieren sie stabile Servicepunkte.

2. Monitore greifen lesend und steuernd auf diese Server zu. Sie sind Hintergrundautomaten, arbeiten regelbasiert, teilautonom und synchronisieren sich periodisch. Hierdurch werden geplante Aufgaben (zum Beispiel Scheduling, SW-Verteilung, Pflegemassnahmen) und ungeplante Aktivitaeten etwa Operating, Alert-Management) realisiert.

3. Die Verarbeitungsregeln werden ebenso wie die Benutzer-Profile oder Log- und Accounting-Daten der Verarbeitung in Repositories abgelegt.

4. Netzwerkkomponenten stellen die Verbindung zwischen den Servern (Datenbanken, Betriebssystem-Server, andere) und den Klienten her (Monitore, Anwendungsprogramme der Endanwender). Sie bauen auf gaengigen Netzwerkprotokollen auf, bedienen sich aber ansonsten der definierten Service-Punkte der Client-Server-Verarbeitung.

5. Integrierende Oberflaechen ermoeglichen den Single-point of access zu allen System-Management-Komponenten (Administratoren) beziehungsweise Business- Applikationen (Endanwender).

6. Offene Architekturen ermoeglichen die Integration von Altanwendungen ebenso wie die Erweiterbarkeit hinsichtlich zukuenftiger Forderungen (Hardware, Software, organisatorische Umgestaltung). Sie beruecksichtigt Standards, wo immer diese sinnvoll sind. Sie ermoeglicht ebenso den steuernden Zugriff der Fachabteilungen auf die sie betreffende Hintergrundverarbeitung (Beispiele: Parametereingabe fuer die naechtliche Batch- Verarbeitung; Steuerung von Druckdaten).

Broker fungieren als vermittelnde Instanz

Was fehlt in diesem Szenario noch? Stellt man sich eine grosse Anzahl von Clients vor, die mit einer Vielzahl von Servern kommunizieren muss, so ist es einleuchtend, dass es durchaus eine vermittelnde Instanz geben muss: den Broker. Er garantiert, dass jeder Client auch den Server findet, der seiner Anforderung entspricht. Dabei lassen sich verschiedene Arten der Kommunikation aufbauen: konversationell/

non-konversationell, 1:1/n:1, synchron/asynchron, RPC etc .

Neben dem reinen Verbindungsaufbau werden allgemeine Services fuer das Client-Server-Processing zur Verfuegung gestellt (vgl. Abbildung 3):

- Translation-Services ueberbruekken zum Beispiel ASCII/EBCDIC Grenzen.

- Directory-Services erlauben den Verbindungsaufbau unabhaengig von der physischen Lokation der Teilnehmer.

- Security-Services erlauben einen zentralen, plattformunabhaengigen Zugriffsschutz.

- Dispatching-Services gestatten die optimale Ausnutzung vorhandener Ressourcen und ermoeglichen eine Prioritaetssteuerung bei der Verarbeitung der Request.

- Operational Services ermoeglichen den steuernden Eingriff in das System.

- Logging-and-Accounting-Services gestatten eine zentrale, plattformunabhaengige Protokollierung der Aktivitaeten und des Ressourcenverbrauchs auf der Basis logischer Einheiten.

Halten sich dann Clients und Server an die definierten Servicepunkte und steht der Broker als vermittelnde Instanz zur Verfuegung, so lassen sich alle gaengigen und auch zukuenftigen plattformspezifischen Verarbeitungen uebergreifend integrieren. Ein in C++ geschriebenes Programm, das unter Windows NT ablaeuft und eine GUI-Oberflaeche bedient, kann so zum Beispiel auf Daten und Funktionen eines IMS/DC-Servers zugreifen oder aber die Systembelastung eines BS2000-Systems visualisieren. Und da es keinen Unterschied macht, ob ein Programm einen Endanwender am Terminal oder PC bedient oder aber im Hintergrund als Monitor laeuft, lassen sich die Funktionen des System-Managements nach den gleichen Prinzipien in einer Client-Server-Umgebung realisieren. Einzige Voraussetzung ist die Einhaltung und Nutzung der definierten Servicepunkte.

Als erstes Beispiel hierzu soll die Verarbeitung betrachtet werden, die momentan unter den Schlagworten Workflow- oder Groupware-Processing in aller Munde ist. Obwohl noch keine endgueltige Definition vorliegt, lassen sich folgende Komponenten einer solchen Verarbeitung identifizieren:

- eine moeglichst Endanwender-gerechte Benutzeroberflaeche, in der betriebsrelevante Vorgaenge abgebildet sind und der Begriff Formular eine zentrale Rolle spielt.

- einen Hintergrundprozess, der aufgrund einer definierten Verarbeitungstopologie weiss, welche Schritte nach Beendigung jedes Prozessschritts durchzufuehren sind (zum Beispiel Programm ausfuehren, Meldung verschicken, Netzwerk starten). Ein solcher Workflow-Manager ist die konsequente Weiterentwicklung dessen, was heute als Scheduler bekannt ist. Aber: Er ist in der Lage, mit Endanwenderapplikationen zu kommunizieren, egal, wo diese in heterogenen Netzwerken gerade ablaufen, und gleichgueltig, welche Oberflaechenpraesentation sie benutzen.

- Middleware-Komponenten, die die Verbindung zwischen den Clients und dem Hintergrund-Server ermoeglichen.

Das zweite Beispiel kann mit dem Begriff "logisches Output- Management" beschrieben werden. Die Notwendigkeit hierfuer wird unmittelbar einleuchtend, wenn man die rasante Zunahme von dezentralen Druckern in einem Unternehmen betrachtet, die nahe beim Endanwender stehen und deren Funktionen ausgenutzt werden sollen (beispielsweise Laserdrucker, Formularausgabe). Die Druckdaten kommen hierbei eben nicht nur aus lokalen Verarbeitungsprogrammen (Windows, Excel, Dbase), sondern auch aus Tausenden von zentralen Host-basierten Applikationen. Notwendig sind hier also Funktionen wie Endanwender-gerechte, Mandanten- faehige Darstellung der Druckdaten, dezentrales Drucken oder aber einheitliches Archivieren.

Fazit: System-Management und Endanwenderapplikationen lassen sich nach den gleichen Bauprinzipien realisieren, ja sogar eine Kommunikation zwischen den technischen Anwendungen der Produktionssicherung und den Business-Applikationen eines Unternehmens ist moeglich. Endanwender werden so zu Clients, das Rechzentrum zu einem Serviceanbieter.

* Matthias Seeger ist Produkt-Manager bei der Software AG in Darmstadt.