Verstehen die Anbieter von Anwendungsservern die Bereitstellung wirklich?

Bei XebiaLabs kennen wir uns mit der automatisierten Bereitstellung von Java EE-Anwendungen aus ;-) . Eine Sache, die mir seltsam vorkommt, ist die Tatsache, dass die Leute, von denen man erwarten würde, dass sie am meisten über die Anwendungsbereitstellung wissen, nämlich die Anbieter von Anwendungsservern, das Problem überhaupt nicht zu verstehen scheinen.

In einem unserer früheren Blogs können Sie nachlesen, was wir unter dem vollen Umfang einer Java EE-Anwendungsbereitstellung verstehen. Die Kurzversion ist dies:

• Es geht um mehr als nur um die Bereitstellung einer EAR- oder WAR-Datei. Zunächst einmal kann es sich um mehr als eine dieser Dateien handeln.
• Die meisten Anwendungen benötigen auch andere Arten von Artefakten, die bereitgestellt werden müssen, z. B. statische Inhalte für den Webserver oder statische Konfigurationsdateien, die vom Java-Code beim Start gelesen werden.
• Außerdem müssen Sie Java EE-Ressourcen wie Datenquellen, JMS-Anbieter usw. konfigurieren.
• In den meisten Fällen müssen Sie auch die Middleware selbst konfigurieren. Denken Sie an die Erstellung und Konfiguration von Anwendungsserver-Clustern oder die Einrichtung von virtuellen Apache-Host-Konfigurationen.
• All dies muss in der richtigen Reihenfolge geschehen, um die Ausfallzeiten der Anwendung während der Bereitstellung zu minimieren (oder zu verhindern) und die Geschwindigkeit der Bereitstellung zu verbessern.

Was halten die Anbieter von Anwendungsservern von dieser Entwicklung?

Oracle WebLogic Server

Nun, Oracle WebLogic Server verfügt über ein Konzept, das Deployment genannt wird. Es ist das, was Sie erstellen, wenn Sie eine EAR, WAR oder EJB JAR bereitstellen. Sie können sein Verhalten durch die Bereitstellung oder Bearbeitung eines Bereitstellungsplan. Es gibt jedoch keine Möglichkeit, mehrere Java EE-Artefakte in einer Bereitstellung zu bündeln oder die Erstellung von Java EE-Ressourcen wie Datenquellen einzubeziehen.

In WebLogic gibt es auch eine so genannte Unterbereitstellung aber merkwürdigerweise hat dieses Konzept nichts mit dem einer Bereitstellung zu tun. Es handelt sich um einen Mechanismus, der dazu dient, Teile eines JMS-Systemmoduls auf bestimmte JMS-Server oder WebLogic-Server-Instanzen zu richten. Die JMS-Systemmodul-Abstraktion selbst scheint dazu gedacht zu sein, zusammengehörige JMS-Ressourcen zu gruppieren. Vielleicht hatte einer der Entwickler dieses Ding ursprünglich Deployment genannt und wurde dann an das andere Deployment erinnert, das es bereits in WebLogic gibt. Das ist natürlich alles Spekulation, aber es würde gut erklären, warum ein Subdeployment so heißt ;-)

WebLogic bietet eine Reihe von verschiedenen Bereitstellungs-APIs. Es gibt den weblogic.Deployer Kommandozeilenwerkzeug, das wldeploy Ant-Task und das Python-basierte WebLogic Scripting Tool(kurz WLST ). Von diesen ist WLST meiner Meinung nach am vollständigsten. Die Abstraktion des Dateisystems, die über der MBean-Hierarchie liegt, funktioniert ziemlich gut, so dass es in der Regel nicht allzu lange dauert, bis man herausfindet, wie man etwas erledigen kann.

JBoss Anwendungsserver

Die Bereitstellung in JBoss erfolgt über das Virtual Deployment Framework. Dabei handelt es sich um ein sehr flexibles MBean-basiertes Framework, mit dem viele verschiedene Arten von Artefakten (EARs, WARs, EJB JARs, RARs, SARs usw.) und Ressourcen (Datenquellen, JMS-Einstellungen usw.) in JBoss bereitgestellt werden können. All dies wird von einem eigenen Standard-Deployer verwaltet.

Die meisten Benutzer werden diese Deployer jedoch nicht manuell aufrufen oder gar an ihnen herumschrauben. Stattdessen legen die meisten Benutzer ihre Artefakte im Deploy-Verzeichnis des JBoss-Anwendungsservers ab und warten darauf, dass sie vom Deployment Scanner. Und dann verfolgen sie die Protokolldateien, um zu sehen, wann die Bereitstellung abgeschlossen ist.

Das große Problem dabei ist, dass die Bereitstellung keine atomare Aktion ist. Wenn Sie die Bereitstellung automatisieren, wollen Sie Ihren Webserver erst dann neu starten, wenn die Bereitstellung Ihrer neuen WAR-Datei erfolgreich war. Aber Code zu schreiben, um Protokolldateien zu verfolgen und auf das Auftauchen einer bestimmten Zeichenfolge zu warten, ist einfach, nun ja, hässlich. Eine Alternative wäre, die Eigenschaft ScanEnabled des DeploymentScanners auf false zu setzen und den spezifischen Deployer manuell aufzurufen. Dadurch wird Ihr Code nicht nur komplexer, sondern Sie müssen Ihre Dateien auch noch in das Deployment-Verzeichnis kopieren, damit JBoss sie nach einem Neustart abholen kann.

Es stellt sich also heraus, dass JBoss Application Server die Integration von Implementierungen auf seinen Servern in ein größeres Implementierungsszenario erschwert. Das ist etwas, das sie unbedingt beheben müssen, um wirklich bereit für Unternehmen zu sein.

IBM WebSphere Anwendungsserver

Wie wäre es also mit dem großen Java EE-Biest von Big Blue? Es bietet eine sehr vielseitige, transaktionale Methode zur Bereitstellung von Anwendungen und Ressourcen. Im Grunde genommen ist der wsadmin Skriptschnittstelle können Sie alle Aspekte von WebSphere steuern und es ist sehr deutlich, wenn bestimmte Dinge aktiviert wurden. Sie können Knoten explizit synchronisieren und die Jython-Methode (oder JACL, wenn Sie dazu geneigt sind), die Sie zur Bereitstellung einer Anwendung aufrufen, kehrt erst zurück, wenn sie fertig ist. Der Nachteil ist, dass es viel langsamer ist als das ähnliche WLST-Tool von WebLogic (es scheint eine Menge XML-Dateien über SOAP hin und her zu kopieren. Argh!) und die angebotene API ist ziemlich komplex (wer von uns kennt den Unterschied zwischen einem Containment-Pfad, einer Konfigurations-ID und einem Objektnamen?)

Mit WAS ist es zwar nicht möglich, die Artefakte und Ressourcen zu gruppieren, die mit einer Bereitstellung zusammenhängen, aber seine transaktionale Natur ermöglicht es Ihnen, zusammenhängende Änderungen an der Konfiguration in einem Zug zu übertragen. Es kann sogar einen Teil der Konfiguration von installierten IBM HTTP Server- oder Apache HTTP Server-Instanzen verwalten.

Auch wenn WebSphere in Bezug auf die Geschwindigkeit der Bereitstellung nicht ganz so schnell ist, so ist es doch in Bezug auf die Zuverlässigkeit der Bereitstellung unschlagbar.

Zusammenfassung

Die Anwendungsserver bieten jeweils ein unterschiedliches Maß an Unterstützung für die Komplexität von Implementierungen auf Unternehmensebene. Natürlich können sie alle die grundlegenden Java EE-Artefakte bereitstellen, aber keiner kann mehrere Artefakte in einer Bereitstellung gruppieren oder die Java EE-Ressourcen verknüpfen, die zu diesen Artefakten gehören. WebLogic ist der einzige Anwendungsserver, der versucht, zusammenhängende Ressourcen zu gruppieren (das JMS-Systemmodul und das Subdeployment). Diese Abstraktionen decken so wenig vom gesamten Umfang der Java EE-Bereitstellung ab, dass sie bei der Implementierung der automatisierten Bereitstellung tatsächlich im Weg sind.

Wiederholbarkeit und Vorhersagbarkeit sind für eine erfolgreiche Implementierungsstrategie sehr wichtig, was die Vorherrschaft von WebSphere auf dem Unternehmensmarkt erklären könnte. Und schließlich ist eine gute API-Unterstützung erforderlich, damit Sie Ihren Bereitstellungsprozess automatisieren können, und sowohl WebSphere als auch WebLogic bieten dies. JBoss lässt es in diesem Bereich ernsthaft vermissen, Twiddle reicht da einfach nicht aus!

Meine Kollegen bei XebiaLabs und ich haben in unseren früheren Jobs unzählige Skripte zur Automatisierung von Bereitstellungen geschrieben und mussten diese Probleme immer wieder umgehen. Wir haben nun Deployit entwickelt, ein Produkt zur Automatisierung der Java EE-Bereitstellung, weil wir glauben, dass die Automatisierung der Bereitstellung von größter Bedeutung ist, um die wachsende Zahl von Bereitstellungen in den heutigen Unternehmensumgebungen zu bewältigen.