Das Play Framework

das Framework für Flexibilität, Effizienz und Stabilität

Java Play Framework - The High Velocity Web Framework For Java and Scala

Play bringt die Vorteile der mächtigen Java-Tools auf leichtfüssige Art in den Web-Entwicklungsbereich.

Martin Bachmann, CTO

Da wir bei insign vermehrt das Play Framework für Weblösungen aller Art einsetzen (und verschiedene Komponenten als open-source veröffentlichen), werde ich hier in looser Folge verschiedene Aspekte dieses Frameworks vorstellen.

Everybody likes to play!

Dieser Satz gilt mit Sicherheit für unsere Entwickler: jeder in unserem Team, der mit dem Play Framework gearbeitet hat, möchte nicht mehr wechseln. In diesem Artikel zeige ich die Vor- und Nachteile auf, und versuche einen kurzen Vergleich mit anderen Frameworks zu ziehen.

Play – what?

Play Applikationen werden in Java (oder Scala) programmiert. Dabei will sich Play bewusst von klassischem, für Weblösungen zu schwerfälligen JEE (Java Enterprise Edition) abheben. Das ist aus unserer Sicht gut gelungen: Für viele Aspekte standen so erfolgreiche Frameworks wie Ruby on Rails Pate. Andererseits stehen dem Entwickler trotzdem die mächtigen Tools der Java-Welt zur Verfügung – ein wichtiger Vorteil für Enterprise-level Lösungen. Play setzt dabei eigene Akzente – z.B. mit dem Reactive Manifesto.

Play Framework – die Vorteile

  • Sehr ausgereifte Technologien: Java rsp. die Java Virtual Machine (worin auch Scala läuft) als Grundlage
  • Nahezu alle Tools und Libraries aus der Java-Welt einsetzbar
  • Trotzdem federleicht im Vergleich zum JEE-Stack
  • Web pur: Stateless wie HTTP und daher frei skalierbar
  • Performance. Ohne Kompromisse (non-blocking I/O).
  • Testing-Framework integriert
  • Typensicherheit – bis runter ins Template!
  • Compile on the fly  („hit refresh“ workflow)
  • Hype „Functional Programming“ – mit Scala schon jetzt einsetzbar

Natürlich gibt es auch Nachteile:

Type Safety erfordert Kompilieren. Kompilieren erfordert Zeit. Insbesondere bei Play, wo auch die Templates kompiliert werden, kann das spürbar werden. Dafür sind nach erfolgreicher Kompilation 80% der Bugs schon raus – während das Debugging z.B. mit PHP dann erst beginnt.

Die JVM mag Speicher. Immer. Im Gegensatz zu PHP erfordert der Betrieb einer Java-Lösung eine permanent aktive Java Virtual Machine. Wo man bei PHP unzählige kleine, unabhängige Kundenlösungen auf einen Server packen kann, sollte man für Play-Lösungen am besten einen dedizierten Server einrechnen – was sich aber ab einer gewissen Projektgrösse sowieso gehört.

Verschiedene Frameworks, gleiche Konzepte

Wer heute die am weitesten verbreiteten Frameworks vergleicht, wird feststellen, dass die meisten davon ganz ähnliche Konzepte verfolgen. Bei jungen Frameworks stand nicht selten Ruby on Rails Pate – dessen Einfachheit und Eleganz inspirierte manche Entwickler. Zu den Kernprinzipien dieser Frameworks gehören:

  • MVC-Architektur
  • DRY – don’t repeat yourself
  • Convention over configuration
  • ORM statt SQL

Die Frameworks, welche wir in der PHP-Welt einsetzen, Symfony2 oder Typo3 FLOW, folgen ebenfalls diesen Prinzipien. Als ORM setzen beide PHP Frameworks Doctrine ein – welches sich stark an JPA aus der Java-Welt orientiert (Hibernate wird denn bei Doctrine auch als Inspirationsquelle genannt). Doctrine implementiert Annotations für PHP durch Quellcode-Analyse – weil in PHP (im Gegensatz zu Annotations in Java) Annotations kein direktes Sprach-Feature sind.

FLOW geht in Sachen „Convention“ noch etwas weiter als Symfony und bietet Features wie Dependency Injection und Aspect Oriented Programming, die es in PHP direkt eigentlich (noch) nicht gibt. Um diese Magie zu ermöglichen, wird unter der Haube von FLOW auch heftig gearbeitet und PHP-Code on the fly „umgeschrieben“.

Subjektiv gesehen gehen damit diese Frameworks, insbesondere FLOW, an (rsp. je nach Anschauung auch über) die derzeitigen Grenzen von PHP. In diesem Grenzbereich ist vieles noch nicht standardisiert und nur durch Quellcodeanalyse machbar.

Das auf Java (rsp. Scala) basierende Play Framework profitiert hier von einem mächtigeren und stabilen Unterbau. Zwar wird auch und nicht zu knapp on-the-fly kompiliert (Stichwort kompilierte Templates), aber die grundlegenden Bausteine sind in Java enthalten und müssen nicht über Umwege herbeigeführt werden. Zudem stehen für viele Aufgaben im Enterprise-Umfeld wesentlich mehr und ausgereiftere Java- als PHP-Tools zur Verfügung. Wer z.B. schon mal SAP- oder Navision-Integrationen via SOAP mit PHP und mit JAVA gemacht hat, kennt die Unterschiede.

(noch) kein Play CMS

Für grössere Webprojekte kommt meist ein Content Management System als integrierende Basis für die Applikationen zum Einsatz. In der PHP-Welt gib’s dazu jede Menge Open-Source Lösungen, von Joomla über WordPress bis zum TYPO3 CMS – jedes mit seinen Vor- und Nachteilen. Bei Play gibt es noch kein gängiges, ausgereiftes Open-Source CMS.

… aber bald!

Aus diesem Grund haben wir unsere über 12-jährige Erfahrung in der CMS-Entwicklung zusammengepackt und uns entschieden, ein Open-Source CMS für das Play Framework zu entwickeln. Unser Fokus liegt dabei auf „Enterprise-readiness“, flexibler Erweiterbarkeit und einfacher Integration von Applikationen. Der Release unseres Play CMS‘ erfolgt in den nächsten Wochen.

Mehr dazu aber in einem späteren Beitrag.

Von Martin BachmannMartin Bachmann auf FacebookMartin Bachmann auf Google+Martin Bachmann auf Twitter Autoren-Webseite anschauen

Mitgründer und CTO @insigngmbh, Initiant von @android_schweiz, Android Evangelist und jetzt auch Papi.

Kommentare (2)

Pingback Liste

  1. Pingback: ESP8266 | wer bastelt mit?

  2. Pingback: Beta-Test für die Smartshopper App von Comparis | insign blog

Antworten auf Mischa Antwort abbrechen