Seite 2: JBoss: Der Spezialist für Open-Source-Middleware

Inhaltsverzeichnis

Vom Tool zur Strategie

Doch für das Management waren darüber hinaus Support und Wartung der Plattform entscheidend. Da kam es zupass, dass JBoss den gesamten Applikations-Lebenszyklus unterstützten will. Zum Beispiel offeriert das Unternehmen mit dem JBoss Operation Network (ON) eine Management- und Monitoring-Plattform, die IT-Abteilungen nutzen können, um Updates und Patches einzuspielen, die Performance zu kontrollieren und Hilfe etwa beim Starten und Stoppen von Applikationen zu erhalten.

"Bedeutsam war und ist aber auch", so IT-Leiter Düster, "dass wir dank JBoss 'Beauty-Contests' durchführen können." Darunter versteht er den Wettbewerb zumeist junger Unternehmen, die sich darum bemühen, einzelne Funktionsblöcke der von der Norisbank-IT definierten Geschäftsprozesse zu entwickeln. "Wir nutzen ein modulartiges Design und schreiben einzelne Funktionsblöcke aus", sagt der IT-Chef, "und schauen dann, was die Firmen daraus machen."

Ein solches Vorgehen sei nur möglich, wenn der Markt genügend Ressourcen und Kompetenz hergebe. In einem vergleichsweise geschlossenen Umfeld, wie es mit IBM, BEA und Oracle-Produkten einhergehe, seien solche Beauty-Contests geradezu ausgeschlossen, argumentiert auch Entwicklungsleiter Pouatcha. Doch der JBoss-Applikations-Server und die JBoss-Community orientiere sich strikt an Standards, sodass der Markt genügend Potenzial offeriere. um ein verteiltes, modulares Entwickeln zu erlauben.

Bei der Norisbank gipfelt diese Sichtweise in dem Strom-Modell, wie IT-Leiter Düster das Hosting der JBoss-basierten Anwendungen nennt. "Wir übergeben dem Rechenzentrum, einem Dienstleister quasi eine Black-Box", erläutert er. Der Provider müsse sich dank Standards um weniger Parameter kümmern. Dank Open-Source fielen auch Lizenzfragen flach. "Und wir zahlen nur Betriebswirtschaft". Schließlich habe für JBoss gesprochen, dass mit einer höheren Qualität zu rechnen war, erläutern Düster und Pouatcha. Bei BEA und anderen Anbietern kommerzieller Produkte landeten die Fehler auf einer Offenen-Posten-Liste und würden, wenn überhaupt, mit einem nächsten Release behoben. Hingegen arbeitet die Open-Source-Community fehlergetrieben. Fehler in der Software würden aufmerksamer verfolgt sowie schneller und gründlicher bereinigt.

Letztlich sprachen auch für die Geschäftsleitung der Norisbank so viele Gründe für JBoss, dass sie eine strategische Entscheidung zugunsten der Open-Source-Plattform fällten – zu Lasten der kommerziellen Konkurrenz von BEA. "Seither heißt es bei uns: Null Bea", sagt Düster.

Knock-out für BEA Systems

Laut JBoss-CTO Labourey fallen in Migrationsprojekten meistens BEA-Applikations-Server der JBoss-Einführung zum Opfer. Analyst Monson-Haefel bestätigt diese Behauptung. Der Grund liegt seiner Ansicht nach darin, dass sich Applikations-Server in ihrem Funktionsumfang kaum noch unterscheiden. "Alles ein Abwasch", sagt er. Oracle und IBM aber können eine Menge Tools darauf satteln und diverse Pakete schnüren. BEA habe hier noch immer einen Nachholbedarf; der Anbieter werde eben als Hersteller eines Applikations-Servers wahrgenommen. Und im Vergleich dazu koste JBoss weniger, sei einfacher zu implementieren und biete mehr Service.

Darüber hinaus gibt es laut Labourey und Monson-Haefel keinen typischen JBoss-Kunden. "Wir adressieren mit dem Applikations-Server den Massenmarkt", sagt der CTO, "haben aber keine spezifischen Lösungen für Nischen. Das unterscheidet unsere Produkte von denen kommerzieller Mitbewerber." Darüber hinaus brauche ein Mittelständler häufig gezielte Lösungen für ein Problem. Passe JBoss dort hinein, sei die Entscheidung schnell gefällt, ohne großes "Management-Bla-Bla". In große Unternehmen gelange JBoss häufig durch die Entwickler, die zusätzliche Lösungen zu existierenden SAP-, IBM- oder Oracle-Lösungen bauen. Während dem Einsatz kommerzieller Software oft eine strategische Entscheidung vorausgeht, quasi Top-down, passiert eine JBoss-Implementierung häufig bottom-up. Bei vielen kleineren JBoss-Lösungen falle schließlich ins Gewicht, dass Open-Source kostengünstiger sei und das begründe dann eine strategische Richtlinie.

Dass am Anfang in der Regel nicht die Frage "quelloffen oder kommerziell" steht, fällt auch dem Analysten Monson-Haefel auf. "Open-Source ist heute immer Bestandteil eines IT-Cocktails und wird bei anstehenden Entscheidungen immer mit begutachtet. Das hat sich wirklich geändert. Denken Sie doch einmal daran, wie das noch vor zwei, drei Jahren war!"

Anwender, die auf Open Source setzen, müssten sich hingegen fragen, wie lebendig die hinter einem Projekt stehende Community ist, welche Lizenzpolitik verfolgt wird und in welcher Form eine Organisation wie JBoss Inc. Service und Support bieten kann. Die erste Frage beantwortet der Burton-Group-Analyst gleich selbst: "Apache und JBoss Application Server gehören zu den lebendigsten Projekten überhaupt – eine sehr sichere Sache für die Anwender."

Verankerung in der Community

Darüber hinaus trage JBoss Inc. selbst wesentlich zur Weiterentwicklung der Produkte bei, führt der europäische Geschäftsführer Labourey aus. Zum Beispiel stammten rund 60 Prozent des von der Apache Foundation gepflegten Webservers Tomcat von JBoss, dessen frisch angekündigter JBoss Web Server 1.0 dann wiederum auf Tomcat und der Apache Portable Runtime (APR) basiert. Der aktuell führende Entwickler Remy Maucherat ist mittlerweile bei JBoss angestellt. Den Vorteil fasst JBoss-Deutschland-Chef Hartwig zusammen: "Die Apache-Community bleibt erhalten, aber Innovationsgeschwindigkeit und Qualität haben sich erhöht, und unseren Kunden sichert es den Support."

Auch das Persistenz-Framework Hibernate gehört seit mehr als zwei Jahren zum JBoss-Portfolio. Laut einer Analyse von Monson-Haefel aus dem Dezember 2005 gehört es zu den führenden "Rebellen-Frameworks", als Alternative und Ergänzung zur J2EE. Tatsächlich hat Hibernate einen wesentlichen Anteil an der Gestaltung von Enterprise Java Beans 3.0. Wie der Burton-Group-Analyst verdeutlicht, entspricht Hibernate dem kleinsten gemeinsamen Nenner für die Persistenz von relationalen Daten, eignet sich aber auch für objekt-orientierte Datenbanken, XML und Directories wie das Lightweight Directory Access Protocol (LDAP).

Damit sind zwei Arten erläutert, wie bei JBoss technische Entwicklungen laufen: "Erstens: Wir starten ein Inhouse-Projekt wie beim Application Server, dem Cache-Werkzeug und dem Portal", fasst CTO Labourey zusammen. "Zweitens: Wir schauen, welche Open-Source-Projekte es gibt, die unser Angebot sinnvoll ergänzen, und versuchen es einzugliedern, wie bei Apache, Hibernate, Rules und dem Business Process Management. Das ist jedoch weder Kapern noch Kidnapping: Wir kaufen unter Umständen einen Markennamen oder probieren, die Entwickler zu überzeugen, bei uns zu arbeiten." Letzteres bezeichnet Analyst Monton-Haefel übrigens als "Silver-Bullet-Strategie."

So stand offenbar zur Diskussion, nicht einen eigenen Enterprise Service Bus (ESB) auf den Weg zu bringen, sondern Bestandteile des Open-Source-ESB Celtix vom irischen Hersteller Iona zu nutzen. "Wir haben einen ganz ähnlichen Fokus", verrät Labourey. Und gänzlich ausgeschlossen sei es nach wie vor nicht.

Eine dritte Möglichkeit besteht in simplem Einkaufen von bislang proprietären produkten. Der unlängst vorgestellte Transaktionsmonitor JBoss Transactions beispielsweise stammt von Arjuna, einem Spin-off von Hewlett Packard.

Das leidige Lizenzproblem

Ungeachtet der Zertifizierung von Partnern ist die Entwicklung mit der JBoss Enterprise Middleware Suite (JEMS) frei. Die JBoss-Software unterliegt nicht wie der Linux-Kernel und viele Linux-Tools der GNU General Public License (GPL), sondern der Lesser GPL (LGPL), unter der zahlreiche Bibliotheken – darunter auch die zentrale C-Library auf Linux-Systemen – stehen und die das binäre Linken von nicht-GPL-, sogar proprietärem, Code mit LGPL-Code erlaubt.

Seit September des vergangenen Jahres läuft eine heftige Diskussion über die die LGPL-Lizenz für den Application Server. Dem früheren JBoss-Projekt-Mitarbeiter und JBoss-Inc.-Partner Rickard Oeberg fiel nun auf, dass er als Mitentwickler zentrale Quelltext-Fragmente im JBoss Application Server sein Eigen nennen kann. Denn im Gegensatz zur Apache Software Foundation (ASF), bei der der Contributor das Copyright an die ASF übergibt, behält bei der LGPL jeder einzelne Contributor sämtliche Rechte an seinen Code-Fragementen.

Rickard, der offenbar vor Jahren unfreundlich aus dem Projekt herausmanövriert worden war, will nun, dass all seine Sourcen von der LGPL in die GPL umgewandelt werden. Möglich wäre das für alle zukünftigen Versionen – bisherige Releases des Application Server wären nicht betroffen, da die Lizenz nicht rückwirkend geändert werden darf. Mittlerweile ist es allerdings ruhig geworden um diese Auseinandersetzung. (odi)