Client-Server-Computing

Geschwurbel von Daniel Schwamm (25.10.1994 bis 26.10.1994)

Gesammeltes zum Thema

Informationsmanagement (IM) im Wandel von zentral nach dezentral. Heterogene Rechnerwelten werden integriert (Rightsizing), wozu eine geeignete SW-Architektur nötig ist: Client/Server-Techniken (C/S) können die Leistung von mehreren Rechnern in das Rechnernetz (RN) erbringen, wodurch alte Investitionen weiter nutzbar und vorhandene Ressourcen optimal verteilbar sind.


C/S: Logisches Konzept für SW-Architekturen zur verteilten IV in RN. Jede vollständige SW besteht bei C/S aus mindestens einem Client und einem Server (Gegensatz zu monolithischen Programm). Die Auftragsbeziehung geht immer vom Client aus, aber Server kann gegenüber anderen Programmen ebenfalls zum Client werden. Wichtig für die Interoperabilität: Gemeinsames Protokoll.

  • C/S!=offene Systeme, denn C/S unabhängig von der Netzarchitektur.
  • C/S!=verteilte Systeme, denn VS sind eine Obermenge von C/S.
  • C/S!=HW-Konfiguration, denn C/S ist eine SW-Architektur.
  • C/S!=denzentrale IV, sondern kooperative IV.

Vertikale Verteilung von C/S der ersten Generation (Sinn: Jeder Rechner erledigt nur sein Spezialgebiet):

  • Verteilte Präsentation: X-Server übernimmt Bilddarstellung.
  • Verteilte Verarbeitung: "Number Cruncher" erledigt Rechenaufgaben, RPCs.
  • Verteiltes Datenhandling: DB-Maschine erledigt DV.

Über SQL-Server kann auf Ingres-, Sybase-, Oracle- und DB2-Datenbanken in gleicher Weise zugegriffen werden (Zugriffstransparenz). SQL-Statements über das Netz versenden ist aber nicht sehr effektiv. Besser: Client stösst Server nur zur Arbeit an => der produziert die nötigen SQL-Statements selbst, findet lokal die Daten und sendet die Antwort an den Client zurück. Auf diese Weise lässt sich Online Transaction Processing realisieren, welches nicht auf das eigene LANs beschränkt bleiben müsste.


C/S kommunizieren über IPC oder Netzprotokolle, die aber intransparent sind. Der RPC-Mechanismus erlaubt die transparente Nutzung entfernter Funktionsserver. Mittels Transaktionsmonitoren wie Tuxedo oder Transaktionsdienste wie OSI-TP können Mainframe-Monitore ersetzt werden. Alternativ zu RPCs werden auch objektorientierte, verteilte Systeme realisiert.


Mögliche Interaktionsmuster: Pipelines, Peer-to-Peer-Interaktion, C/S-Interaktion, Heartbeat-Interaktion, Probe/Echo-Interaktion, Token-Passing-Interaktion.


Kommunikationsmodellarten: Mitteilungsorientiert (simplex), auftragsorientiert (duplex, blockierend) oder transaktionsorientiert (duplex, blockierend, zuverlässig).


Verteilte Systeme können mittels Distributed Computing Environment der Open System Foundation realisiert werden, das aber nicht objektorientiert ist. Die OSF ist eine non-profit Hersteller-Vereinigung (HP, IBM, DEC). DCE ist unter AIX, UNIX und OSF/1 verfügbar, soll für MVS (Multiple Virtual Storage), OS/400 und MSDOS realisiert werden. DCE bietet:

  • RPC: Hier immer blockierend (OSI bietet auch nicht-blockierende RPC an).
  • Threads: Parallelisierung innerhalb eines Prozesses.
  • Cell/Global Directory-/Time-/Security-Services
  • Distributed File System: Transparente Verteilung von Dateien.
  • Diskless Support: Integration von Diskless Workstations in die DCE.

DCE: Server-Schnittstellen werden mit der IDL (Interface Definition Language) beschrieben, die sehr C-ähnlich ist (abgesehen von den Zusätzen "in" und "out" für Input-Parameter oder Output-Parameter). Der IDL-Compiler erzeugt daraus eine C-Header-Datei, die der Client einbinden muss, um die Server-Fkt. aufrufen zu können. Ansonsten wird der Client genauso programmiert, als würde er keine RPCs benutzen. Der IDL-Compiler erzeugt ausserdem einen Client- und einen Server-Stub, die über die Netzwerk-Komponente den RPC ausführen. Meist wird noch ein Binder zwischengeschaltet. Initialisiert sich ein Server-Prozess, dann sendet er den Export seines Funktionsangebot an den Binder (zusammen mit einer Versionsnummer und seiner Adresse). Ein Client, der zum ersten Mal einen RPC absetzt, kontaktiert ebenfalls den Binder, um seine Funktionswünsche zu importieren. Der Binder erkennt, ob ein passender Server ex. und sendet dessen Adresse zurück.


Typische Probleme, die im Zusammenhang mit RPCs auftreten, sind: C und S verstehen sich nicht; C und S benutzen verschiedene Adressräume, sind daher auf Kommunikation angewiesen; C und S können abstürzen; C und S können nicht beliebige Argumente austauschen; globale Variablen wie "errno" nicht einsetzbar; variable Parameterzahlen wie bei "printf" unmöglich zu realisieren. Einige Hauptprobleme und ihre Lösungen seien im Folgenden genannt:

Client findet Server nicht:
  Grund  : Server nicht aktiv, Client-Stub veraltet, Binder defekt
  Loesung: Fehlerrueckmeldung und -Handling (ist aber intransparent).

Server empfaengt nichts:
  Grund  :  Nachricht ging unterwegs verloren.
  Loesung:  Timeout-Technik (Zeit allerdings schwer berechenbar).

Server sendet nichts zurueck:
  Grund   : Sever vor/waehrend/nach Reply abgestuerzt.
  Loesung: Timeout+Sequenznummern gegen nicht-idempotente Wiederholungen.
           
           Die Wiederholungsstrategie hängt ab von der Semantik:
           -> Hoechstens/Mindestens/Genau einmal-Empfangs-Garantie.
                 V.a. bei zustandsbehafteten Servern problematisch!

Client empfaengt nichts:
  Grund  : Client abgestuerzt, neu hochgefahren, neue Portnummern.
  Loesung: Orphan-Behandlung
           - Ausrottung: Jeder RPC wird in Protokollliste eingetragen.
           - Reinkarnation: Neue Epoche starten, alle RPCs abbrechen.
           - sanfte R.: Neue Epoche, nur Orphan-RPCs abbrechen.
           Wichtig: Gekillt RPCs verhindern u.a. Entblockierungen von Dateien!

Call-by-Copy/Restore: Ähnlich wie bei einem Call-by-Value wird hier ein komplette Struktur (und nicht nur ein Pointer) an eine Funktion übergeben, die die Struktur kann aber verändern werden (Gegensatz zum Call-by-Value). Um C-typische Call-by-References über RPCs zu ermöglichen, kopieren die Stubs die gesamte Pointer-Struktur und übergeben sie als Call-by-Copy/Restore (funktioniert aber nicht bei komplexeren Strukturen).


Während die Clients über RPC völlige Transparenz bezüglich der Funktionsverteilung realisieren, sind die Stubs selbst eher intransparent: Sie benutzen explizit die Befehle "send()" mit anschliessendem "receive()", um zu blockieren, bis der Server die Antwort sendet. Da die Stubs jedoch automatisiert erstellt werden, bleibt die Transparenz für den User und Programmierer erhalten.


NFS ermöglicht ein verteiltes System unter UNIX, auch wenn das Mounten von Verzeichnissen in das eigene Verzeichnis nicht transparent ist; auch müssen Pfadnamen weiterhin angegeben werden. NFS erleichtert dadurch aber den Einsatz von RPCs. Transaktionen sind aber nicht möglich, da NFS zustandslose Server verwendet!


Über X11 kann eine verteilte Präsentation realisiert werden. Der X-Server, der i.d.R. auf dem Arbeitsrechner läuft, verwaltet Tastatur, Maus und Monitor. Zur Kommunikation wird das X-Protokoll verwendet, welches auf TCP/IP bzw. UDP/IP aufsitzt. Im Gegensatz zu den meisten RPC-Protokollen ist X nicht-blockierend.


NetWare von Novell: Das klassische Client/Server-System für PC-LANs (Local Area Network). Dieses System ist offen, d.h. es unterstützt Ethernet, Token-Ring, FDDI, MSDOS, OS/2, UNIX, Macintosh-OS und OS/400, bietet aber auch das eigene Netzwerk-Protokoll IPX/SPX an. Inzwischen ist NetWare über einen X.25-Anschluss auch WAN-tauglich (Wide Area Network), wobei es auf X.500 als Directory-Dienst zugreift.


Vor- und Nachteile von C/S:

  • Vorteile von C/S: Durch abgekoppelte und dann zentralisierte DV kann u.U. Integrität erhöht werden; Ressourcen können gemeinsam genutzt werden; Verfügbarkeit+; Integrationspotenzial+; Modularisierung erlaubt bessere Wartung; spezialisierte=dedizierte Rechner einsetzbar; Ausbaufähigkeit+; Parallelisierung von Anwendungen möglich; RPC-Möglichkeit und andere innovative Techniken; Imagepunkte; Weiterverwendung von Mainframes möglich; Client kann zwischen mehreren Servern wählen, d.h., Kompromisse bezüglich der Qualität sind möglich; flexibler; feinstufig anpassbarer.
  • Nachteile von C/S: Kommunikationsaufwand; Zeitintensität; Standards werden nicht befolgt (oder sind nur faule Kompromisse wie Token-Ring UND Ethernet UND ...); Gateways zur Integration schlucken Performance; CASE-Tools zur Client/Server-Applikationen-Entwicklung noch Mangelware; Server muss stabile Interfaces anbieten; Transparenz-Forderung nur schwer einhaltbar; Datensicherheit und Integrität schwierig; verlangt schnelle Netze und leistungsstarke Rechner; Kosten-Erfassungsmängel; Schulung/Betreuung+; Mainframe-Betreuer geben nur ungern Macht ab; nur 5% der Kosten durch HW+SW (nur 5% des Personals vertraut mit C/S); Gefahr zu Unterschätzung der Anstrengungen wie bei CIM-Salabim!

Vor- und Nachteile von Workstations:

  • Vorteile Workstations gegenüber Mainframes: Billiger (45.000 DM für Server, 1.000 DM für Clients); Leistung wächst schneller; Parallel Computing leichter realisierbar; kürzere Lebenszyklen und dadurch innovativer; benutzerfreundlicher durch bessere Präsentation (Multimedia, Hypermedia); papierloses Büro; bessere Antwortzeiten; Ergonomie; v.a. Qualitätsverbesserung (weniger Kosten-Verbesserung); da weniger Sicherung (wie z.B. über RACF) müssen Daten weniger redundant gehalten werden.
  • Nachteile von Workstations gegenüber Mainframes: Betreuungsaufwand+; Präsentation artet zur Spielerei aus; Nachteile von C/S-Computing; nicht alle Mainframe-Applikationen umsetzbar; Akzeptanz nicht von alleine gegeben; Schulungsaufwand; bieten keine leichte unternehmensweite Informationslandschaft; Speichermangel; Durchsatz viel kleiner als bei Mainframes, da Workstations die meiste Zeit auf User-Inputs warten.

SW-Zyklen in den Organisationen. meistens zu lange, daher haben sich C/S-Systeme noch nicht überall durchgesetzt. Da aber inzwischen viele Workstations in Organisationen vorhanden sind, dient C/S als Integrationsmodell zum Rightsizing.


Tendenz: 4 von 5 Firmen steigen auf C/S um, wobei Mainframes nicht ersetzt, sondern in Server umfunktioniert werden. 1/3 aller Unternehmen sind laut Online aktiv dabei, auf C/S-Applikationen umzusatteln. Bis zum Jahr 2000 sollen C/S-Applikationen den Markt sogar zu 90% dominieren! Multiple Virtual Storage (MVS) z.B. ist bereits C/S-freundlicher geworden und auch die ehemals proprietäre AS/400 wurde bereits zum offenen System. Zu beachten sind auch die zahllosen Kooperationen zwischen Firmen, um einheitliche, offene Produkte auf den Markt zu bringen. Migrationen werden zunehmen, wobei C/S die Basis bildet aufgrund seines Rightsizing-Potenzials.


C/S-Missbrauch: Häufig wird mit C/S nur plakativ geworben, obwohl die Applikationen weit entfernt ist von einem kooperativen C/S-Computing und Verteilung. Graphical User Interface (GUI): Die Oberfläche der alten Mainframe-Programme werden als verteilte Präsentation realisiert. Besser ist es aber, gänzlich neue Oberflächen zu erstellen, da moderne Workstations hier wesentlich weitreichendere Möglichkeiten haben als die alten Mainframes.


Sicherheitskonzept für interagierende Clients und Servers besonders aufwendig. Sie werden z.B. nötig, wenn ein Client über einen Server Geld überweisen lassen will. Der Client muss authentifiziert und autorisiert sein, damit er die Operation durchführen kann, und während der Ausführung müssen alle Störungen abgefangen werden. Mögliche Verfahren:

  • Authentifikation: Client weist sich gegenüber Server aus. Damit er das nicht jedes Mal machen muss, kann der Server von einem Authentifikationsserver den öffentlichen Schlüssel anfordern, um den Client zu prüfen.
  • Autorisierung: Client erhält über Zugriffsmatrizen (an Ressourcen gebunden) oder Capabilities (an Client gebunden) über Ressourcen-Server Zugriffsrechte auf Ressourcen.
  • Integrität: Daten müssen in nachvollziehbarer Weise modifiziert werden. Checkpoints, Roll-Back-Verfahren, 2-PC-Protokoll usw. sorgen für Konsistenz der Daten.
  • Policy-Mechanismen: Gegen mutwillige Störungsversuche.

Wer die DCE nutzt, erhält automatisch ein Sicherheitskonzept mit. Autorisierung, Authentifizierung und Verschlüsselung werden durch dedizierte Server erledigt.


Benutzung von Threads (häufig mit leichtgewichtigen Prozessen gleichgesetzt): Ein Client kann über das Thread-Konzept, wie es z.B. DCE anbietet, nicht-blockierende RPCs realisieren, die eigentlich von DCE nicht vorgesehen sind. Threads eines Prozesses können auf den gleichen Speicherbereich zugreifen, verfügen aber über eigene Stacks. Auf Server-Seite lassen sich über Threads parallele Server entwickeln, die keine Sohn-Kopie von sich erzeugen müssen.


RPCs werden auch von der OSI angeboten: In der Anwendungsschicht ex. verschiedene Application Service Entities, wie z.B. ROSE, RPC, über die blockierende und nicht-blockierende RPCs möglich sind. Die Darstellungsschicht (entspricht den DCE-Stubs!) mit ihrer ASN.1-Definition und den Presentationskontexten ermöglichen es, auch in heterogener Rechnerumwelt RPCs einsetzen zu können. Die Parameter werden über ASN.1 in eine globale Transfersyntax übersetzt. Allerdings: Die IDL wird wohl auf mehr Akzeptanz stossen als ASN.1.


Verteilte, objektorientierte Systeme bieten: Datenkapselung, Polymorphismus, Vererbung, Klassenbildung, feinere Granularität (Objekte& lt;< Client-Prozesse), Persistenz, by-reference-Übergaben erlaubt (angeblich - nur wie, das wurde nicht erklärt), Migrierbarkeit von Objekten zur Laufzeit und damit optimaler Lastenausgleich. Mögliche Strategien der Server-Objekte ohne Common Object Request Broker Architecture (CORBA)): Lastanziehung oder Lastabstossung (Börsenalgorithmus). Problem: Bei der Migration müssen alle kooperierenden Objekte über das neues Ziel informiert werden, weshalb hier meist zentrale Instanz (CORBA) eingesetzt wird, über die dies verwaltet wird.


Common Object Request Broker Architecture (CORBA): Von der non-profit-Organisation OMG (Object Management Group) entwickelt. Konzept ähnlich wie bei Distributed Computing Environment (DCE wurde z.T. integriert), aber CORBA-Interface Definition Language (IDL) erlaubt auch objektorientierte Elemente zu nutzen, v.a. Vererbung. Im Gegensatz zu DCE können die Schnittstellen auch dynamische Typen verarbeiten! Eine Migration der Objekte zur Laufzeit wurde bisher nicht berücksichtigt. Objekte, die eine Fkt. ausgeführt haben wollen, senden ihren Aufruf an CORBA, und der sorgt für einen passenden Empfänger. Vorteil: CORBA kann bei redundanten Objekten entscheiden, welches weniger ausgelastet ist.


Rightsizing: DV-Applikationen auf die Rechner verlagern, die dafür am besten geeignet sind. Wichtige Frage: Wie weit lasen sich operative Anwendungen dezentralisieren? Support und Fehlerbehandlung bei C/S noch mangelhaft im Vergleich zu Mainframes. Meistens bleibt daher Doppelbetrieb bestehen, der aber nicht eben billiger ist. Viele Rightsizing-Applikationen unterstützen Workflow-Management.


Mainframe-Abbau:

  • ERSATZ durch Midrange-Systeme wie z.B. (mehrere) AS/400 => die Investition des Terminal-Netzwerks bleibt erhalten.
  • PC-Netzwerk: Rechernetz statt Terminalnetz => i.d.R. leichter erweiterbar.
  • HOST und PC-Netzwerk: C/S-Verbund. PCs dann nicht nur für die Informationsdatenverarbeitung (IDV) da, sondern auch im operativen Geschäft einsetzbar.

Mainframe-Zukunft:

  • IBMs /390 Vector Facility wollen 62% laut Online-Umfrage auf keinen Fall kaufen!
  • Dedizierter Einsatz: Mainframes als Batch-Server.
  • IBM macht sich mit den POWER-CPU-basierten Parallelsystemen SP1 und SP2 selbst Konkurrenz, da diese den RISC/UNIX-Markt stärken.
  • BS2000 wurde mit Open Server Dimension-Variante offen: Seitdem wird kräftig angebaut.

Die meistbenutzten Produkte: WINDOWS > TCP/IP > UNIX > MSDOS > SQL > Novell NetWare > MVS. COBOL ist die verbreitetste Sprache. 60% der Entwicklungsressourcen gehen dadurch für die Wartung von Unwartbaren darauf.


SAP bietet ihre Integrationssoftware als Host- und Client/Server-Variante an: R/2 und R/3. Derzeit feiern beide Produkte in den USA Erfolge. R/3 wird um EDI erweitert für den elektronischen Datenaustausch zwischen externen Partnern. Das System läuft auf UNIX und WINDOWS-NT. Langfristig ist die Integration von OLE-Programmen wie Lotus Notes und MS Office in R/3 geplant (Integration statt Interfacing!). Unter dem Codenamen "Heidelberg" ist eine Plug & Play-Version für den PC in Arbeit. Das enorme Wachstum ihrer Produkte verschafft SAP inzwischen Service-Probleme, dem u.a. durch Videoconferencing entgegengewirkt wird. Massiv-parallele Variante von R/2 sind für IBMs S/390 in Arbeit, d.h., die User werden hier nicht zum R/3-System genötigt. Ab 1995 soll jedoch ein Migrationstools für den Umstieg von R/2 nach R/3 existieren.


Groupware: 3 Firmen dominieren hier: Lotus mit seinem Notes, welches im Prinzip nur ein E-Mail-basiertes shared Repository darstellt. MS, dass Groupware-Fkt. ins BS integriert. Novell, der sein Netz-Know-how für Groupware nutzen will. Übrigens: Workflow und Groupware haben verschiedene Zielsetzungen: Workflow will Kontrolle, Groupware will kreatives Miteinander!


Workflow-Management: Aktionsorientierte, prozessorientierte Vorgangsbearbeitung. Setzt getriggerte DBMS ein, die Akteure zur Reaktion nötigt (Gegensatz zu Groupware, wo Individuen das System zur Reaktion nötigen). Ist strategisch integriert ins Business Processing Reengineering. Doppelarbeiten fallen dabei zwar häufig an, dafür ist Qualität und Durchlaufzeit durch fehlende Schnittstellen wesentlich erhöht. Ist konform mit dem selbstoptimierenden Prozess nach ISO9000. Zu beachten: Wie gut unterstützt C/S die IT in der Wertschöpfungskette? Umlage-Verfahren bzgl. der GK sind nicht mehr up-to-date, C/S verlangt aufgrund seiner versteckten Kosten Prozess-Controlling über Workflow-Management.


C/S-Anwendungen der 2.Generation: Horizontale Teilung der vertikal geteilten Logiken Präsentation, Verarbeitung und DBMS. Das führt zum Lean Application-Ansatz im Zusammenhang mit der objektorientierten CORBA: Nur noch spezielle Applikationen-Objekt-Funktionen sind zu entwickeln, während alle allgemeinen Applikationen-Funktionen ins Netz gespeist werden, wo sie die CORBA aufnimmt und weiterleitet. Die Middleware, die die verteilte Präsentation und DBMS-Logik enthält, bietet den Objekten APIs an. Der CORBA-Broker, der auch verteilt realisiert sein kann, sorgt dabei für die nötige Interoperabilität. Alternativ kann auch mit Remote Procedure Calls (RPC) von der DCE gearbeitet werden, aber diese RPCs sind nicht asynchron, nicht objektorientiert, nicht dynamisch, nicht reusable, Objekte nicht in Bibliotheken verwaltbar, kein Polymorphismus, Granularität ist grob. Beispiel für Middleware: X-WINDOWS, OSF/RPCs


Wrapper: Programme, die bestehende Applikationen einkapseln und als Objekt einsetzbar machen, indem sie ein API nach aussen hin anbieten. Dadurch können Altanwendungen leicht zu den horizontal verteilten Applikationen-Objekten integriert werden.


UNIX als Ersatz-Betriebssystem für MVS kommt v.a. deshalb infrage, weil es:

  • offen ist, d.h. nicht-proprietär, frei kopierbar.
  • multiuser- und multitaskingfähig ist.
  • als relativ sicher gelten kann (im Gegensatz zu MSDOS).
  • es in C geschrieben und damit extrem portabel ist.
  • die RISC-Architektur über C begünstigt.

Fehlertolerante Systeme: Die Verteilung gestattet auch redundante Datenhaltung, die die Sicherheit der Daten erhöhen kann. Ziel bei fehlertoleranten Systemen ist, dass das Gesamtsystem sicherer als seine Komponenten ist. Dadurch, dass sie billiger als Spezialanfertigung sind, und Fehler z.T. hohe Kosten verursachen, können fehlertolerante Systeme u.U. billiger als Normal-Systeme werden. Weiteres Ziel: Fail-Save-Eigenschaft (das System gelangt nicht in einen gefährlichen Zustand). Erreicht werden diese Ziele durch HW-Redundanz (gespiegelte Platte, RAID, Voter-gesteuerter Ersatzprozessor), SW-Redundanz (N-Versions-Ergebnisvergleich mit Voting Majority). Beispiel für ein fehlertolerantes System: IBMs S/88!


IBM erkennt inzwischen den Markt für verteilte Systeme. Ihr Netzwerk SNA wurde durch die Ergänzung APPN (Advanced peer-to-peer-Networking) und der darin enthaltenen Norm LU 6.2 zum Open System (alternativ kann auch OSI-TP eingesetzt werden!). Der Anwender muss nur über die Schnittstelle CPI-Communication verfügen, dann kann er mit IBM-Mainframes kommunizieren. CPI-C ist in OS/400 und OS/2 bereits von Hause aus integriert! Auch wird intensiv an einem CISC-API gearbeitet, sodass der Standard-Transaktionsmonitor von IBM vom PC aus genutzt werden kann. Innerhalb von APPN können OSI-APs wie FTAM eingesetzt werden, die Entitäten konfigurieren sich selbst (Plug & Play), das APPN-Netz ist adaptiv und selbstlernend (die Knoten tauschen Routing-Informationen untereinander aus). Aber v.a.: APPN ist dezentral organisiert, kommt ohne Zentralinstanzen aus => Basis für VS!


Informationssysteme nach dem Dreischichtenmodell der IS-Planung:

  1. Strategische Unternehmensplanung
  2. Hersteller-unabhängige IS-Planung: Meistens zu klein.
  3. Hersteller-bezogene IS-Planung: Meistens viel zu gross.

MAP ist eine offene SW, die über das OSI-Modell eine Fertigungsautomation in heterogener Rechnerumwelt gestattet => CIM-Module können ohne Probleme miteinander kommunizieren. Über Standards wie EDI (nicht international, branchenspezifisch/branchenübergreifend) und EDIFACT (international, branchenspezifisch) lässt sich JIT realisieren. VDA ex. bei Autoindustrie, SWIFT (transaktionsorientiert) im Bankbereich.