Aufwand und Know-how muessen hoch sein

Die Anwendungen teilen und trotz Downsizing beherrschen

21.05.1993

Portabilitaet wird zu einer strategischen Eigenschaft von Anwendungssoftware. Dies gilt sowohl fuer fertig gekaufte als auch fuer selbst entwickelte Programme. Zwei wesentliche Eigenschaften von Client-Server-Systemen sprechen fuer diese Behauptung:

- Client-Server-Systeme sind in der Regel heterogen bezueglich der eingesetzten Hardware, der Betriebssysteme und der Systemsoftware (vgl. Abbildung 1). Dazu kommt die hohe technische Innovationsrate in Hardware und Systemsoftware bei PCs und Unix-Loesungen. Insgesamt geht der Trend zu offenen Client-Server-Systemen mit der Moeglichkeit der freien Auswahl von Hardware und Softwarebausteinen.

- Client-Server-Systeme sollen sich flexibel an neue Aufgaben und veraenderte organisatorische Strukturen von Unternehmen anpassen. Die Verlagerung von DV-Funktionen kann dabei in allen Variationen auftreten: Zentrale Dienste werden dezentralisiert (zum Beispiel wegen Kompetenzverlagerung in die Geschaeftsstellen), dezentrale Dienste werden teilweise oder ganz zentralisiert (zum Beispiel wegen der Performance oder der Sicherheit), und bestimmte Dienste sollen sowohl zentral als auch dezentral erbracht werden.

In den folgenden Abschnitten sollen die Zusammenhaenge erlaeutert und Vorschlaege fuer die technische Realisierung gegeben werden.

Mit Portabilitaet eines Softwaresystems ist zunaechst die Unabhaengigkeit von Hardware und Betriebssystem gemeint. Eine weitgehend akzeptierte Definition lautet:

Portabilitaet ist eine Eigenschaft von Software (Programmen und Daten), die es erlaubt, diese Software nach automatischen Aenderungen auf ein anderes Grundsystem (bestehend aus Hardware und Betriebssystem) zu transportieren und die Funktionen mit vorgeschriebener Genauigkeit und Effizienz auszufuehren.

Unterschiedliche Hardware und Betriebssysteme werden unterstuetzt und die Leistungen (Funktionalitaet, Genauigkeit und Effizienz) der portierten Software muessen fuer das neue Grundsystem definiert sein.

Als Qualitaetsmassstab fuer die Portabilitaet einer Software laesst sich das Verhaeltnis des Aufwands fuer die Neuentwicklung zum Aufwand fuer die Portierung heranziehen:

P=AI / (AI + AP + AA), wobei 0.95 < P < 1.0

mit den Bedeutungen:

P = Portabilitaetsmass; gute Portabilitaet bedeutet, dass weniger als fuenf Prozent der Neuentwicklung fuer die Portierung benoetigt werden,

AI = Aufwand fuer die Neuentwicklung,

AP = Aufwand fuer die Portierung sowie

AA = Aufwand fuer Anpassung und Optimierung.

Es hat sich gezeigt, dass Portabilitaet nicht nur von der Programmiersprache abhaengt, sondern wesentlich von der Struktur der Software und der Einhaltung von Standards. Damit wird Portabilitaet auch zu einem Qualitaetsmass von Softwaresystemen.

Fuer Anwendungssoftware in Client-Server- Systemen reicht diese Definition jedoch nicht aus. Portable Anwendungsfunktionen muessen auch von den wichtigsten Komponenten der Systemsoftware (wie DBMS, GUI, Netz) unabhaengig sein und zusaetzlich ueber eine einheitliche Schnittstelle zur Kommunikation zwischen lokalen und verteilten Funktionen verfuegen.

Als Grundprinzip fuer die Realisierung portabler Anwendungssoftware gilt:

Bei der Programmierung duerfen keine Funktionen des Betriebssystems und der Systemsoftware (speziell DBMS, GUI, Netz) direkt aufgerufen werden, sondern nur indirekt ueber virtuelle Schnittstellen (VS).

Der Umfang von virtuellen Schnittstellen

Eine virtuelle Schnittstelle kapselt die urspruengliche Schnittstelle ab, so dass die aufrufende Anwendungsfunktion syntaktisch und semantisch von dem unterlegten System unabhaengig wird. Der Umfang einer VS haengt einerseits von den Unterschieden in den Produkten ab, andererseits aber auch von der gewaehlten logischen Implementierungsebene der VS.

- Betriebssystem (OS): Die VS des Betriebssystems wird moeglichst nahe am realen Betriebssystem orientiert. Der Anwender kann hierfuer auf den Standard Posix zurueckgreifen. Posix lehnt sich eng an Unix V an, das heisst, die meisten Unix-Versionen sind Posix-kompatibel. Damit wird die Anwendung unabhaengig von den Unix-Varianten; ausserdem werden auch fuer proprietaere Betriebssysteme (wie VAX/VMS, BS2000) Posix-Schnittstellen angeboten oder sind angekuendigt (Windows NT, IBM). Zusaetzlich bieten auch einige Softwarehaeuser virtuelle Schnittstellen fuer verschiedene Betriebssysteme an.

- Datenbanksystem (DBMS): Die VS fuer das Datenbanksystem sollte trotz der Normierung von SQL logisch hoeher angesiedelt werden; es empfiehlt sich die Definition einer DB-Zugriffsschicht auf Transaktionsebene. Das bringt neben der

Unabhaengigkeit vom DB-Produkt auch noch Performance- und Technologievorteile. Denn Transaktionen (Sequenzen von SQL- Anweisungen) lassen sich in modernen DBMS als Stored procedure in der Datenbank ablegen. Das bedeutet eine deutliche Reduzierung der Interaktionen zwischen Anwendung und DBMS (in Client-Server- Systemen eine Voraussetzung fuer OLTP-Anwendungen) und vereinfacht die Programmierung der Anwendung (Moeglichkeit der objektorientierten Modularisierung!).

- Grafische Benutzeroberflaeche (GUI): Die verfuegbaren Programm- Schnittstellen der einzelnen GUIs unterscheiden sich erheblich und sind aufwendig zu programmieren. Eine VS, die funktional maechtiger ist als die Schnittstellen der einzelnen GUIs, bringt als Vorteile die Produktunabhaengigkeit und eine deutliche Reduzierung des Aufwands in der Progammierung. Hierfuer beginnt sich eine neue Generation von Werkzeugen mit VS fuer mehrere GUIs durchzusetzen. Die VS werden entweder in Form von Libraries oder als Werkzeugumgebung (4GL-Frontware und objektorientierte Sprachen) angeboten. Aktuelle Produktbeispiele sind: XVT von XVT Software, Open Interface von Nexus und Starview von Starvision.

- Netz: Der VS fuer das Netz kommt in Client-Server-Systemen eine besondere Bedeutung zu. Zum einen sind netztransparent (ueber WAN und LAN) dezentrale Funktionen aufzurufen. Zum anderen sollen lokale und verteilte Funktionen nicht fest mit bestimmten Clients und Servern verbunden sein. Wegen der geforderten flexiblen Anpassung muessen Funktionen auch in der Betriebsphase neu zugeordnet werden koennen. Hierfuer wird eine Nachrichten- Schnittstelle zwischen den separaten Funktionen benoetigt, die einheitlich sowohl lokal auf einem Rechner als auch verteilt im LAN auf mehreren Rechnern effizient laeuft. Fuer diese Schnittstelle gibt es Definitionen und erste Implementierungen mit Normungscharakter von der OSF (Open Software Roundation) im Rahmen der DCE-Aktivitaeten als RPC (Remote Procedure Call) und von der OMG (Object Management Group) im Rahmen von OMA (Object Management Architecture) als ORB (Object Request Broker).

- ISO-Schichtenmodell: Die Technik der virtuellen Schnittstellen ist nicht neu; sie wird von einigen Softwarehaeusern und Anwendern bereits seit mehr als zehn Jahren mit Erfolg eingesetzt. Ueberwiegend wird heute ein Softwareschichtenmodell benutzt; es wurde urspruenglich aus dem ISO/OSI-Schichtenmodell abgeleitet (vgl. Abbildung 1). Dabei wird die Software in logische Schichten eingeteilt; als Service bezeichnet man die Zusammenfassung mehrerer Funktionen, die eine Leistung ueber eine definierte Schnittstelle anbieten. Die Zuordnung von Services zu den Schichten ist so zu waehlen, dass die Services einer Schicht nur von Funktionen hoeherer Schichten angesprochen werden.

In diesem Sinne ist die Abhaengigkeit der Schichten in Abbildung 1 zu verstehen.

Portabilitaet laesst sich nach diesem Modell auf drei Ebenen erreichen:

- Hardware-Unabhaengigkeit (vgl. Abbildung 2): Es wird auf allen Hardwareplattformen das gleiche, portable Betriebssystem eingesetzt. Anwendungs- und Systemsoftware bleiben unveraendert. Dieses Vorgehen ist nur in Client-Server-Systemen mit homogenem Betriebssystem (zum Beispiel nur OS/2 oder nur Unix) praktikabel.

- Betriebssystem-Unabhaengigkeit (vgl. Abbildung 3): Es wird auf den verschiedenen Hardware/OS-Plattformen die gleiche Anwendungs- und Systemsoftware eingesetzt, das heisst Anwendungs- und Systemsoftware muessen jeweils bereits Betriebssystemunabhaengig realisiert und auf die ausgewaehlten Plattformen portiert sein.

3. Systemsoftware-Unabhaengigkeit (vgl. Abbildung 4): Es werden auf verschiedenen Hardware/OS-Plattformen auch unterschiedliche Produkte eines Typs von Systemsoftware eingesetzt. Dieses Modell setzt portable Anwendungssoftware im Sinne der erweiterten Definition voraus.

Eine Verfeinerung des ISO-Schichtenmodells mit Beruecksichtigung aller Softwarekomponenten eines geplanten Systems liefert Aussagen ueber weitere Kandidaten fuer virtuelle Schnittstellen.

Client-Server-Konzept und Software-Architektur

Client-Server als Software-Architektur bedeutet Aufteilung einer Anwendung in mehrere separate Prozesse, die auf einem oder auf verschiedenen Rechnern ablaufen koennen. Der Auftraggeber (Client) initiiert eine Anfrage an den Auftragnehmer (Server); die Eigenschaften Client und Server sind dabei nur temporaere Rollen eines Prozesses und nicht an die Hardware gebunden. Man bezeichnet diese Art der Aufgabenteilung auch als Cooperative processing.

Die physische Trennung von Client und Server erfordert die Einhaltung zusaetzlicher Randbedingungen beim Software-Entwurf:

- sinnvolle Aufteilung eines Softwaresystems,

- definierte, moeglichst stan dardisierte Schnittstellen,

- minimaler Datenaustausch zwischen den Funktionen so wie

- Einsatz einer Funktion auf verschiedenen Rechnern.

Erschwert wird der Software-Entwurf zusaetzlich durch die Forderung der Anwender, eine Funktion auch nachtraeglich auf einem anderen Rechner einsetzen zu koennen.

Die Gruende hierfuer koennen aus organisatorischen Aenderungen, aus einer besseren Lastverteilung oder aus Sicherheitsanforderungen resultieren.

Leider erlauben die bisher benutzten Software-Engineering- Verfahren keine systematische Strukturierung von Softwaresystemen nach dem Gesichtspunkt der Verteilbarkeit. Neue Perspektiven eroeffnen hier die objektorientierten Softwaretechniken mit der Kapselung von Daten und Funktionen in Objekten und dem einheitlichen Nachrichtenmechanismus zwischen den Objekten (vergleiche auch OMA mit dem ORB).

Ausgehend von einer groben Unterteilung der Anwendungssoftware in Praesentation, Funktionen und Datenverteilung, lassen sich fuenf verschiedene Verteilungsmodelle definieren (vgl. Abbildung 5). In konkreten Anwendungen von Client-Server-Systemen treten meist mehrere dieser Varianten auf. Selbst die Wahl der Schnittstellen zwischen den Funktionen kann sehr unterschiedlich ausfallen.

Systematische Entwicklung langfristig wartbarer, portabler Software verlangt gerade fuer Client-Server-Systeme den Einsatz von Werkzeugen und eine definierte Software-Architektur mit entsprechenden Standards und Schnittstellen fuer die Entwicklung. Hohe Produktivitaet erreicht man mit 4GL-Sprachen, die die Bedienung von GUIs unterstuetzen; gut geeignet sind auch objektorientierte Sprachen mit Klassenbibliothek.

Beide genannten Ziele (Wartbarkeit und Produktivitaet) sind heute mit einem Sprachkonzept nicht erreichbar. Insbesondere stellen die Forderung nach hoher Produktivitaet und nach Offenheit (im Sinne von Standards und Austauschbarkeit von Produkten) noch Gegensaetze dar. Es gibt zum Beispiel keinen Standard fuer eine 4GL. Jede 4GL ist proprietaer.

In dieser Situation bietet sich eine Aufteilung der Anwendung in strategische und nichtstrategische Funktionen an. Die strategischen Funktionen sollten unter dem Gesichtspunkt der langfristigen Wartbarkeit, der Portabilitaet und der Offenheit entwickelt werden. Nichtstrategische Funktionen (zum Beispiel individuelle DV und Ad-hoc-Auswertungen) koennen unter dem Gesichtspunkt hoher Produktivitaet erstellt werden. Fuer beide Funktionsklassen bindend sind dann das einheitliche Datenmodell sowie ausgewaehlte Standards und Schnittstellen (zum Beispiel DB- und Netz-Schnittstelle).

Wichtige Bedingungen fuer die Realisation

Zur Realisierung der portablen Anwendungsfunktionen fuer Client- Server-Systeme muessen die folgenden Randbedingungen eingehalten werden:

- Aufteilung eines Anwendungssystems in separate Prozesse mit geringer Belastung der Schnittstellen zwischen den Prozessen,

- Einheitliche Nachrichten-Schnittstelle fuer alle Prozesse,

- Verwendung von virtuellen Schnittstellen fuer alle strategischen Softwarekomponenten wie OS, DBMS, GUI, Netz,

- Verwendung eines portablen Subsets einer Programmiersprache, die auf allen Zielsystemen verfuegbar ist; das koennen 3GL, 4GL oder objektorientierte Sprachen sein.

Der portable Quellcode der Anwendungsfunktionen besteht dann nur noch aus Sprachelementen des definierten Subsets der ausgewaehlten Programmiersprache (vgl. Abbildung 6). Bei der Portierung sind damit die Anpassungen an spezielle Eigenschaften des Zielsystems und des Ziel-Compilers minimal.

Dagegen laesst sich der Quellcode der einzelnen virtuellen Schnittstellen nur bedingt portabel gestalten. Der Anwender muss entscheiden, ob er die virtuellen Schnittstellen als Produkte einkauft oder selbst realisiert.

Zusammenfassend kann festgestellt werden: Offenheit und Flexibilitaet eines Client-Server-Systems sind keine von der Stange kaufbaren Produkte. Die neuen Moeglichkeiten der Client-Server- Systeme werden nur von muendigen Anwendern genutzt werden koennen; einen wesentlichen Beitrag zur Erreichung dieses Ziels stellt die sorgfaeltige Planung der Software-Architektur dar. Der Aufwand und das erforderliche Know-how fuer diese Arbeit sind groesser als in den klassischen, proprietaeren DV-Systemen.

*Diplomphysiker Gerd Henselmann ist Mitglied der Geschaeftsleitung der Collogia Unternehmensberatung, Koeln.

Abb. 1: Grobes Softwareschichtenmodell. Quelle: Collogia

Abb. 2: Unabhaengigkeit von der Hardware. Quelle: Collogia

Abb. 3: Unabhaengigkeit vom Betriebssystem. Quelle: Collogia

Abb. 4: Unabhaengigkeit von der Standardsoftware. Quelle: Collogia

Abb. 5: Variationen von Client-Server-Systemen. Quelle: Gardener Group

Abb. 6: Portable Anwendungsfunktionen. Quelle: Collogia