Dropwizard als REST-App-Server

Inhaltsverzeichnis

Das Java-Framework Dropwizard soll mit den Anforderungen der Online-Welt im Vergleich zu alteingesessenen App-Servern deutlich besser zurecht kommen. Dabei greift es auf eine Fülle an Open-Source-Projekten zurück.

Die Systeme und Frameworks, die Entwickler bei ihrer Arbeit benutzen, sind stark von ihrer Arbeitsumgebung geprägt. Verbreitete Application Server wie WildFly (ehemals JBoss), Tomcat oder GlassFish sind ursprünglich als Container für große, komponentenbasierte Java-EE-Anwendungen konzipiert worden. Dem Container kommt dabei die Aufgabe zu, der in ihm betriebenen Anwendung sämtliche Infrastruktur bereitzustellen: beginnend bei Datenbank-Verbindungen und verteilten Transaktionen bis hin zum Aufbau von hochverfügbaren Clustersystemen.

Software-Systeme sollten sich nach der in den 90er Jahren des letzten Jahrhunderts vorherrschenden Ansicht aus separat entwickelbaren Komponenten zusammensetzen, wodurch eine hohe Modularisier- und Wiederverwendbarkeit angestrebt wurde. Hardware war teuer und Virtualisierungsoptionen für viele Systeme nicht wie heute verfügbar, weshalb es notwendig schien, mehrere Anwendungen in einer Application-Server-Instanz betreiben zu können, auch wenn oftmals nur eine einzige Anwendung pro Server betrieben wurde. Entweder um zu verhindern, dass sich die Anwendungen gegenseitig die Ressourcen strittig machten, oder weil der Einfachheit halber alle Funktionen in einer Applikation gebündelt wurden. Entwicklung der Anwendung und der Betrieb des Application Server samt der Anwendung wurden durchgängig als getrennte Aufgaben betrachtet, die von unterschiedlichen Gruppen wahrgenommen werden. Die damals verbreitete Trennung der Tätigkeiten prägte die Architektur der Application Server und schlug sich auch in der Java-EE-Spezifikation mit ihren sieben unterschiedlichen Rollen nieder (Java Platform, Enterprise Edition [Java EE] Specification, v7, EE.2.11 Platform Roles). Eine solche Aufteilung konnten sich vor allem große Organisationen leisten.

Mit der Veränderung der IT-Landschaft durch das Internet kamen Anforderungen an Application Server auf, für die sie ursprünglich nicht gedacht waren, da es bei vielen Anwendungen vorrangig um die schnelle Auslieferung von Webseiten oder mit zunehmenden Maß um die Beantwortung von REST-Anfragen ging. Anforderungen wie maximale Transaktionssicherheit oder die Unterstützung möglichst vieler Standards spielen in diesem Umfeld eine untergeordnete Rolle. Ein Übriges tat die Entstehung der DevOps-Bewegung, die die Trennung von Entwicklung und Betrieb aufhebt und so das Separieren von Server-Management und Anwendungsentwicklung aufzulösen versucht.

Kurzum, herkömmlich Application Server können die Anforderungen der Online-Welt zwar auch, aber nicht optimal erfüllen, da sie für andere Anforderungen konzeptioniert wurden. Darüber hinaus lassen sich viele ihrer Funktionen wie Skalierbarkeit und Clustering heute architektonisch auch anders erreichen.

Aus dem Grund sind in den letzten Jahren viele neue, leichtgewichtige Application Server wie Netty, Play, Akka, Grizzly, Spring Boot oder Vert.x entstanden, die entweder ein einfacheres Entwicklungsmodell oder Erleichterungen in Sachen Konfiguration, Deployment und Betrieb zusammen mit der vorrangigen Ausrichtung auf Kommunikation per HTTP bieten. Der Autor hat an dieser Stelle bewußt den Begriff Application Server gewählt, da alle genannten Projekte sich dadurch auszeichnen, dass sie die Infrastruktur für die Entwicklung und den Betrieb von Anwendungen bereitstellen und Entwickler sich vorrangig auf die Anwendungslogik konzentrieren können.

Auftritt Dropwizard

Einer dieser alternativen Application Server ist der speziell auf RESTful-Webservices ausgelegte Dropwizard. Er hat seinen Ursprung im US-amerikanischen Social Network Yammer. Dasselbe gilt für die bekannte Metrics-Bibliothek, mit der sich anwendungsspezifische Metriken erheben lassen.

Dropwizard zeichnet sich durch eine gelungene Mischung aus Pragmatismus und hoher Performance aus. Dadurch erlaubt er eine effiziente Entwicklung und bietet Lösungsansätze für die größten Probleme im Lebenszyklus einer Anwendung, beginnend von der Entwicklung über das Deployment bis hin zu Konfiguration und Betrieb. Statt alle Komponenten selbst zu entwickeln, bauen die Dropwizard-Entwickler konsequent auf bewährte Open-Source-Projekte, die eine hohe Verbreitung genießen. Als Servlet-Engine kommt Jetty zum Einsatz, RESTful-Webservices werden mit der JAX-RS-Referenzimplementierung Jersey und Jackson für die Serialisierung realisiert. Google Guava dient als allgemeine Ergänzung des JDK. Diese Aufzählung ließe sich mit Joda-Time für Datums- und Zeitberechnungen fortsetzen und über Liquibase für das Datenbank-Management weiterführen.

Solch verbreitete Komponenten einzusetzen reduziert sowohl Entwicklungszeit als auch Einarbeitungsaufwand, da Antworten zu vielen Standardfragen im Internet leicht zu finden sind. Durch den Verzicht auf umfangreiche Eigenentwicklungen kann sich das Team hinter Dropwizard auf die optimale Integration aller Komponenten konzentrieren.

Das Deployment einer Dropwizard-Anwendung erfolgt in Form eines Fat Jars, das während des Builds aus allen benötigten Bibliotheken erzeugt wird. Dadurch ist eine Bereitstellung grundlegend durch Kopieren des Fat Jars auf den Zielserver möglich. Beim Start der Main-Klasse startet Dropwizard eine eingebettete Jetty-Instanz, womit die Anwendung einsatzbereit ist.

Eine Dropwizard-Anwendung lässt sich mit einer YAML-Datei konfigurieren, die Jackson beim Start auf eine POJO-Klasse abbildet, die sich wiederum zusätzlich durch Bean Validation validieren lässt. Schlägt diese fehl, startet die Dropwizard-Anwendung nicht. Zur Überwachung der Applikation kann der Nutzer die erwähnte Metrics-Bibliothek integrieren, mit der es ihm möglich ist, Health-Checks und diverse Performance-Messungen zu realisieren.