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.

18.10.1991 - 

Serie: Downsizing, Client-ServerTeil 3

Downsizing als Mainframe-Ersatz durch PCs ist nur ein Modetrend

Downsizing als neues Modewort aus den USA zielt auf einen Effekt dezentraler Datenverarbeitung: Die zentrale Hardware wird relativ zur dezentralen kleiner, aber nicht unbedingt absolut. Insbesondere wird so eine Reorganisation der firmeninternen Datenverarbeitung bezeichnet, bei der sich die Größe der Zentrale reduziert und mehr Aufgaben den peripheren Rechnern, also den PCs, übertragen werden. Verkürzt und vergröbert ausgedrückt: Weg mit den zentralen Großrechnern, alles wird über PC-Netzwerke gelöst.

Dies ist einerseits für Siemens-Nixdorf nichts Neues, weil seit vielen Jahren die passenden Produkte existieren und diese auch zum Einsatz kommen. Nur wurden dafür weniger PCs, sondern beispielsweise der BNC der "Banking Network Computer", eingesetzt, der unter anderem eine viel größere Auswahl an Kommunikationsprotokollen bietet als PCs und zudem noch mehr Arbeitsplätze und eine große Vielfalt von Peripheriegeräten bedienen kann. Ähnliches gilt für unsere Netzwerk-Computer 8860 und 8862.

Wenn wir Downsizing nicht bedingungslos propagieren, so liegt das nicht nur daran, daß es unsere Kunden längst durchführen. Vielmehr sind wir gemeinsam der Überzeugung, daß sich ein wesentlicher Teil der in Europa zu lösenden IT-Aufgaben nach dem jetzigen Stand der Technik gar nicht ökonomisch auf einem reinen PC-Netzwerk realisieren läßt. Abgesehen davon kommen selbst kleinere Unternehmen längst nicht mehr mit einem LAN- Netzwerk aus, sondern wollen ihre Filialen auch grenzüberschreitend verknüpfen und über eine leistungsstarke Zentrale koordinieren.

Als ein Beispiel für die Notwendigkeit zentraler DV-Systeme sei die Platzreservierung für Flugreisen genannt. Einige wenige zentrale Rechenzentren verwalten die Plätze, so daß der Kunde schnell und zuverlässig bedient wird. Ein PC-Netzwerk mit Remote Bridges kann auch den zentralen Server befragen - nur ist dies sinnvolles Downsizing, wenn es insgesamt teurer wird? Verzichtet man aber auf den zentralen Rechner, so steigt der Kommunikationsbedarf der PCs untereinander, weil die verstreut gespeicherten Daten, die die Ressource Sitzplätze darstellen, ausgetauscht werden müssen. Downsizing wird begrenzt durch die geringe Transaktionsleistung eines PCs; dabei ist die reine Rechenleistung MIPS uninteressant.

Anwendungen eher zentral oder dezentral?

Ein noch gravierenderes Problem ergibt sich aus dem wesentlich höheren Aufwand, um Sicherheit und Verfügbarkeit der Verarbeitungsknoten in Zusammenhang mit einem PC-Netzwerk auch organisatorisch zu garantieren. Selbst wenn die Ausfallsicherheit der Zentralsysteme nur in der gleichen Größenordnung läge wie die des einzelnen PCs, wird eine Lösung mit 100 PCs, deren Gesamtverfügbarkeit die Verfügbarkeit aller PCs voraussetzt ungefähr um den Faktor 100 weniger zuverlässig sein als das Zentralsystem.

Die Großrechner realisieren jedoch durch Redundanzmaßnahmen (Spiegelplatten, Multiprozessoren etc.) eine ungleich höhere Verfügbarkeit als ein einzelner PC. Auch wenn dies Beispiel künstlich erscheint, weist es auf wichtige Randbedingungen hin.

Von der Logik her verlangen die meisten kommerziellen Anwendungen der Datenverarbeitung eine zentrale Koordination von Betriebsmitteln im allgemeinen Sinne. Also werden noch lange die wesentlichen das heißt nicht einfach reproduzierbaren Daten auf einem Zentralrechner gehalten werden. Heute lautet die Frage: Paßt die Anwendung besser auf eine zentrale oder dezentrale Lösung?

Gesamtlösungen für optimale Kostenstruktur

Früher wurde, weil es wirtschaftlich war, Dezentralität durch Time-Sharing simuliert. Durch die technische Entwicklung entfiel dieser Zwang, also hat man Textverarbeitungs- und Bürosystem nicht mehr als Zentrallösungen konzipiert. Insbesondere sind die Office-Lösungen konsequent dezentralisiert. Aber warum soll eine Aufgabe, die zentralen Charakter hat, dezentralisiert werden?

Viel größere Bedeutung als Kostenersparnissen im Hardware-Etat kommt Gesamtlösungen zu, die zu optimalen Kostenstrukturen führen. Hierbei stelIen die Entwicklung der Software und Administration des realisierten Systems durch den Kunden eher die größeren Anteile.

Daß immer mehr Rechner im Verbund arbeiten - und natürlich auch die Großrechner untereinander - ist unbestritten. Es entsteht ein Netzwerk aus Rechnern unterschiedlicher Stärke; mit Verarbeitungsrechnern hoher Transaktionsleistung und Präsentationsrechnern hoher Interaktionsleistung, die zusätzlich lokale Verarbeitungsleistung bieten.

Fazit: Downsizing aufgefaßt als Ersatz des Großrechners durch PC-Netzwerke, ist eine Modeerscheinung. Sinn macht es allerdings, der Struktur von Aufgaben entsprechend vorzugehen, die logischen Zentralen zu identifizieren und den Rest verteilt zu realisieren.

Bei der Realisierung von Downsizing wird ein Konzept zugrunde gelegt, daß die Aufgabe in zusammengehörige Teile strukturiert. Dieses Konzept heißt Client-Server-Architektur. Die systemanalytische Aufgabe besteht dabei darin, Services zu definieren, also Funktionen zusammenzufassen, die Gemeinsamkeiten haben. Diese Gemeinsamkeiten können logischer Art sein ("alles was mit Drucken zusammenhängt") oder sich auf gemeinsame Betriebsmittel ("Zugang zum öffentlichen X.25 Netzwerk") beziehen.

Client-Server (C/S) ist für Netzwerke das, was strukturierte Programmierung für die Programmerstellung ist: eine Art und Weise, nach der eine Aufgabe zerlegt und strukturiert wird. So wie nach anfänglicher Begeisterung sich strukturierte Programmierung als Stand der

Technik, aber nicht als Allheilmittel etabliert hat, so wird sich der Client-Server-Gedanke

durchsetzen, weil er die so realisierten Anwendungen durch die klare Strukturierung besser

handhabbar macht.

Als Server sind nicht nur Großrechner einsetzbar

In der Systemanalyse für eine Client-Server-Lösung werden Aufträge definiert. Zusammen gehörige Aufträge wiederum bestimmen die Services, die Transaktionen realisieren können oder Information bereitstellen sowie Daten weiterreichen. Erst

nach der Festlegung der Services entscheidet ein Mengengerüst, welche Verarbeitungs- und Transaktionsleistung der Server haben muß. Zusammen mit weiteren Gesichtspunkten wie Sicherheit und Verfügbarkeit kann dann der Typ des Servers definiert werden. Keineswegs sind als Server nur Großrechner einsetzbar.

Durch die Definition von Services wird zudem die Software Investition des Anwenders geschützt: Der Server kann später ausgelagert oder durch einen anderen ersetzt werden, zum Beispiel bei Verwendung der Siemens-Nixdorf-Datenbank Serviceschnittstelle DBA.

Wichtig ist hierbei, daß Client und Server Rollen im Netzwerk beschreiben. Daher wird häufig eine Maschine als Server oder Client bezeichnet, wenn dies ihre überwiegende Aufgabe im Netzwerk ist.

Aber auch Transaktionsrechner im Netz, die primär Serverfunktion übernehmen, können als Client die Dienste anderer Server beanspruchen. Gute Beispiele sind Security-Server oder ein X.500-Directory, die gegebenenfalls auch auf kleinen spezialisierten PCs realisiert werden.

Da die Client-Server-Architektur eine Strukturierung oberhalb der Ebene von Programmkommunikation (Program-toprogram Communication, PPC) darstellt, ergeben sich zwei Nutzeneffekte im Sinne von Offenheit und Austauschbarkeit: Erstens kann das Verfahren der Programmkommunikation durch ein anderes ersetzt beziehungsweise durch Gateways umgesetzt werden. Beispielsweise läßt sich sowohl Remote procedure call (RPC) in Unix-Netzen als auch Advanced program-toprogram communication (APPC) in SNA-Netzen zur Realisierung einsetzen. Dabei ist allerdings RPC besser an die Client-Server-Architektur angepaßt. Zweitens ist bei standardisierter PPC ein Zugang zu und von Rechnern verschiedener Systeme möglich.

Client-server-Struktur als Grundlage von Downsizing

Client-Server Beziehungen sind nicht auf LANs beschränkt. Im mittlerweile weltweit benutzten Internet sind viele Dienste durch Client-Server-Lösungen realisiert worden, als alle anderen noch Stern-Maschen-Netze geknüpft haben und eine Strukturierung von Program-to-program-Communication, wie sie die Client-Server-Architektur einführt, nicht als vorrangig ansahen.

Fazit: Client-Server ist die Netzarchitektur, die eine strukturierte Verteilung der Aufgaben im Netz nahelegt. Sie ist damit Grundlage von wirksamem Downsizing.

In der gesamten Diskussion spielt direkt und indirekt die Frage nach offenen Systemen eine Rolle. Offene Systeme werden sehr unterschiedlich definiert und diskutiert:

- Kompatibilität auf der Ebene der Software-Schnittstellen; die Anwendungen sind nach Rekompilierung auf unterschiedlichen Maschinen ablauffähig (Source-Kompatibilität),

- Austauschbarkeit auf Hardware- und Software-Ebene (Binärkompatibilität),

- Multivendor-Fähigkeit, insbesondere als Mix: heterogen ausgestattete Hardware- und Softwarebasis,

- offengelegte Schnittstellen, die damit auch eine Nutzung erlauben, die vom Lieferanten nicht vorgesehen war,

- quasi-öffentliches Verfahren der Schnittstellenfestlegung,

- konsequente Anwendung und Befolgung von Standards, auch De-facto-Standards,

Man könnte auch sagen, ein System ist dann offen, wenn die Portierung einer Anwendung signifikant weniger Aufwand kostet als ihre Neuprogrammierung. Es wird aus dieser Liste aber klar, daß die Erwartungen an offene Systeme heterogen sind. Auch wird erkennbar, daß Offenheit kein binäres Attribut ist. Je mehr Elemente aus obiger Liste enthalten sind, desto mehr hat das System den Charakter eines offenen Systems.

Bei eingehender Analyse werden dann auch drei Formen von Offenheit sichtbar.

- Netzkompatibilität (offene Kommunikation): Hier steht nicht der einzelne Rechner und sein Betriebssystem, sondern die Koppelung der Rechner untereinander im Vordergrund. Gefordert sind die Implementation der weit verbreiteten Protokolle wie OSI, SNA und TCP/ IP. Hinzu kommen LAN-Manager für PC-Anschluß und gegebenenfalls weitere Protokolle die De- facto-Standards darstellen.

- Source-Kompatibilität: Obwohl sich die Betrachtung hier auf den einzelnen Rechner konzentriert, für den die Anwendung übersetzt werden muß liegt eine logische Koppelung zur Netzwerk-Kompatibilität vor. Indem die Schnittstellen gleich sind, können auch Netzwerkanwendungen erfolgreich übersetzt werden und miteinander kommunizieren, so daß mit Source-Kompatibilität in der Regel auch Netzkompatibilität erreicht wird.

- Binär-Kompatibilität: Dies ist die strengste Form der Übertragbarkeit von Software auf verschiedene Maschinen, bei denen keine Bearbeitung des Objekts, etwa eine Neuübersetzung, stattfinden muß. Damit sind wie zuvor auch Source- und Netzkompatibilität vorbereitet.

Offenheit ist kein einfaches binäres Attribut

Wichtigstes Element für die Offenheit ist die konsequente und durchgängige Verwendung von langfristig stabilen Schnitt stellen. Siemens-Nixdorf hat daher die System Interfaces for Applications (SIA) definiert, die eine Schnittstellenfestlegung über Betriebssyteme und Rechnerfamilien der SNI bedeuten. Hierin wird überwiegend auf existierende Standards verwiesen, wobei ausgeführt wird, welche Standards gelten und mit welchen Optionen (Functional standards). Langfristig stabil sind natürlich insbesondere Schnittstellen, die die Akzeptanz von Standardisierungs-Körperschaften gefunden haben, seien dies die internationalen Organisationen wie ISO oder die nationalen Äquivalente DIN und ANSI. Selbstverständlich zählen hierzu auch die speziell auf IT-Themen ausgerichteten neueren Organisationen wie X/Open.

Da die SIA für unsere Sinix-Systeme gilt, ergibt sich, daß die Mehrzahl der referierten Standards aus der Unix-Welt kommen. Da die SIA für unterschiedliche SNI-Systeme gilt, sind auch im BS2000 definierte Schnittstellen der offenen Welt zu finden.

Durch die Kompatibilität der Schnittstellen wird damit aus unserem Betriebssystem BS2000 ein offenes: Es ist in ein Netzwerk wie ein offenes System integrierbar. Es bietet darüber hinaus Transaktionsleistungen an, die mit den am Markt erhältlichen Unix-Systemen nicht erreichbar sind.

Die Öffnung von BS2000 erfolgt aber nicht nur im Netzbereich, wo sie mit SNA- und TCP/IP-Zugang schon länger verfügbar ist. Der Universelle Transaktions-Monitor (UTM) ist mit kompatiblen Schnittstellen auf beiden Systemen verfügbar, so daß auch die Applikationen softwarekompatibel sind. Ziel ist Source-Komptibilität, zum Beispiel nach dem in die SIA zum großen Teil aufgenommenen X/Open Portability Guide.

Auch wenn der Trend zu offenen Systemen und der damit verbundenen Vereinheitlichung und Standardisierung richtig ist, so stellt er dennoch kein Allheilmittel dar.

Es sei an den Ausspruch erinnert, daß Kompatibilität der Feind des Fortschritts ist. Alle neuen, fortgeschrittenen und spezialisierten Lösungen sind im allgemeinen zunächst nicht offen, bis sie sich in der Praxis bewährt haben.

Daher sieht Siemens-Nixdorf auch weiterhin einen Sinn darin, über die Standards hinaus spezielle Systeme und Zusätze anzubieten, die ökonomisch sinnvolle Funktionen ermöglichen. Die große Bedeutung der Herstellervereinigung OSF (Open Software Foundation), in der wir mitarbeiten, liegt nun gerade darin, die von den Mitgliedern erarbeiteten speziellen Lösungen in die offene Welt zu überführen, in der sie dann allen verfügbar sind.

Fazit: Offenheit von Systemen ist kein einfaches binäres Attribut; Offenheit ist zu messen an dem gewünschten Grad, in den herstellereigene Systeme unterstützt werden.