Wer meint eigentlich was mit Portabilität? Während die einen damit Unabhängigkeit von Hardwarelieferanten assoziieren, sprechen andere davon, auf Entwicklungssystemen erstellte Software auf die Zielsysteme zu übertragen. Dritte wiederum variieren das Thema dahingehend, daß die Unabhängigkeit von einem Datenhaltungssystem, einem Netzwerk oder sonstigen Softwarekomponenten gemeint ist - oder alles zusammen.
Die nachfolgende Betrachtung geht von folgenden Annahmen aus:
- Die ideale Form der Portierbarkeit von Applikationen ist die völlige Unabhängigkeit von Hardware, Betriebssystem, Datenhaltungssystem und Verteilung von Ressourcen oder Datenbeständen.
- Es gibt funktionale Abhängigkeiten und konzeptionelle Abhängigkeiten. So ist zum Beispiel die Verfügbarkeit eines Cobol-Compilers eine funktionale Abhängigkeit (ohne geht's gar nicht), während eine konzeptionelle Abhängigkeit die Nutzung von Mehrfachprozessoren wäre (Applikation läuft, nutzt aber nur eine CPU von vielen).
- Abhängigkeiten können mit einem wirtschaftlichen Wert versehen werden. Dieser Wert sind die Kosten, die entstehen, wenn aufgrund der Veränderung eines Betriebsmittels die Applikation geändert oder gar neu implementiert werden muß. Eine ideal portierbare Applikation hat in jeder Kategorie der Abhängigkeit den Wert Null.
Der durchschnittliche Lebenszyklus von Hardware beträgt mittlerweile etwa fünf Jahre. Betrachtet man demgegenüber die Lebensdauer von 15 bis 20 Jahren für eine Applikation, bedeutet dies, daß jede Applikation drei- bis viermal umgesetzt werden muß. Die großen Hardware-Hersteller bemühen sich natürlich, jeweils die Objektcode-Kompatibilität zu erhalten. Die Vergangenheit hat jedoch gezeigt, daß dies über technologische Sprünge in der Hardware hinweg nicht immer gegeben war. Zuweilen wurde dann auch ein sogenannter Kompatibilitätsmodus unterstützt, der aber die Leistungsfähigkeit der neuen Hardware nicht nutzte und somit letztendlich unwirtschaftlich war.
Die Objektcode-Abhängigkeit ist durch die Verfügbarkeit von Hochsprachen der dritten Generation heutzutage am einfachsten zu lösen Die Wahl einer normierten Programmiersprache setzt bei entsprechender Disziplin der Programmierer den Wert dieser Abhängigkeit auf Null.
Das Betriebssystem Unix steht für die Unabhängigkeit von der Hardware schlechthin. Doch mittlerweile dürfte es sich bis in den letzten Winkel herumgesprochen haben, daß Unix nicht gleich Unix ist. Zweifellos ist es einfacher, eine Applikation von Unix System V des Herstellers A nach Unix System V des Herstellers B zu portieren als von einem herstellerspezifischen Betriebssystem zu einem anderen, aber allzu sorglos sollte man dabei nicht sein.
Portabilität allein auf ein portables Betriebssystem aufzubauen, scheint auch deshalb nicht ratsam zu sein, weil Unix zwar auf vielen Rechnern verfügbar ist, aber es nicht in jedem Fall das optimale Betriebssystem ist. Ein Flugreservierungssystem mit Tausenden von Bildschirmen stellt andere Anforderungen an ein Betriebssystem als eine Entwicklungsumgebung mit 60 oder 70 Bildschirmen.
Konzeptionelle Abhängigkeiten lassen sich grob in zwei Kategorien einteilen:
Die Abhängigkeit von einer spezifischen Architektur ist mit der Abhängigkeit von einem bestimmten Rechnertyp vergleichbar, wenn auch die Folgen nicht ganz so offensichtlich sind. Symmetrische oder asymmetrische Multiprozessoren erfordern aber zur optimalen Nutzung entsprechende Berücksichtigung in der Architektur der AppIikation.
Die Parallelisierung auf Prozeßebene wird heute zwar weitgehend von dem Betriebssystem von Multiprozessorsystemen geleistet, doch muß die Applikation selbst dazu in mehrere Prozesse aufgeteilt sein und über eine eigene Synchronisationslogik verfügen. Ist das nicht der Fall, werden die vorhandenen Prozessoren nur bei einer entsprechenden Anzahl von Benutzern, sprich Prozessen, genutzt, wobei der maximale Durchsatz eines einzelnen Prozesses durch die Leistungsfähigkeit eines Prozessors begrenzt wird.
In der Praxis sind dies jene Fälle, wo bei der Aufrüstung eines Multiprozessorsystems mit einem zusätzlichen Prozessor keine Verbesserung der Antwortzeiten einer Applikation erreicht werden kann.
Die Unabhängigkeit von der Computerarchitektur kann nur mit einer entsprechenden Architektur der Applikation berücksichtigt werden. Die Ausrichtung auf Monoprozessoren macht möglicherweise den Einsatz auf Multiprozessoren unrentabel. Dies wiederum ist nur mit einem Redesign der Applikation zu beheben und entsprechend teuer.
Logische Konzepte sind untrennbar mit der Architektur einer Applikation verbunden. Die Wahl des Datenmodells entscheidet also nicht nur über das Datenhaltungssystem - Filesystem, Datenbanksystem oder relationales Datenbank-Management-System (DBMS) -, sondern auch über weite Teile der Programmlogik. Darüber hinaus beeinflußt die Wahl des Datenhaltungssystems die Integrationsfähigkeit von Applikationen sowie die Nutzung von verteilter Rechnerleistung und verteilter Datenhaltung. Die wirklich wichtigen Entscheidungen zur Portabilität werden in diesem Bereich getroffen. Hier entscheidet sich, ob eine Applikation nicht nur lauffähig ist, sondern auch die gegebenen Möglichkeiten nutzen kann und somit langfristig wirtschaftlich ist.
Nicht immer werden Datenmodell und Zugriffsart auseinander gehalten. Für die Portierbarkeit von Applikationen lag naturgemäß die Zugriffsart und deren Standardisierung im Vordergrund. Daß bei SQL die Datenmanipulationssprache (DML) und die Datendefinitionssprache (DDL) zusammengefaßt wurden, macht diese Unterscheidung nicht gerade leichter. Seit sich relationale DBMS und SQL im Markt durchsetzen, nutzen manche Hersteller von Datenbanksystemen selbst eine teilweise Implementation des DML-Teils(!) von SQL als Hinweis auf die Relationalität ihres ansonsten unveränderten DBMS - und tragen somit ihren Teil zur Verwirrung bei.
Darüber wird gerade im Zusammenhang mit der Portierbarkeit zuweilen vergessen, daß für die Architektur der Applikation das Datenmodell entscheidend ist und nicht, welche Befehle für den Zugriff kodiert werden müssen. Natürlich ist eine standardisierte SQL-Schnittstelle wichtig, aber entscheidend für die Programmlogik ist doch, ob eine mengenorientierte Verarbeitung möglich ist oder nicht. Es hat auf die Logik der Verarbeitung einen größeren Einfluß, ob ich dem relationalen Datenmodell entsprechend Nullwerte verarbeiten kann oder ob meine invertierte Liste einen entsprechenden Eintrag nicht kennt.
Durch die enge Verknüpfung der Verarbeitungslogik ist eine Applikation nur begrenzt über Datenmodelle hinweg portierbar. Die Abhängigkeit vom Datenmodell ist deshalb als teuer einzustufen. Die Kosten können durch die Einhaltung eines Standards bei der Zugriffsart entschärft, nicht aber grundsätzlich vermieden werden, wenn von einem relationalen DBMS mit SQL auf ein nicht- oder semirelationales DBMS mit SQL-Schnittstelle übergegangen wird.
Die Verteilung von Ressourcen nach dem Client-Server-Modell baut auf der dezentralen Verarbeitung von zentral gehaltenen Daten auf. Dieses Konzept kann entweder in der Architektur der Applikation selbst, über die Dienste eines Filesystems (NFS, RFS) oder aber durch die Nutzung eines entsprechenden relationelen DBMS gelöst werden.
Die Implementation in der Applikation stützt sich möglicherweise auf weitgehend standardisierte Protokolle, doch bietet die Nutzung entsprechender Filesysteme oder relationaler Datenbank-Management-Systeme (RDBMS) den Vorteil der Transparenz zur Applikationsseite. Dies bedeutet, daß Applikationen die sich auf Filesysteme oder RDBMS abstützen, zwar portabel zwischen nur lokal verarbeitenden Umgebungen und verteilten Ressourcen sind, andererseits eine entsprechende Abhängigkeit eingehen. Bei einem RDBMS kann diese Abhängigkeit durch die Standardisierung von SQL aber entschärft werden.
Integrierbarkeit von Applikationen
Hat eine Applikation alle Hürden der Portabilität genommen, bleibt als letztes das Zusammenspiel mit anderen Applikationen, die bereits vorhanden sind, sprich die Integration. Die engste Integration ist gegeben, wenn alle Applikationen auf dem gleichen Datenmodell aufbauen.
Die Vorzüge des relationalen Datenmodells wurden an anderer Stelle bereits hinreichend erläutert und die wesentlichen Neuentwicklungen bauen alle auf diesem Modell auf. Selbst die jüngste Entwicklung auf diesem Gebiet, objektorientierte Datenbanken, sind entgegen anderslautender Ansichten kein Ersatz, sondern eine Weiterentwicklung des relationalen Modells. Auch kann nur ein relationales DBMS aufgrund der Mengenorientiertheit den vollen Sprachumfang von SQL implementieren und somit die Einhaltung des entsprechenden Standards gewährleisten.
Dies wiederum bedeutet für die Portierbarkeit einer Applikation, daß das relationale Datenmodell das einzige ist, bei dem die Abhängigkeit durch einen Standard entschärft und somit als wirtschaftlich tragbar zu bewerten ist.
DBMS als "Isolierschicht"
Der Weg der Portierbarkeit ist trotz allem ein steiniger. Es ist ob all der Bewegung in bezug auf Standards und Trends deshalb nicht weiter verwunderlich, wenn große Unternehmen die Risiken begrenzen wollen und deshalb eigene Standards setzen. Durch die Festlegung auf bestimmte strategische Produkte entstehen so Arbeitsteilungen mit bestimmten Herstellern von Hardware und horizontaler Software. Viele Unternehmen haben sich deshalb zum Beispiel auf ein relationales DBMS festgelegt, welches als "Isolierschicht" zwischen der Computerplattform und der Applikation fungiert. Einerseits delegiert der Benutzer damit das Problem der Portierbarkeit, andererseits sichert er seine Unabhängigkeit weitgehend durch die Nutzung einer standardisierten SQL-Schnittstelle.