Remoting zwischen Mono + Linux und.net + Windows

Transkript

1 Remoting zwischen Mono + Linux und.net + Windows Dieter Bremes 4. Juni 2005 Lizenzbestimmungen Dieser Beitrag ist unter der UVM Lizenz (unveränderte Inhalte) < nrw.de/kunden/uvm/ lizensiert. Zusammenfassung Das Open-Source-Projekt Mono bietet dem Linux-Programmierer ähnliche Vorteile wie Java, neben einer umfassenden Infrastruktur mit einheitlichen Lösungsmustern vor allem Plattformunabhängigkeit und Sicherheit, ist aber technisch einfacher und sprachunabhängig..net ist Microsofts Implementierung derselben Standards und setzt bei der Windows- Programmierung neue Produktivitätsmaßstäbe. Der Einsatz von Mono und.net schafft deshalb ideale Voraussetzungen, um verteilte Programme in den üblichen heterogenen IT-Welten zu realisieren - beispielsweise mit Linux-Servern und Windows-Clients. Die Kommunikation zwischen den Programmteilen kann so die Nachteile anderer Standards wie Web Services oder COR- BA vermeiden und das sogenannte Remoting einsetzen: Eine in die Plattform integrierte und leicht erweiterbare Infrastruktur, die beliebige Datentypen zwischen beliebigen Plattform-Implementierungen performant überträgt. Nach einer kurzen Einführung in die technischen Grundlagen des Remoting demonstriert dieser Vortrag anhand praktischer Beispiele, mit welcher Performance beim Remoting zwischen einem Server mit Linux und Mono sowie seinen Clients mit Windows und.net zu rechnen ist. Er zeigt außerdem Tuning-Möglichkeiten und zieht einen Vergleich zu Alternativen wie Web Services und Terminal Servern. Etwas Grundwissen zu.net, TCP/IP und verteilten Anwendungen wäre optimal, die technischen Grundlagen des Remoting werden erläutert.

2 1 Remoting zwischen Mono und Linux sowie.net und Windows Das Open-Source-Projekt Mono bietet dem Linux-Programmierer ähnliche Vorteile wie Java: neben der Produktivitätssteigerung durch eine umfassende Infrastruktur mit einheitlichen Lösungsmustern vor allem Plattformunabhängigkeit und Sicherheit; es ist aber technisch einfacher und sprachunabhängig..net ist Microsofts Implementierung derselben Infrastruktur und setzt bei der Windows- Programmierung neue Produktivitätsmaßstäbe. Der Einsatz von Mono und.net schafft deshalb ideale Voraussetzungen, um verteilte Programme in den üblichen heterogenen IT-Welten zu realisieren - beispielsweise mit Linux- Servern und Windows-Clients. Die Kommunikation zwischen den Programmteilen kann so die Nachteile anderer Standards wie Web Services oder CORBA vermeiden und das sogenannte Remoting einsetzen: Eine in die Plattform integrierte und leicht erweiterbare Infrastruktur, die beliebige Datentypen zwischen beliebigen Plattform-Implementierungen performant überträgt. Nach einer kurzen Einführung in Mono und die technischen Grundlagen des Remoting demonstriert dieser Vortrag anhand praktischer Beispiele, mit welcher Performance beim Remoting zwischen einem Server mit Linux und Mono sowie seinen Clients mit Windows und.net zu rechnen ist. Er zeigt außerdem Tuning-Möglichkeiten und zieht einen Vergleich zu Alternativen wie Web Services und Terminal Servern. 1.1 Was ist Mono? Die Frage Was ist Mono? beantwortet das Projekt am besten selber; von der Mono-Website ( com/main Page): Mono is a platform for running and developing modern applications, based on the ECMA/ISO Standards. Mono can run existing programs targeting the.net or Java frameworks. Mono is an open source effort led by Novell and is the foundation for many new applications. Hinter Mono steht also ein Java-ähnliches Plattformkonzept - man schreibt Programme für die Plattform und nicht mehr für ein bestimmtes Betriebssystem oder eine bestimmte Hardware-Architektur: write once, run everywhere. Für diesen Zweck bietet Mono eine Laufzeitumgebung, eine Klassenbibliothek und einen Compiler für die neue Sprache C#. Ein großer Teil dieser Implementierung beruht auf entsprechenden ECMA- und ISO-Standards, die auch die Grundlage von Microsofts.NET bilden. Das Mono-Projekt wurde im Jahr 2001 von Miguel de Icaza gegründet, in der Linux-Welt als Vater des Gnome-Projekts und Gründer der Firma Ximian bekannt. Im Jahr 2004 erschien

3 die Version 1.0 des Projekts, aktuell (Mai 2005) sind die Versionen (Stable) sowie (Development) und für September 2005 ist die Version 1.2 geplant. Mono bietet eine vollständige Programmier-Infrastruktur für Fat Clients und Web-Anwendungen. Es enthält dazu neben entsprechenden Oberflächenelementen beispielsweise auch eine Unterstützung für Datenzugriff und -darstellung. Seine Klassenbibliothek und Laufzeitumgebung übernehmen darüber hinaus Aufgaben wie Threading und Sicherheit und definieren auch das vollständige und damit sprachunabhägige Typsystem der Plattform. Mono-Binaries sind unter < com/downloads> für SUSE- und Redhat-Linux sowie für OS X und Windows erhältlich; durch den ebenfalls verfügbaren Quelltext lässt sich Mono außerdem für andere Betriebssysteme, wie FreeBSD, übersetzen. 1.2 Warum Mono? Sowohl als Anstoß für die Entwicklung als auch bei der Argumentation zum Einsatz von Mono kristallisieren sich drei Gründe heraus: produktiveres Entwickeln, Plattformunabhängigkeit und erhöhte Sicherheit. Bestehende Lösungsansätze wie Java, GTK und QT bieten oft nicht die gewünschten Vorteile - und schließlich profitieren nicht nur in der Natur alle Beteiligten von konkurrierenden Alternativen. Sehr prägnant beschreibt der Vater des Mono-Projekts seine Motivation: Life is too short for debugging C code! Und schließlich soll Mono nicht nur die Entwicklung unter Linux angenehmer machen - hinter allen Überlegungen steht natürlich auch das Ziel, Linux auf den Desktop zu bringen Produktiveres Entwickeln Mono ermöglicht produktiveres Entwickeln durch die standardisierte Infrastruktur, die Sprachunabhängigkeit und Komponentenunterstützung, das vereinfachte Erstellen von Webseiten und Web Services sowie das Ende der DLL-Hell (DLL = Dynamic Link Library, entspricht Shared Object unter Linux). Die standardisierte Infrastruktur bietet zum einen Funktionalität, die in anderen Bibliotheken nicht enthalten ist - beispielsweise XML-Unterstützung oder moderne Sicherheits- Features. Sie befreit zum anderen vom Zwang, sich betriebssystemspezifische Details merken zu müssen, wie die unterschiedliche GUI-Programmierung unter Windows, OS X und Linux. Mono unterstützt verschiedene Compiler und bietet dadurch Sprachunabhängigkeit. Diese erhöht vor allem das Angebot an Komponenten und anderen Bibliotheken, denn der Anbieter muss nicht mehr Bindungen oder sogar Implementierungen für einzelne Sprachen liefern. Sie vereinfacht außerdem, sich in beliebige Mono-Programme einzuarbeiten - die

4 benutzte Infrastruktur mit ihrem Objektmodell bleibt ja gleich, und es ändert sich nur die Syntax wie geschweifte Klammern oder Semikolons. Weil Mono auch die Infrastruktur für Webseiten und Web Services enthält, muss man sich für solche Anwendungen weder in neue Lösungsmuster einarbeiten, noch sich mit den Details von HTTP und HTML auseinandersetzen. Unter Mono kann man problemlos verschiedene Versionen einer Bibliothek (.DLL bzw..so) installieren. Welche Bibliotheksversion ein Programm verwendet, lässt sich sowohl beim Übersetzen des Programms als auch später durch den Administrator konfigurieren. Die insbesondere unter Windows gefürchtete DLL-Hell, die durch unbeabsichtigtes Überschreiben einer von anderen Programmen genutzten Bibliothek entsteht, ist damit Geschichte Plattformunabhängigkeit Die Plattformunabhängigkeit ergibt sich aus der von Mono-Compilern generierten plattformunabhängigen Zwischensprache (Intermediate Language), die erst zur Ausführungszeit in eine maschinenspezifische Sprache übersetzt wird (just-in-time kompiliert). Mono- Programme laufen also auf jedem Betriebssystem, für das eine entsprechende Laufzeitumgebung existiert. Die Laufzeitumgebung ist entweder Mono selber oder das dazu kompatible.net von Microsoft. Mono-Programme laufen damit auf Linux, OS X und Windows; durch den frei verfügbaren Quelltext lässt sich Mono außerdem für andere Betriebssysteme übersetzen Erhöhte Sicherheit Mono bietet erhöhte Sicherheit vor allem durch Programmausführung in einer virtuellen Maschine, durch automatische Speicherverwaltung und durch das neue Konzept der Codezugriffssicherheit. Jedes Mono-Programm läuft innerhalb einer virtuellen Maschine - durch dieses Sandbox- Prinzip kann Code nicht direkt auf Betriebssystem oder Hardware zugreifen. Zusätzlich schützt die automatische Speicherverwaltung sowohl vor ungewollten Speicherlecks und daraus resultierender Programm-Instabilität als auch vor böswilligen Buffer-Overrun-Angriffen. Schließlich bietet Mono als Ergänzung der bekannten rollenbasierten Sicherheit ein völlig neues Sicherheitskonzept: die Codezugriffssicherheit (Code Access Security). Dieses Konzept knüpft bestimmte Rechte an den Code selber - unabhängig von den Rechten des angemeldeten Benutzers. Dadurch hat beispielsweise Code, der aus dem Internet kommt, automatisch nur stark eingeschränkte Rechte - selbst wenn der Benutzer als root bzw. Administrator angemeldet ist. Rechte und Codegruppenzugehörigkeit lassen sich sehr feingranular konfigurieren, insbesondere kann der Administrator entsprechende Festlegungen auch später noch ändern.

5 1.3 Was ist Remoting? Remoting ist der Begriff für jede Kommunikation zwischen Programmteilen in Mono - auch für die Intra-Prozess-Kommunikation. Um maximale Sicherheit bei bester Performance zu erreichen, verwendet Mono innerhalb eines Prozesses sogenannte Anwendungsdomänen (Application Domains). Diese Anwendungsdomänen schirmen Programmteile ähnlich voneinander ab wie eine Prozessgrenze, kosten aber weniger Performance bei der Datenübertragung und weniger Ressourcen. Während das Remoting innerhalb eines Prozesses hauptsächlich bei Web-Anwendungen auftritt, ist es beim Datenaustausch zwischen Mono-Anwendungen über Prozess- oder Rechnergrenzen die Regel. In jedem Fall geschieht es völlig automatisch. Im Gegensatz zu den meisten anderen Kommunikationslösungen ist Remoting sehr gut konfigurierbar und erweiterbar. So lässt sich beispielsweise festlegen, ob die Daten per TCP, HTTP oder über ein anderes Protokoll übertragen werden sollen. Ebenso kann man das Datenformat und Zusatzfunktionalität wie Kompression und Verschlüsselung frei bestimmen. Verglichen mit Web Services bietet Remoting neben den schon genannten Freiheiten insbesondere eine höhere Performance und es ist nicht auf XML-Datentypen beschränkt. Dafür fehlt die Plattformunabhängigkeit - um beispielsweise mit einem C-Programm über Rechnergrenzen zu kommunizieren bietet sich also nach wie vor ein Web Service an. 1.4 Wie funktioniert Remoting? Sobald zwei Anwendungsdomänen miteinander Daten austauschen, beginnt automatisch das Remoting. Die folgenden Abschnitte beschreiben die zentralen Bestandteile der dabei verwendete Infrastruktur sowie die gängigsten Konfigurationsmöglichkeiten Formatierer und Kanäle Die Remoting-Infrastruktur serialisiert zunächst mit sogenannten Formatierern die zu übertragenden Daten. Sie benutzt dazu normalerweise einen der beiden eingebauten Formatierer, die wahlweise das standardisierte SOAP-Format oder ein kompakteres Binärformat erzeugen. Danach erfolgt die eigentliche Datenübertragung über sogenannte Kanäle; Mono bringt dazu einen HTTP- und einen TCP-Kanal für die entsprechenden Netzwerkprotokolle mit. Schließlich stellt die Remoting-Infrastruktur auf Empfängerseite automatisch die Ausgangsdaten wieder her. Welche Formatierer und Kanäle verwendet werden sollen, konfiguriert man über XML- Dateien. Außerdem lassen sich eigene Formatierer und Kanäle einbinden, um beispielsweise Verschlüsselung zu realisieren oder einen Message Queue Server einzubinden.

6 1.4.2 Übertragen als Wert oder als Referenz Ähnlich wie der Datentransport lässt sich auch das Verhalten der zu übertragenden Objekte bzw. Klassen konfigurieren. Zum einen kann man Objekte als Wert übertragen (Marshal-byvalue, MBV) oder als Referenz (Marshal-by-reference, MBR). Beim Übertragen als Wert wird normalerweise das gesamte Objekt kopiert, einschließlich privater Felder. Dazu muss die zugrunde liegende Klasse entweder mit dem Attribut SerializableAttribute gekennzeichnet sein oder die Schnittstelle ISerializable implementieren, außerdem lassen sich Felder auch explizit vom Serialisieren ausschließen. Diese Übertragungsvariante ist sinnvoll, wenn danach viele Mitgliedszugriffe erfolgen; große Objekte zu kopieren belastet natürlich Rechner und Netzwerk. Die zweite Übertragungsvariante, das Übertragen als Referenz, kopiert nicht das Objekt selber sondern nur die Parameter- und Rückgabewerte entsprechender Mitgliedsaufrufe. Dieses Paradigma ist beispielsweise von Microsofts COM / DCOM (Distributed Component Object Model), von Java RMI (Remote Method Invocation) oder von Web Services bekannt. Damit eine Klasse an dieser Übertragungsvariante teilnehmen kann, muss sie von MarshalByRefObject abgeleitet sein - die Remoting-Infrastruktur generiert dann automatisch Proxies. Diese Variante bildet den Normalfall der Übertragung, für die Parameterwerte selber gelten natürlich die Regeln des Übertragens als Wert Aktivierungsverfahren Für Objekte, die als Referenz übertragen werden sollen, kann man verschiedene Aktivierungsverfahren wählen. So kann entweder der Client (Client-activated-object, CAO) oder der Server (Server-activated-object, SAO) das Objekt aktivieren. Beim Konstruktor-Aufruf eines Client-aktivierten Objekts entsteht dieses sofort auf dem Server, außerdem wird am Client ein entsprechender Proxy mit Referenz auf das Objekt erzeugt - aus diesem Vorgehen resultiert natürlich ein Round-trip zwischen Client und Server. Weil das Objekt dem erzeugenden Client exklusiv zur Verfügung steht und seinen Zustand auch über mehrere Methodenaufrufe erhält, bieten Client-aktivierte Objekte ein von lokalen Objekten gewohntes Programmiermodell. Dazu gehört auch, dass der Client beliebige Konstruktoren aufrufen kann. Weil Client-aktivierte Objekte zustandsbehaftet sind, eignen sie sich nicht für Server-Farmen und schränken dadurch die Skalierbarkeit der Anwendung ein. Bei Server-aktivierten Objekten entscheidet der Server, wann das Objekt tatsächlich erzeugt wird - dementsprechend entsteht die Instanz nicht beim Konstruktor-Aufruf, sondern erst beim Zugriff auf eine Methode oder Eigenschaft. Außerdem ruft der Server immer nur den Standardkonstruktor auf. Server-aktivierte Objekte existieren wiederum in zwei Varianten: Singleton-Objekte und Single-call-Objekte. Von einem Singleton-Objekt existiert immer nur eine Instanz, die sich alle Clients teilen - mit ähnlichen Vor- und Nachteilen wie bei den Client-aktivierten Objekten. Dagegen erfolgt jeder Methoden- oder Eigenschaftszugriff auf ein Single-call-Objekt

7 über eine eigene Instanz. Das hört sich zwar sehr nach Ressourcenverschwendung an, ist tatsächlich aber das am besten skalierende Verfahren. Denn weil die Objekte nicht zustandsbehaftet sind, kann der Server zum einen Objekte recyceln (Object-pooling). Zum anderen ist die Sitzung nicht an einen bestimmten Server gebunden, jeder Zugriff kann problemlos von einem anderen Server erledigt werden Lebensdauerverwaltung Während Single-call-Objekte per Definition sofort freigegeben bzw. recycled werden, ist für die Lebensdauerverwaltung von Client-aktivierten und Singleton-Objekten ein sogenannter Lease Manager zuständig. Dieser begrenzt die Lebensdauer (Lease) normalerweise auf fünf Minuten bzw. zwei Minuten nach jedem Zugriff. Beide Werte lassen sich konfigurieren; zusätzlich kann man sogenannte Sponsoren einrichten, die der Lease Manager konsultiert, bevor er ein Objekt freigibt. In keinem Fall sollte man im Client-Code aber davon ausgehen, dass ein als Referenz übertragenes Objekt beim nächsten Aufruf noch existiert Konfiguration In den meisten Fällen werden Client und Server durch je eine XML-Datei konfiguriert; Kanal, Formatierer und ähnliche Festlegungen müssen natürlich in beiden übereinstimmen. Diese Art der Konfiguration hat zum einen den Vorteil, dass man eine Anwendung nicht neu kompilieren muss, um beispielsweise Verschlüsselung hinzuzufügen oder einen anderen Server anzusprechen. Ein weiterer Vorteil besteht darin, dass die Programmlogik nicht durch Infrastruktur-Code verwässert wird. In komplexeren Problemszenarien wird man statt Konfigurationsdateien oft die verschiedenen Methoden der Activator-Klasse benutzen müssen. Das ist beispielsweise nötig, um Server dynamisch einzubinden oder um den Clients ein bestimmtes, vorkonfiguriertes Objekt zu übergeben Host-Anwendungen Prinzipiell kann jede ausführbare Datei als Remoting-Server dienen. Zusätzliche Anforderungen, wie Sicherheit und Skalierbarkeit, machen aber im allgemeinen eine sogenannte Host-Anwendung nötig. Die Host-Anwendung bildet den von außen ansprechbaren Teil des Servers, die eigentliche Funktionalität steckt dabei in einer Bibliothek. Als Host-Anwendung eignet sich prinzipiell jede ausführbare Datei, diese Variante wird man aber nur zu Testzwecken während der Entwicklungsphase nutzen.

8 Ein Dienst bzw. Dämon bildet die zweite Variante der Host-Anwendung; sein einziger Vorteil gegenüber anderen ausführbaren Dateien liegt aber darin, dass kein Benutzer angemeldet sein muss. Erst die dritte Variante der Host-Anwendung, ein Web- oder Anwendungs-Server, erfüllt zusätzliche Anforderungen nach Sicherheit und Skalierbarkeit. Unter Windows dienen dazu die integrierten IIS (Internet Information Services), eventuell In Kombination mit den Enterprise Services. Für Linux-Server bietet sich der Apache- sowie der Mono Application Server an; beide sind zusätzlich für Windows verfügbar. Je nach Host-Anwendung kann diese zusätzliche Funktionalität bieten, wie Load-balancing oder verteilte Transaktionen. Andererseits kann eine Host-Anwendung auch Einschränkungen mit sich bringen, so unterstützen die IIS nur den HTTP-Kanal. 1.5 Remoting im Test Im Server-Bereich hat Linux bereits deutlich an Boden gewonnen; während es dort inzwischen auch Windows-basierte Server verdrängt, dominiert dieses Betriebssystem auf absehbare Zeit noch den Desktop- bzw. Client-Bereich. Für verteilte Programme bietet sich in diesem Szenario natürlich eine Mono- und.net-basierte Lösung an: man muss sich nur in eine Plattform einarbeiten und kann deren spezialisiertes und entsprechend performantes Kommunikationsverfahren nutzen. Gegen den Einsatz von Mono auf dem Client spricht heute vor allem noch die nicht abgeschlossene Entwicklung der GUI-Bibliotheken und der Entwicklungswerkzeuge. Den besten Eindruck vom Nutzen einer Lösung mit Mono auf dem Linux-Server und.net auf den Windows-Clients verschafft ein Test, der zum einen ihre Performance mit der einer reinen, Windows-basierten.NET-Lösung vergleicht. Zum anderen sollte dieser Test einen Vergleich mit der Standardlösung beim Verbinden von Plattformen, einem Web Service, bieten Test-Aufbau Der Server des Test-Aufbaus besteht Software-seitig zum einen aus einer Bibliothek, deren sechs Methoden verschiedene Datenmengen und -arten senden und empfangen. Übertragen werden dabei zwei verschiedene Tabellen aus Microsofts Northwind-Beispieldatenbank in DataSet-Instanzen mit einem Umfang von bzw Zeichen netto sowie eine benutzerdefinierte Objektliste mit Zeichen netto. Weil Methoden zum Senden und Empfangen vorhanden sind, lässt sich sowohl das Remoting vom Server zum Client als auch die umgekehrte Richtung testen. Den zweiten Teil des Servers bildet ein einfaches Kommandozeilenprogramm als Host- Anwendung. Es unterstützt zum einen die performanteste Kommunikationsvariante, also TCP-Kanal und Binärformatierer. Um vergleichsweise die Performance eines Web Service zu simulieren, unterstützt die Host-Anwendung außerdem das Remoting mit HTTP-Kanal und

9 SOAP-Formatierer - denn in die Performance eines richtigen Web Service würde natürlich auch die des Web Servers eingehen. Den Client bildet ebenfalls ein Kommandozeilenprogramm, das beim Aufruf der Server- Methoden die benötigte Zeitspanne misst und in einer Datei protokolliert. Dabei lässt sich konfigurieren, wie oft jede Methode nacheinander aufgerufen wird und welche Wartezeit zwischen diesen Aufrufen vergehen soll. Außerdem kann man diese Aufruf-Folgen über einen einstellbaren Zeitraum wiederholen, um beispielsweise Speicherproblemen auf die Spur zu kommen. Gemessen wird zur Vereinfachung des Test-Aufbaus nur die reine Zeit, nicht die Netzwerk-, CPU- und Speicherbelastung. Außerdem erfolgt der Test nur mit einem Client. Der Server wird beim Test zunächst unter Windows 2000 und.net 1.1 ausgeführt. Vergleichsmessungen erfolgen dann mit derselben Hardware unter SUSE Linux 9.2 sowohl mit Mono als auch mit Mono Der Client läuft immer unter Windows 2000 und.net 1.1. Client- und Server-Rechner sind miteinander über einen Switch ohne externe Netzwerkbelastung verbunden. Client- und Server-Programme werden unter Windows 2000 und Visual Studio.NET 2003 kompiliert, der Mono-Compiler geht also nicht in das Ergebnis ein Test-Ergebnisse Die Test-Ergebnisse sind in Abbildung 1 bis 3 zusammengefasst. Dabei zeigt Abbildung 1 den Vergleich zwischen Remoting und Web Services. Ein Web Service, simuliert durch HTTP-Kanal und SOAP-Formatierer, kann demnach durchaus 50 % Performanceverlust gegenüber der Remoting-Variante (TCP-Kanal und Binärformatierer) verursachen.

10 Abbildung 1: Remoting- gegen Web Service -Performance In Abbildung 2 ist das Zusammenspiel von.net 1.1 unter Windows und Mono (in SUSE Linux 9.2 enthalten) unter Linux zu sehen; als Vergleichskriterium dient hier wie in Abbildung 1 eine reine.net-lösung mit TCP-Kanal und Binärformatierer. Die Get-Methoden, also die Übertragung vom Server zum Client, sind 30 % bis 50 % langsamer als bei einer reinen.net-lösung, liegen aber zumindest noch im Performance-Bereich der Web Service -Lösung. Dagegen schleppen die Take-Methoden einen Overhead von rund 200 Millisekunden mit sich - diese Zeitspanne würde reichen, um die gesamte Orders- Tabelle zu übertragen. Abbildung 2: Mono gegen.net 1.1-Performance Erfreulicherweise zeigt Abbildung 3 enorme Entwicklungsfortschritte bei Mono in der (bis Anfang Mai 2005) aktuellen Development-Version Die Performance-Unterschiede bei den Get-Methoden sind auf rund 10 % geschrumpft und die Performance der Take-Methoden ist jetzt wenigstens besser als die der Web Service -Lösung.

11 Abbildung 3: Mono gegen.net 1.1-Performance Dieser Test kann natürlich nur als Gerüst und Anregung für eigene Tests dienen, in denen man seine Lösung und mögliche Alternativen möglichst genau nachbildet. Beispielsweise könnte man durch neugierige Firewalls gezwungen sein, den HTTP- statt den TCP-Kanal zu benutzen - wie weit senkt das die Performance der Anwendung? Relativ statische Daten könnte man auch komprimieren; das liegt insbesondere bei DataSet-Instanzen nahe, die auch über den Binärformatierer ein unnötig geschwätziges Serialisierungsformat erzeugen - ist die gesparte Bandbreite die zusätzliche Prozessorbelastung wert? 1.6 Alternativen zum Remoting zwischen Mono und Linux sowie.net und Windows Die folgenden Abschnitte beschreiben kurz bestehende Alternativen zum Remoting zwischen Mono und Linux sowie.net und Windows. Betrachtungsschwerpunkt ist dabei, inwieweit die Lösung zur Überwindung von Plattformgrenzen beiträgt - auch im Hinblick auf den Lernaufwand Java Als Alternative bietet sich zunächst natürlich eine Java-Lösung an, diese Plattform verfolgt ja exakt das gleiche Ziel wiemono und.net. Dementsprechend hat auch diese Lösung den Vorteil, dass der Entwickler sich nicht in unterschiedliche Paradigmen, Objektmodelle und Infrastrukturen verschiedener Server- und Client-Plattformeneinarbeiten muss. Client-seitig kranken Java-Lösungen aber immer noch an der fehlenden RAD-Unterstützung (Rapid Application Development); VEP (The Eclipse Visual Editor Project) bietet hier nur

12 einen Anfang, und die Datenbindung fehlt immer noch. Außerdem erfordert die generell höhere Komplexität einer Java-Lösung einen entsprechend höheren Einarbeitungs- und Implementierungsaufwand. Die meisten Unternehmen haben sich aber ohnehin schon grundsätzlich für oder gegen Java entschieden, so dass diese Alternative meistens keine Rolle mehr spielt Web Service Die Alternative Web Service hilft dagegen nur, Plattformgrenzen zu überwinden. Der Entwickler muss sich also trotzdem in verschiedene Plattformen einarbeiten, dazu kommt der im Test demonstrierte Performance-Verlust sowie die Einschränkung auf XML-Datentypen. Außerdem ist die Definition der entsprechenden Standards noch nicht abgeschlossen, beispielsweise fehlen Festlegungen zu Transaktionsbehandlung und Verschlüsselung Web Anwendung Eine Web Anwendung ist von Hause aus plattformübergreifend nutzbar - von Browser- Inkompatibilitäten abgesehen. Außerdem ist sie skalierbar und erledigt ihr Rollout sozusagen selber, ein weiterer nicht zu unterschätzender Vorteil. Trotzdem finden Server- und Client-Entwicklung auch in aktuellen Implementierungen wie ASP.NET noch in völlig unterschiedlichen Welten statt, mit entsprechendem Lernaufwand für den Programmierer. KO-Kriterium ist aber meistens die fehlende Funktionalität und Performance interaktiver Oberflächen, praktisch realisierbar sind zur Zeit nur relativ einfache Eingabefenster. Diese Einschränkungen werden in Zukunft sicher durch Standards wie XForms und SVG entfallen, zur Zeit unterstützt sie aber noch keiner der üblichen Webbrowser Terminal Server Je nach Sichtweise ändert sich für den Entwickler durch den Einsatz eines Terminal Servers alles oder auch nichts: ein verteiltes Programm ist nicht mehr nötig, ebensowenig die Überwindung einer Plattformgrenze - beides erledigt der Terminal Server bzw. seine Client- Software. Nachteilig sind an dieser eher administrations- als architekturbasierten Lösung neben der Abhängigkeit von einem bestimmten Hersteller vor allem die erhöhten Hardware-Kosten durch die größere Serverlast sowie die begrenzte Skalierbarkeit einer Zweischichtanwendung. Zum anderen besteht das Problem, auf jedem Client spezielle Software installieren zu müssen. Im Allgemeinen verwendet man Terminal Server deshalb nur für standardisierte Arbeitsplätze, wo Diskless-Workstations durch gesparten Administrationsaufwand die erhöhten Serverkosten wettmachen. Ein weiterer Anwendungsfall besteht in Not- und Übergangslösungen

13 - z. B. um bei der Linux-Migration ein Windows-Programm, das nicht unter einem Emulator wie Wine läuft, trotzdem auf einem Linux-Client nutzen zu können. 1.7 Fazit Mono und.net sind inzwischen zum ernsthaften Java-Konkurrenten geworden, wobei die Kombination aus Mono und.net durch geringen Lernaufwand und hohe GUI-Produktivität punkten kann. Die anderen Alternativen für plattformübergreifende Programme eignen sich entweder nur für bestimmte Anwendungsfälle, bieten nur Teillösungen oder erfordern die Einarbeitung in mehrere Plattformen. Der Test zeigt, dass auch die Performance einer verteilten Anwendung mit Linux-Server und Windows-Clients vom Einsatz von Mono und.net profitiert - ein Web Service wäre wesentlich langsamer. Ebenso zeigt der Test, dass auch in der aktuellen Mono-Version noch Überraschungen lauern, die man beim Lösungsdesign berücksichtigen sollte. Und schließlich wird deutlich, dass Mono mit jedem Release noch besser wird - die Entwickler empfehlen übrigens inzwischen den Einsatz der Develpoment-Version.