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.

21.05.1993 - 

Management Report/PORTIERUNGSKONZEPTE

Middleware: Bruecke zwischen Anwendungs- und System-SW

Portabilitaet von Anwendersoftware beruht darauf, dass die Entwicklung der betreffenden Programme so erfolgt, dass sie ohne manuelle Eingriffe oder Aenderungen auf unterschiedlichen Computersystemen ablaufen koennen. In juengster Zeit hat die Forderung nach dieser Portabilitaet ein immer hoeheres Gewicht bekommen. Die rasanten Veraenderungen in der gesamten Branche der Informationstechnologie (IT) haben alte Strukturen aufgebrochen. Mit folgenden Trends muss gerechnet werden:

- Die Hardware-Innovation wird auch in der naechsten Zeit nicht gebremst. Das bedeutet Hardwarezyklen von 18 bis 24 Monaten, im PC-Bereich noch darunter.

- Im Bereich der Systemsoftware sind die Zyklen deutlich laenger - hier sind je nach Komponente drei bis fuenf Jahre realistisch.

- Bei der Anwendersoftware - dazu gehoert fast immer auch ein organisatorisches Konzept - kann man mit recht langen Zyklen von zehn bis 15 Jahren rechnen.

Es ist heute weder technisch zu bewaeltigen noch organisatorisch verkraftbar, Anwendersoftware und damit die organisatorischen Ablaeufe in kurzen Zeitraeumen komplett umzukrempeln; sie muss daher etliche Hardware- und gegebenenfalls auch einige Systemsoftwarezyklen ueberdauern koennen.

Eine nicht eindeutig definierte Schicht

Diese Anforderung konnte relativ unproblematisch erfuellt werden, solange der Anwender bei seinem Hardwarelieferanten blieb, denn dieser sicherte ihm in der Regel Aufwaertskompatibilitaet zu. Fuer den Anwender war es deshalb relativ leicht, wenn er es fuer notwendig hielt, auf ein neues, leistungsfaehigeres System umzusteigen. Er kam dadurch in den Genuss moderner Hard- und Softwaretechnologie mit einem besseren Preis-Leistungs-Verhaeltnis.

Heute will der Anwender Offenheit, das heisst die Freiheit, sich eine seinen Anforderungen entsprechende Hardwareplattform zu suchen, auf die er dann seine Loesung portiert, ohne dass ihre Funktionsfaehigkeit beeintraechtigt wird. Dies eroeffnet auch die Moeglichkeit, Software unterschiedlicher Herkunft auf einem System zusammenzufuehren.

Diese Zielvorstellung ist bisher am ehesten im PC-Bereich realisiert. Anwendersoftware fuer MS-DOS zum Beispiel ist auf allen MS-DOS-faehigen Systemen einsetzbar, unabhaengig vom jeweiligen Hardwarelieferanten. In fast allen anderen Bereichen ist das wesentlich problematischer.

Die Welt der IBM-kompatiblen PCs hat den hohen Nutzen und die Attraktivitaet von binaercodekompatiblen Systemen gezeigt. Auch im Bereich der Unix-Systeme besteht der Wunsch nach Binaercodekompatibilitaet seit laengerer Zeit. Zwar bemueht sich die OSF um Definitionen, aber noch ist kein Standard in Sicht.

Ein weiterer Aspekt erschwert beziehungsweise erleichtet die Portabilitaet von Anwendersoftware: die sogenannte "Middleware".

Middleware ist eine Schicht oberhalb des eigentlichen IT-Systems (bestehend aus Hardware und Betriebssystem). Sie ist nicht eindeutig definiert und auch nicht sauber abgegrenzt, schlaegt aber eine Bruecke zwischen der eigentlichen Systemsoftware (Betriebssystem) und dem Anwenderprogramm (vgl. die Abbildung).

Zur Middleware kann man zaehlen:

- hoeherwertige Datenhaltungs- und Datenbanksysteme,

- Kommunikationssoftware,

- Benutzerverwaltungs-Systeme,

- Transaktionsmonitore sowie

- Generatoren und Interpreter.

Die Middleware ist in vielen Faellen am schwierigsten zu portieren.

Entscheidend ist die Portierungs-Schnittstelle: oberhalb (Alternative 1 auf der Abbildung) oder unterhalb (Alternative 2) der Middleware.

Standardisierte Programmiersprachen

Zur Erhoehung der Portabilitaet ist oft die Nutzung von standardisierten (hoeheren) Programmiersprachen notwendig. Dieses Vorgehen funktioniert aber nur, wenn keine fremde Middleware genutzt wird oder die Middleware ebenfalls portabel ist.

Im Bereich der IBM-PC-kompatiblen Loesungen ist das kein Problem. Durch die Binaercodekompatibilitaet ist die

Middleware meist automatisch auf Systemen unterschiedlicher Anbieter verfuegbar.

Anders sieht es zum Beispiel innerhalb der Unix-Welt aus. Hier nutzt insbesondere die Middleware zur Verbesserung bestimmter Eigenschaften (beispielsweise der Performancedie Besonderheiten einzelner Unix-Implementierungen aus. Problematischer wird es bei unterschiedlichen Betriebssystemen, beispielsweise bei einer Portierung von MVS nach Unix. Nur ganz selten kommt ein in einer hoeheren Programmiersprache entwickeltes Programm ohne Middleware- Schicht aus. Die Portabilitaet der Middleware bestimmt daher in hohem Masse die Portabilitaet von Anwendersoftware.

Portable Middleware fuer portable Anwendungen

Es gibt verschiedene Ansaetze, um dem oben geschilderten Dilemma zu entkommen:

- Nutzung einer portablen Middleware als Basis fuer die Anwendungsentwicklung. Fast alle Anbieter offerieren heute nicht nur nackte Datenbanksysteme, sondern auch leistungsstarke Entwicklungsumgebungen (zum Beispiel Informix 4GL).

- Anwendersoftware, die auf einer solchen Basis entwickelt worden ist, ist portierbar auf alle Systeme, auf denen auch die Middleware - zum Beispiel Datenbanksysteme und die zugehoerige Entwicklungsumgebung - bereitgestellt wird. Bei den Datenbankanbietern ist das meist eine breite Palette. Nachteil fuer den Kunden ist haeufig eine Bindung an die zugehoerige Datenbank. Es gibt aber auch eine ganze Reihe von datenbankunabhaengigen MiddlewareAnbietern. Viele Hersteller von CASE-Tools haben Werkzeuge und Generatoren zur Entwicklung portabler Software auf den Markt gebracht. Hierbei werden entweder systemabhaengige Komponenten generiert oder entsprechend eingebunden. Eine andere Moeglichkeit besteht in der Bereitstellung von portablen Runtime- Komponenten.

- Standardsoftware im kommerziellen Bereich erreicht Portabilitaet in vielen Faellen durch die Portierung einer Runtime-Komponente. Die Software wird in einer speziellen Entwicklungsumgebung geschrieben und dann ueber einen Interpreter zum Ablauf gebracht. Durch Portierung dieser Komponente auf verschiedene Systeme ist die so entwickelte Anwendersoftware praktisch automatisch auch portabel. Nach diesem Konzept sind zum Beispiel die Loesungen R/3 von SAP, Triton von Baan/Space, Comet und ALX von Siemens-Nixdorf konstruiert.

Neben der Portabilitaet hat dieser Ansatz noch einige Vorteile fuer das Customizing, die Software-Maintenance und die Softwarelogistik.

Codeumsetzung mit Sprachkonvertern

In Einzelfaellen ist auch versucht worden, Portabilitaet durch Codeumsetzung herbeizufuehren. Mit Unterstuetzung von Generatoren wird eine vorhandene Softwareloesung weitgehend automatisch (70 bis 90 Prozent) in einer anderen Programmiersprache neu implementiert, zum Beispiel von Basic nach C. Die Problematik dieses Verfahrens liegt einmal in der im Ausgangsprogramm genutzten Middleware; zum anderen und oft mehr aber in der Maintenance und Weiterentwicklung des neu entstandenen Programms.

Pflege und Entwicklung

Software ist ein dynamisches Gut. Sie lebt nur, wenn sie auch gepflegt und weiterentwickelt, das heisst gewartet wird. Hier treten einige spezielle Konstellationen bei der Portierung auf. Folgende Faelle sind zu unterscheiden:

- Ein Anwender portiert von einem System auf ein anderes, zum Beispiel um eine neue Hardwareplattform einzufuehren. Wenn die Software einmal portiert ist, kann das alte System vergessen werden. "Mainteniert" werden muss dann nur

noch das neue System. Bei einem hohen Grad an Portabilitaet duerfte das mit Ausnahme der Codeumsetzung keine groesseren Probleme bereiten.

- Ein Anwender portiert von einem System auf verschiedene andere, zum Beispiel bei einer Multivendor-Strategie. Bei kompatibler Software entstehen aus einem einheitlichen Sourcecode unterschiedliche Object-Code-Versionen. Dies stellt besondere Anforderungen an die Release-Verwaltung, Verteilung und Qualitaetssicherung. In einer Runtime-basierten Loesung ist bei der Verfuegbarkeit der Runtime-Komponente auf den verschiedenen Zielsystemen ein einfaches Handling moeglich, da Objectcode und Sourcecode gleich sind.

Bei Standardsoftware gewaehrleistet die Bereitstellung einer portablen Version durch den Hersteller der Standardsoftware in der Regel auch die Sicherstellung der zukuenftigen Maintenance auf verschiedenen Systemen.

- Ein Anwender oder auch ein Software-Anbieter will eine portable Software entwickeln. Hier bietet eine portable Middleware eine gute Entwicklungsbasis. Insbesondere die Runtime-basierten Konzepte eignen sich wegen der grossen Vorteile bei Portabilitaet und Maintenance gut zur Entwicklung von Standardsoftware.

Dadurch, dass Objectcode gleich Sourcecode ist, muessen fuer unterschiedliche Systeme nicht verschiedene Versionen erstellt, getestet, gepflegt und verwaltet werden.

Offenheit kuenftig in allen IT-Bereichen

Der Wunsch nach Offenheit wird in Zukunft prinzipiell alle IT- Loesungen betreffen. Mit dem Begriff gemeint sein wird dann Freiheit bei

- der Auswahl der Hardware,

- der Systemsoftware,

- des Datenbanksystems und

- der Anwendersoftware.

Auf der anderen Seite steht das Thema Offenheit und damit auch Portabilitaet so sehr im Brennpunkt, dass die Standardisierung von Schnittstellen und Architekturen intensiv vorangetrieben wird. Die PC-Welt hat gezeigt, was eine hohe Portabilitaet wert ist. Dieses Bewusstsein gewinnt zunehmend auch in den anderen IT-Welten an Bedeutung.

*Klaus Adena ist Leiter Anwendungssoftware und Projekte bei der Siemens-Nixdorf Informationssysteme AG in Paderborn.

Abb: Entscheidend ist die Portierungsschnittstelle oberhalb und unterhalb der Middleware. Quelle: SNI