Sind .NET und Java Formen der Applikations-Virtualisierung?

Der BITKOM veröffentlichte einen 3-teiligen Leitfaden zur Virtualisierung. Die doppelseitigen PDF-Dokumente behandeln "Business Grundlagen", "Design, Deployment und Betrieb" sowie "Sicherheit in virtuellen Umgebungen". Der eher praktisch orientierte zweite Teil enthält Marktübersichten für einige Produktkategorien. Im Gegensatz zu allen mir bekannten Produktverzeichnissen (siehe etwa auch die ausgezeichnete Übersicht von Virtuall) zählt das BITKOM-Papier Java und .NET zur Software für die Applikationsvirtualisierung.

Die Autoren des Leitfadens, überwiegend Mitarbeiter großer IT-Hersteller, gehen offenbar davon aus, dass die Laufzeitumgebungen von .NET und Java mit der Sandbox vergleichbar sind, in der Programme bei der App-Virtualisierung ablaufen. In beiden Fällen schiebt sich also eine Schicht zwischen Betriebssystem und Anwendung. Aber damit hören die Gemeinsamkeiten auch schon auf.

App-Virtualisierung zügelt native Anwendungen

Software zur Applikationsvirtualisierung wurde entwickelt, um wesentliche Schwächen im gewachsenen Anwendungsmodell von Windows zu kom­pen­sie­ren. Das betrifft vor allem die Tatsache, dass die Installation von Software das OS verändert, woraus Programmkonflikte und fehlerhafte Windows-Konfigurationen resultieren können. App-Virtualisierung wirkt dem entgegen, indem es den Anwendungen die betroffenen Systemkomponenten (Dateisystem und Registrierung) vorgaukelt und die Schreibzugriffe dorthin abfängt. Ein zusätzliches nützliches Feature der meisten Tools zur App-Virtualisierung besteht darin, dass Anwendungen via Streaming an den Client gelangen und damit ein alternativer Distributionsmechanismus für Software zur Verfügung steht.

.NET braucht keine Virtualisierung der Registry

Ganz anders liegt der Fall bei .NET. Augenscheinlich sollte es ebenfalls jene Defizite beseitigen, die mit der App-Virtualisierung bekämpft werden. Die Side-by-Side-Execution ist dafür gedacht, verschiedene Versionen einer Software nebeneinander ausführen zu können. Programme werden zu Assemblies verpackt, die alle Metainformationen enthalten und die sie daher nicht in die Registrierdatenbank schreiben. Wenn die Dateien von .NET-Anwendungen gelöscht werden, bleiben keine weiteren Spuren im System zurück.

Allerdings abstrahiert .NET nicht vom Betriebssystem, wie das bei der App-Virtualisierung geschieht, indem sie Systemkomponenten dupliziert. Das ist auch gar nicht notwendig, weil .NET-Anwendungen gar nicht an einem schlechten Verhalten gehindert werden müssen. Die CLR fügt dem Betriebssystem vielmehr neue Services zur Programmausführung hinzu, etwa die Laufzeitkompilierung der Intermediate Language oder ein fein abgestuftes Rechtesystem.

App-Virtualisierung belegt mangelnden Erfolg von .NET

Dass Microsoft nun App-V als Alternative zur herkömmlichen Installation propagiert, belegt, dass sich .NET nicht in dem Maß als Programmiermodell durchgesetzt hat, wie man das vor 10 Jahren gehofft hat. Insofern ist App-Virtualisierung eine nachträgliche Behelfslösung, um Legacy-Code in die Schranken zu weisen. Bei .NET und Java bedarf es einer solchen Virtualisierung nicht.

Der BITKOM-Leifaden enthält noch eine Eigentümlichkeit: Die Marktübersicht, die zwar ausdrücklich keinen Anspruch auf Vollständigkeit erhebt, vergisst bei der Betriebsystemvirtualisierung den Marktführer Parallels, während zwei relativ exotische IBM-Lösungen vertreten sind. Wahrscheinlich liegt das daran, dass IBM mit mehreren Mitgliedern im Redaktionsteam vertreten war, Parallels hingegen gar nicht.