Zügig eine Cross-Plattform entwickeln
Von: Matthias Bauer
Linux-Server sind im Kommen – SAP zum Beispiel hat ihre Produkte schon zu sieben Prozent auf Linux installiert, gegenüber fünf auf Mainframes. Clients und Windows ist praktisch eins. Eine Cross-Plattform zwischen beiden ermöglicht es das IT-Service- Management zu automatisieren.
Linux auf Servern, um Lizenzkosten zu sparen. Windows auf den Clients, weil die Anwendungen es erfordern. – Bei Behörden ist diese Integration sehr häufig Ausschreibungsbedingung, bei Unternehmen kommt dies immer häufiger vor. Netze mit Hunderten von Linux- Servern sind inzwischen kein Problem mehr,und sie bedienen in konkreten Fällen weit über hunderttausend Benutzer an zig Tausenden von PCs. Auch die Einbeziehung von SAP in einen solchen Rahmen funktioniert reibungslos – zum Beispiel unter Suse-Linux. Linux ist erwachsen geworden und »professional«.
Die Frage ist, an welcher Stelle Anwendungssoftware benötigt wird, die von den Servern aus agiert und deshalb direkt unter Linux lauffähig sein muss. Die Automatisierung des IT-Service- Managements in einem umfangreichen Linux/ Windows-Netz und die Portierung eines dafür geeigneten Systems ist mit Hilfe von Mono und ».NET« möglich. Mono ist eine Open-Source- Entwicklungsplattform und gewissermaßen die Brücke von .NET zu Linux. So kann bei der Anwendungsentwicklung voller Gebrauch von .NET gemacht werden. Seine Plattform-überbrückenden Eigenschaften erreicht es über das übliche Konstrukt einer »Virtual Machine«.
ECMA-Ausschüsse arbeiten an deren Standardisierung wie auch an der von Verknüpfungen zwischen Mono und C++ oder an der von Class- Libraries. Das Entwicklungsteam für die Mono- Plattform um Miguel de Icaza arbeitet seit einiger Zeit für Novell. Damit ist dieses traditions-reiche Unternehmen für Netzwerkbetriebssysteme zum Sponsor der Initiative geworden.
Die Notwendigkeit des Projekts ergab sich aus Folgendem:Um ein umfangreiches Netzwerk organisatorisch am Laufen zu halten, ist ein effizientes IT-Service-Management notwendig, das auf beiden Ebenen »wie zu Hause« agiert. Im konkreten Beispiel wurde ein System für IT-Service- Management als Cross-Plattform portiert, das maximale Automatisierung der Abläufe zwischen Benutzern und Ressourcen zu realisieren versucht, um im laufenden Betrieb mit einem Minimum an Bedienungsaufwand auszukommen.
Auf Systemen mit Windows-Servern hatte sich bereits gezeigt, dass die Zahl der mit ITService- Management befassten Administratoren in Netzen mit Tausenden von Benutzern und voller Einbeziehung stetig synchronisierter SAPKonten auf einige wenige begrenzt werden konnte, wo nach alter Arbeitsweise Dutzende nötig gewesen wären.Nun lag ein aktuelles Projekt vor, das ohne einen solchen, hohen Automatisierungsgrad vom öffentlichen Betreiber nicht einmal finanzierbar gewesen wäre. Es ging um ein neu aufzubauendes, riesiges Netz in den oben schon erwähnten Dimensionen an Stelle einiger Insellösungen. Mehraufwand für Administratoren jedoch war im Budget für die laufenden Kosten nicht vorgesehen.
Mono oder JavaEinleitend evaluierten das Projektteam, das heißt, das Entwicklungsteam bei Völcker Informatik, die Frage »Mono/.NET oder Java«. Obgleich Mono zum damaligen Zeitpunkt noch ganz am Anfang stand und auch .NET erst frisch auf den Markt gekommen war,kristallisierte sich eine eindeutige Entscheidung für Mono heraus.
Java ist, wenn man sich nur auf die »Virtual Machine« verlässt, sehr langsam.Man braucht, um es vernünftig zu betreiben, relativ große und teure Server und Umgebungen.Die Performanz verbessert man dann beispielsweise durch Middleware von IBM.Ein solcher Aufwand wäre kontraproduktiv gegenüber der Idee des Ganzen.
Überhaupt war .NET als die modernere Alternative zu erkennen,wobei es dem Projektteam natürlich auch wegen seiner Vertrautheit mit der Microsoft-Welt entgegenkam. Das Projektteam konnte auf Grund seiner Untersuchungen voraussehen, dass es zu einem überwiegenden Teil in der Lage sein würde, seine Codes unter Microsoft zu entwickeln und eins zu eins unter Mono laufen zu lassen.Auch zum Beispiel Beschleunigungsmechanismen gegen-über dem Betriebssystem sind in .NET schon impliziert.
Zudem bewegte sich das Projektteam mit .NET ebenso wie mit Mono in einem offiziellen ECMA-Standard. Dabei ist Novell ebenso im Standardisierungsgremium für .NET vertreten wie Microsoft oder Hewlett-Packard.
Effizientes Arbeiten mit Mono
Schon zu dem Zeitpunkt, als das Projekt begonnen wurde, erwies sich Mono als sehr effizient, und inzwischen hat sich noch einiges getan.Man kann sich darin leicht einarbeiten und es läuft stabil. Die Portierung der existierenden Automatisierungsplattform für Windows, die in ihrer ursprünglichen, auf der Microsoft-COM-Architektur beruhenden Version rund sieben Millionen Zeilen Code umfasste,war innerhalb von neun Monaten durchgeführt. Dabei verringerte sich ihr Umfang trotz erweiterter Funktionalität auf rund drei Millionen Zeilen. Das lag vor allem daran, dass .NET viel Funktionalität als fertige Abläufe anbietet, die auf der vorherigen Basis selbst codiert werden mussten.Die Portierung der Anwendung nahm sogar den geringeren Teil der Fertigstellungszeit in Anspruch.Der neue Code wurde übrigens zu 100 Prozent in C++ geschrieben.
Aufwändiger war die Umsetzung der zum Service- Management-System gehörenden Datenbank von Microsoft-SQL-Server auf Oracle. Auch im derzeitigen Stadium von Mono ist es immer wieder einmal notwendig, partiell eigene Entwicklungen vorzunehmen. Entsprechend häufiger trat diese Situation in der damaligen Phase auf. Das erwies sich jedoch als unproblematisch und ist ja eigentlich auch der Sinn einer Open-Source. Sie stehen dann den Mono- Entwicklern als sogenannte Fixes zur Wahl. Die Unterstützung durch das Mono-Team um Miguel de Icaza mit Novell im Hintergrund war übrigens ganz hervorragend.
Das Projektteam stellte fest, dass auch schon in der frühen Version von Mono, die damals anstand - Novell war damals noch nicht eingestiegen - bereits die Funktionalität zu einem großen Teil vorhanden waren, die es für die Initiierung der Management-Dienste benötigte.
Zudem konnten die Projektverantwortlichen erkennen, dass sie selbst in der Lage sein würden, die jenigen Stellen zu ergänzen, die für die eigenen Zwecke noch fehlten. Später entwickelten das Projektteam dann an die 150 sogenannte Fixes, die es,wie das üblich ist,der Open-Source überstellte.Unter anderem waren auch die notwendigen Konvertierungsfunktionen für die Zeichensätze im Rahmen der jeweiligen Betriebsund Dateisysteme an das Deutsche anzupassen, also Umlaute und Sonderzeichen.
Es war nicht allein die Anpassungsentwicklun selbst, die Zeit kostete, sondern auch der verdoppelte Testaufwand. Auf beiden Betriebssystemen musste natürlich die Mono-Lauffähigkeit der in .NET entwickelten Komponenten getestet werden. Dabei konnte es nicht nur um die Einzelkomponenten gehen, sondern vor allem auch um Durchlauftests für die komplexen Prozessketten, die bei der Automatisierung kompletter Geschäftsprozesse auftreten.
Nach Abschluss des Projekts schätzten die Projektverantwortlichen die Reduzierung der Testzeit gegenüber einem Java-Ansatz auf 60 Prozent. Fünf bis zehn Programmierer, die sonst zusätzlich erforderlich gewesen wären, wurden so eingespart.
Von SQL auf Oracle
Der ganze Aufwand für die Portierung schlug nicht so hoch zu Buche wie die Umstellung der Datenbank von Microsoft-SQL-Server auf Oracle. Die Management-Plattform ist gewissermaßen um eine zentrale Datenbank herum gebaut. Dort liegen nicht allein die Eintragungen zu Identity-Management,Zugriffs- und Einkaufsberechtigungen, technischer und kaufmännischer Bestandsverwaltung (Assets, Lizenzen), Konfigurations- und Kostenmanagement, Software-Verteilung oder Helpdesk-Unterstützung.
Auch die Informationen für die Automatisierung der Anforderungs- und Erfüllungsprozesse werden von dort abgerufen. Im Falle einer SAP-Implementierung werden zudem die detaillierten Identitäts- und Berechtigungseintragungen aus R/3 ständig synchronisiert und mitgeführt. Was Datenbankspezialisten natürlich bekannt ist,wird bei Entscheidungsfindungen auf höherer Ebene oft unterschätzt: SQL-Abfragen erfordern eine gänzlich unterschiedliche Struktur, je nachdem, ob sie auf Microsoft-SQL-Server oder auf Oracle abgearbeitet werden sollen.
Die Auffassung »SQL ist doch SQL« wird also in der Praxis ad absurdum geführt. Da die verschiedenen Datenbanksysteme intern unterschiedlich arbeiten,kommt es darauf an, sie mit denjenigen Sprachanweisungen anzusprechen, die bei ihnen die performanteste Verarbeitung auslösen.
Ein Beispiel: Das Statement »NOT IN« ist in Microsoft-SQL-Server relativ performant in der Abarbeitung.Bei Oracle sollte an dieser Stelle ein anderes Sprachkonstrukt beispielsweise über einen »JOIN« gewählt werden. Darüber hinaus gibt es auch Ausdrücke in SQL, die das eine oder andere Datenbanksystem nicht annimmt. Am Schluss noch eine Bemerkung zu der Grundfrage »Linux oder Windows auf den Servern «: Windows erfordert auf den Servern einen geringeren Betriebsaufwand hinsichtlich der Grundkonfiguration und des Managements als Linux. Dadurch wird über die Jahre ein Teil der an Lizenzen gesparten Kosten wieder wett gemacht.
Es ist völlig klar, dass jedwede Automatisierung, die Konfigurationen und sonstige Maßnahmen von Hand einspart, erst einmal erarbeitet werden muss und dafür sehr viel Aufwand erfordert. Das gilt natürlich auch für den Ausbau von Linux. Um so sinnvoller erscheint es, in einem solchen Projekt dafür zu sorgen, dass dem Gesamtsystem ein Maximum an Automatisierung aus der Windows-Welt zur Verfügung steht und dass diese Automatisierungseffekte durch eine reibungslos funktionierende Cross-Plattform zwischen Linux-Servern und Windows-Clients zum Tragen kommen.
Matthias Bauer,
Leiter Entwicklung, Völcker Informatik
Zügig eine Cross-Plattform entwickeln.
Linux-Server sind im Kommen – SAP zum Beispiel hat ihre Produkte schon zu sieben Prozent auf Linux installiert, gegenüber fünf auf Mainframes. Clients und Windows ist praktisch eins. Eine Cross-Plattform zwischen beiden ermöglicht es das IT-Service- Management zu automatisieren.
Linux auf Servern, um Lizenzkosten zu sparen. Windows auf den Clients, weil die Anwendungen es erfordern. – Bei Behörden ist diese Integration sehr häufig Ausschreibungsbedingung, bei Unternehmen kommt dies immer häufiger vor. Netze mit Hunderten von Linux- Servern sind inzwischen kein Problem mehr,und sie bedienen in konkreten Fällen weit über hunderttausend Benutzer an zig Tausenden von PCs. Auch die Einbeziehung von SAP in einen solchen Rahmen funktioniert reibungslos – zum Beispiel unter Suse-Linux. Linux ist erwachsen geworden und »professional«.
Die Frage ist, an welcher Stelle Anwendungssoftware benötigt wird, die von den Servern aus agiert und deshalb direkt unter Linux lauffähig sein muss. Die Automatisierung des IT-Service- Managements in einem umfangreichen Linux/ Windows-Netz und die Portierung eines dafür geeigneten Systems ist mit Hilfe von Mono und ».NET« möglich. Mono ist eine Open-Source- Entwicklungsplattform und gewissermaßen die Brücke von .NET zu Linux. So kann bei der Anwendungsentwicklung voller Gebrauch von .NET gemacht werden. Seine Plattform-überbrückenden Eigenschaften erreicht es über das übliche Konstrukt einer »Virtual Machine«.
ECMA-Ausschüsse arbeiten an deren Standardisierung wie auch an der von Verknüpfungen zwischen Mono und C++ oder an der von Class- Libraries. Das Entwicklungsteam für die Mono- Plattform um Miguel de Icaza arbeitet seit einiger Zeit für Novell. Damit ist dieses traditions-reiche Unternehmen für Netzwerkbetriebssysteme zum Sponsor der Initiative geworden.
Die Notwendigkeit des Projekts ergab sich aus Folgendem:Um ein umfangreiches Netzwerk organisatorisch am Laufen zu halten, ist ein effizientes IT-Service-Management notwendig, das auf beiden Ebenen »wie zu Hause« agiert. Im konkreten Beispiel wurde ein System für IT-Service- Management als Cross-Plattform portiert, das maximale Automatisierung der Abläufe zwischen Benutzern und Ressourcen zu realisieren versucht, um im laufenden Betrieb mit einem Minimum an Bedienungsaufwand auszukommen.
Auf Systemen mit Windows-Servern hatte sich bereits gezeigt, dass die Zahl der mit ITService- Management befassten Administratoren in Netzen mit Tausenden von Benutzern und voller Einbeziehung stetig synchronisierter SAPKonten auf einige wenige begrenzt werden konnte, wo nach alter Arbeitsweise Dutzende nötig gewesen wären.Nun lag ein aktuelles Projekt vor, das ohne einen solchen, hohen Automatisierungsgrad vom öffentlichen Betreiber nicht einmal finanzierbar gewesen wäre. Es ging um ein neu aufzubauendes, riesiges Netz in den oben schon erwähnten Dimensionen an Stelle einiger Insellösungen. Mehraufwand für Administratoren jedoch war im Budget für die laufenden Kosten nicht vorgesehen.
Mono oder JavaEinleitend evaluierten das Projektteam, das heißt, das Entwicklungsteam bei Völcker Informatik, die Frage »Mono/.NET oder Java«. Obgleich Mono zum damaligen Zeitpunkt noch ganz am Anfang stand und auch .NET erst frisch auf den Markt gekommen war,kristallisierte sich eine eindeutige Entscheidung für Mono heraus.
Java ist, wenn man sich nur auf die »Virtual Machine« verlässt, sehr langsam.Man braucht, um es vernünftig zu betreiben, relativ große und teure Server und Umgebungen.Die Performanz verbessert man dann beispielsweise durch Middleware von IBM.Ein solcher Aufwand wäre kontraproduktiv gegenüber der Idee des Ganzen.
Überhaupt war .NET als die modernere Alternative zu erkennen,wobei es dem Projektteam natürlich auch wegen seiner Vertrautheit mit der Microsoft-Welt entgegenkam. Das Projektteam konnte auf Grund seiner Untersuchungen voraussehen, dass es zu einem überwiegenden Teil in der Lage sein würde, seine Codes unter Microsoft zu entwickeln und eins zu eins unter Mono laufen zu lassen.Auch zum Beispiel Beschleunigungsmechanismen gegen-über dem Betriebssystem sind in .NET schon impliziert.
Zudem bewegte sich das Projektteam mit .NET ebenso wie mit Mono in einem offiziellen ECMA-Standard. Dabei ist Novell ebenso im Standardisierungsgremium für .NET vertreten wie Microsoft oder Hewlett-Packard.
Effizientes Arbeiten mit Mono
Schon zu dem Zeitpunkt, als das Projekt begonnen wurde, erwies sich Mono als sehr effizient, und inzwischen hat sich noch einiges getan.Man kann sich darin leicht einarbeiten und es läuft stabil. Die Portierung der existierenden Automatisierungsplattform für Windows, die in ihrer ursprünglichen, auf der Microsoft-COM-Architektur beruhenden Version rund sieben Millionen Zeilen Code umfasste,war innerhalb von neun Monaten durchgeführt. Dabei verringerte sich ihr Umfang trotz erweiterter Funktionalität auf rund drei Millionen Zeilen. Das lag vor allem daran, dass .NET viel Funktionalität als fertige Abläufe anbietet, die auf der vorherigen Basis selbst codiert werden mussten.Die Portierung der Anwendung nahm sogar den geringeren Teil der Fertigstellungszeit in Anspruch.Der neue Code wurde übrigens zu 100 Prozent in C++ geschrieben.
Aufwändiger war die Umsetzung der zum Service- Management-System gehörenden Datenbank von Microsoft-SQL-Server auf Oracle. Auch im derzeitigen Stadium von Mono ist es immer wieder einmal notwendig, partiell eigene Entwicklungen vorzunehmen. Entsprechend häufiger trat diese Situation in der damaligen Phase auf. Das erwies sich jedoch als unproblematisch und ist ja eigentlich auch der Sinn einer Open-Source. Sie stehen dann den Mono- Entwicklern als sogenannte Fixes zur Wahl. Die Unterstützung durch das Mono-Team um Miguel de Icaza mit Novell im Hintergrund war übrigens ganz hervorragend.
Das Projektteam stellte fest, dass auch schon in der frühen Version von Mono, die damals anstand - Novell war damals noch nicht eingestiegen - bereits die Funktionalität zu einem großen Teil vorhanden waren, die es für die Initiierung der Management-Dienste benötigte.
Zudem konnten die Projektverantwortlichen erkennen, dass sie selbst in der Lage sein würden, die jenigen Stellen zu ergänzen, die für die eigenen Zwecke noch fehlten. Später entwickelten das Projektteam dann an die 150 sogenannte Fixes, die es,wie das üblich ist,der Open-Source überstellte.Unter anderem waren auch die notwendigen Konvertierungsfunktionen für die Zeichensätze im Rahmen der jeweiligen Betriebsund Dateisysteme an das Deutsche anzupassen, also Umlaute und Sonderzeichen.
Es war nicht allein die Anpassungsentwicklun selbst, die Zeit kostete, sondern auch der verdoppelte Testaufwand. Auf beiden Betriebssystemen musste natürlich die Mono-Lauffähigkeit der in .NET entwickelten Komponenten getestet werden. Dabei konnte es nicht nur um die Einzelkomponenten gehen, sondern vor allem auch um Durchlauftests für die komplexen Prozessketten, die bei der Automatisierung kompletter Geschäftsprozesse auftreten.
Nach Abschluss des Projekts schätzten die Projektverantwortlichen die Reduzierung der Testzeit gegenüber einem Java-Ansatz auf 60 Prozent. Fünf bis zehn Programmierer, die sonst zusätzlich erforderlich gewesen wären, wurden so eingespart.
Von SQL auf Oracle
Der ganze Aufwand für die Portierung schlug nicht so hoch zu Buche wie die Umstellung der Datenbank von Microsoft-SQL-Server auf Oracle. Die Management-Plattform ist gewissermaßen um eine zentrale Datenbank herum gebaut. Dort liegen nicht allein die Eintragungen zu Identity-Management,Zugriffs- und Einkaufsberechtigungen, technischer und kaufmännischer Bestandsverwaltung (Assets, Lizenzen), Konfigurations- und Kostenmanagement, Software-Verteilung oder Helpdesk-Unterstützung.
Auch die Informationen für die Automatisierung der Anforderungs- und Erfüllungsprozesse werden von dort abgerufen. Im Falle einer SAP-Implementierung werden zudem die detaillierten Identitäts- und Berechtigungseintragungen aus R/3 ständig synchronisiert und mitgeführt. Was Datenbankspezialisten natürlich bekannt ist,wird bei Entscheidungsfindungen auf höherer Ebene oft unterschätzt: SQL-Abfragen erfordern eine gänzlich unterschiedliche Struktur, je nachdem, ob sie auf Microsoft-SQL-Server oder auf Oracle abgearbeitet werden sollen.
Die Auffassung »SQL ist doch SQL« wird also in der Praxis ad absurdum geführt. Da die verschiedenen Datenbanksysteme intern unterschiedlich arbeiten,kommt es darauf an, sie mit denjenigen Sprachanweisungen anzusprechen, die bei ihnen die performanteste Verarbeitung auslösen.
Ein Beispiel: Das Statement »NOT IN« ist in Microsoft-SQL-Server relativ performant in der Abarbeitung.Bei Oracle sollte an dieser Stelle ein anderes Sprachkonstrukt beispielsweise über einen »JOIN« gewählt werden. Darüber hinaus gibt es auch Ausdrücke in SQL, die das eine oder andere Datenbanksystem nicht annimmt. Am Schluss noch eine Bemerkung zu der Grundfrage »Linux oder Windows auf den Servern «: Windows erfordert auf den Servern einen geringeren Betriebsaufwand hinsichtlich der Grundkonfiguration und des Managements als Linux. Dadurch wird über die Jahre ein Teil der an Lizenzen gesparten Kosten wieder wett gemacht.
Es ist völlig klar, dass jedwede Automatisierung, die Konfigurationen und sonstige Maßnahmen von Hand einspart, erst einmal erarbeitet werden muss und dafür sehr viel Aufwand erfordert. Das gilt natürlich auch für den Ausbau von Linux. Um so sinnvoller erscheint es, in einem solchen Projekt dafür zu sorgen, dass dem Gesamtsystem ein Maximum an Automatisierung aus der Windows-Welt zur Verfügung steht und dass diese Automatisierungseffekte durch eine reibungslos funktionierende Cross-Plattform zwischen Linux-Servern und Windows-Clients zum Tragen kommen.
Matthias Bauer,
Leiter Entwicklung, Völcker Informatik
