Play2 Framework für skalierbare Webanwendungen
•
1 like•2,015 views
Play is a full-stack framework for building scalable web applications using Java and Scala. It is based on a lightweight architecture that uses minimal resources. Play allows for high productivity and the creation of real-time and asynchronous applications that can easily scale in the cloud.
Recommended
Recommended
More Related Content
Similar to Play2 Framework für skalierbare Webanwendungen
Similar to Play2 Framework für skalierbare Webanwendungen (20)
Recently uploaded
Recently uploaded (20)
Play2 Framework für skalierbare Webanwendungen
- 1. Play2 Ein flexibles Full-Stack Framework für skalierbare Webanwendungen http://www.playframework.com
- 2. Martin Grotzke inoio gmbh Twitter: @martin_grotzke Web: http://inoio.de Play2 ... für skalierbare Webanwendungen 2/18
- 3. For the impatient... “Play is a high-productivity Java and Scala web application framework [..] based on a lightweight, stateless, web-friendly architecture and features predictable and minimal resource consumption (CPU, memory, threads) for highly-scalable applications.” http://www.playframework.com/documentation/2.1.1/Home Play2 ... für skalierbare Webanwendungen 3/18
- 4. JEE Complexity Servlet API Mojarra ... JS F Facelets Seam Application Play2 ... für skalierbare Webanwendungen 4/18
- 5. Play simply Servlet API Mojarra ... JS Play Framework F Facelets Seam Application Application Architecture of the World Wide Web, Volume One, W3C, 2004 http://www.w3.org/TR/webarch/ Play2 ... für skalierbare Webanwendungen 5/18
- 6. Cloud Play2 ... für skalierbare Webanwendungen 6/18
- 7. Play Elastic Play2 ... für skalierbare Webanwendungen 7/18
- 8. Realtime Play2 ... für skalierbare Webanwendungen 8/18
- 9. Realtime Play2 ... für skalierbare Webanwendungen 9/18
- 10. Play async Play2 ... für skalierbare Webanwendungen 10/18
- 11. Productivity Play2 ... für skalierbare Webanwendungen 11/18
- 12. Productivity “On our next similar project, we'll be able to deliver 30% cost savings over the Java bid [..]. And remember, these numbers come after paying developers more.” http://thinkrelevance.com/blog/2005/12/20/bidding-projects-with-ruby-rails-take-2 Play2 ... für skalierbare Webanwendungen 12/18
- 13. Productivity 2x Martin Fowler: Is Ruby More Productive? http://martinfowler.com/articles/rubyAtThoughtWorks.html How much did Ruby improve productivity for this project? (Compared to the best mainstream tools you know.) Play2 ... für skalierbare Webanwendungen 13/18
- 14. Play full stack Akka DB WebSockets Evolutions Async I/O Persistence Java Scala sbt Templates +JSON/XML Dev, Test, Prod Asset Environments HTTP Compiler Testing Server Play2 ... für skalierbare Webanwendungen 14/18
- 15. Play demo Play2 ... für skalierbare Webanwendungen 15/18
- 16. Play reality check ● IDE Support: Continuously improved ● Hot Code Reloading: Compile time + app reload ● Async: More async drivers needed Play2 ... für skalierbare Webanwendungen 16/18
- 17. Play is... “a high-productivity Java and Scala web application framework [..] based on a lightweight, stateless, web-friendly architecture and features predictable and minimal resource consumption (CPU, memory, threads) for highly-scalable applications.” http://www.playframework.com/documentation/2.1.1/Home Play2 ... für skalierbare Webanwendungen 17/18
- 18. Questions! @martin_grotzke http://inoio.de Play2 ... für skalierbare Webanwendungen 18/18
Editor's Notes
- Herzlich Willkommen zum Vortrag über Playframework 2 Mein Name ist Martin Grotzke -> [next slide]
- Webentwicklung mit Java seit mehr als 10 Jahren 2002 noch eigenes Servlet-Framework entwickelt Später dann Struts eingesetzt, JSF, Tapestry, Wicket, Spring MVC, GWT usw , neuerdings auch mal Rails Viele Jahre in Hamburger Softwarehaus gearbeitet, Projekte: libri, buch.de, smatch.com, tchibo Vor 2 Jahren eigene Firma gegründet Eigenes Produkt mit Play1, nun 2 Projekte mit Play2 _ Soviel zu mir... _ Was mich zu Beginn interessiert: Wer hat schonmal mit Play gearbeitet? Wer ist alles Java Entwickler? Wer schon mit Frameworks wie Rails oder Django? Nun möchte ich erstmal Play mit wenigen Worten einführen...
- * High-productivity * Lightweight * Stateless * Web-friendly (RESTful) * Effizient * Sehr gut skalierbar Ist Open Source Play1: 2007, Play2: 2012, nun bei Typesafe -> Das ist der Überblick über die nächsten 50 Minuten, wobei ich den Fokus dann auf die Produktivität lege. Im Folgenden stelle ich aktuelle Herausforderungen und Lösungen von Play gegenüber. Anfang: Komplexität bei Java Webentwicklung
- * Servlets (1997): Abstraktion der Web-Konzepte, Java-freundliche API (Web-Konzepte benennen!) * Komplexität u. Einschränkungen der Servlet-API: Gefixt mit zusätzlichen Schichten/Abstraktionen, mit Web-Frameworks wie JSF, Wicket, Spring-MVC, GWT etc. * Schwächen von JSF -> Seam => neue Abstraktionen * Weitere Dimension v. Komplexität durch Specs vs. Implementierungen -> Was gibt die Spec vor, was ist “Vendor-spezifisch”? * Diese Schichten/Abstraktionen/Specs/Implementierungen muss ich als Webdev durchdringen/verstehen, d.h. Ich muss einige Hürden/Stufen nehmen, um mein Ziel zu erreichen * -> Erschwert eher als zu erleichtern Lösung von Play? Anhang - Spezifikationen und Implementierungen: JAX-RS (Jersey, CXF, RESTEasy), JAX-WS 2.0/2.1/2.2 (Metro, Axis, CXF), JSF (Mojarra, MyFaces, PrimeFaces, ICEFaces), JSP, JSTL, WebProfiles, CDI, JPA 1/2, JMS, JTA, JCA.... Specs: das Ergebnis einer Expert Group von Vertretern unterschiedlicher Firmen mit unterschiedlichen Interessen (nicht immer Developer-orientiert) Dieser Wald will beherrscht werden
- Play: * losgelöst von Servlet Spec * Nicht mehrere Schichten, keine künstlichen Abstraktionen, sondern einfache und intuitive HTTP-API * Direktes Arbeiten mit Web-Konzepten * -> Wenn ich weiß, wie das Web funtioniert, habe ich schon einen großen Teil von Play verstanden - klick - * Gute Lektüre zu Web-Architektur: “Architecture of the World Wide Web, Volume One”, W3C, 2004 (http://www.w3.org/TR/webarch/) Nächste Herausforderung: Cloud / horizontale Skalierbarkeit
- Cloud / Elastizität: statt feste Zahl Server für max. Last werden je nach Bedarf die benötigten Ressourcen alloziert * Problem: Serverseitige Sessions (User, Warenkorb, ViewState) * Requests eines Besuchers müssen vom selben App-Server beantwortet werden -> Sticky Sessions (Kopplung mit LB) * Wenn Server aus Last-Verteilung genommen wird wären dessen Sessions verloren -> Session Replikation * Problem Session Replikation: oft nur begrenzt skalierbar, sehr komplex, zerbrechlich / nicht sehr robust Fazit: serverseitige Sessions stehen im Konflikt mit Elastizität/ dynamischer Skalierung Lösung von Play, wer hätte es gedacht, ist stateless zu arbeiten
- Play ist stateless, arbeitet ohne serverseitige Sessions – dem share-nothing Prinzip folgend * Jeder Request kann von jedem App-Server bearbeitet werden * Keine Session Replikation notwendig * Es können problemlos neue Server in Last-Verteilung aufgenommen oder herausgenommen werden * Elastisch, sehr gut dynamisch und horizontal skalierbar * Session auch in Play, clientseitig gelöst (signierter Cookie) Next: Realtime Webapps
- Beispiele: RT Dashboards (Google Analytics), Google Docs, Stock Ticker, Chat-Applikationen (Live Examples: http://en.lichess.org/ , http://live.gilt.com/ , http://console-demo.typesafe.com/ , https://docs.google.com ) Was ist die Herausforderung bei Realtime Anwendungen? Die Hohe Zahl von Clients, also gleichzeitige, lange bestehende Verbindungen, statt Request-/Response Zyklen -> Stichwort WebSockets
- Früher: Request-Verarbeitung mit Thread-per-Connection Modell Problem: * ein dedizierter Thread für einen Request, dieser Thread erledigt alle Arbeit für den Request bis die Response gesendet werden kann * I/O, typischerweise synchron/blocking, auch mit diesem Thread, d.h. dieser Thread ist blockiert und idle bis I/O abgeschlossen * (Randproblem: CPU context switches) * Konsequenz: es werden soviele Threads benötigt wie gleichzeitige Requests/Verbindungen bestehen ** -> RAM für Threads ** -> Ineffizient, schwer vorhersagbarer Ressourcenverbrauch, sehr begrenzt skalierbar * Bsp Threaded: Servlets, Rails, Django, PHP Weiter: Lösung von Play * Anhang: http://engineering.linkedin.com/play/play-framework-async-io-without-thread-pool-and-callback-hell http://www.scalaloader.org/2013/03/event-sourced-architecture-travelling_14.html http://de.slideshare.net/normanmaurer/netty4 http://www.kegel.com/c10k.html http://berb.github.io/diploma-thesis/original/042_serverarch.html
- Play: Event-basiertes Modell * typischerweise 1 Thread pro CPU Core * Idee: Threads werden nicht blockiert, d.h. I/O wird asynchron gemacht, und statt zu warten kann der Thread andere Requests verarbeiten. Wenn der I/O Aufruf fertig ist kann der Thread das Ergebnis aufnehmen und die Response an den Client ausliefern * Somit ist die Anzahl paralleler Verbindung nicht so stark durch Threads/Speicher begrenzt * Ok, seit Servlet Spec 3 auch async Requests, allerdings muss das jetzt erst von den verschiedenen Frameworks integriert/angebunden werden * Andere Event-driven Server: Node.js, Twisted * Für Request-Handling / NIO: Netty (bewährte NetworkingLib) * Intern Concurrency: Akka (Event-basiertes Middleware Framework f. nebenläufige u. verteilte Systeme) Event-driven -> Unterstützung von Streaming (Chunked transfer encoding, Comet, WebSockets) Next: Productivity
- Produktivität ist in der Java EE Welt eher mittelmäßig. Eine Ursache ist Komplexität, hatten wir schon. Anderer wichtiger Punkt: es müssen viele Werkzeuge miteinander kombiniert werden, z.B. Web-Framework, Template-Engine, IoC, Persistence, Testing-Libs, Remoting, evtl. Build-Tool etc. (ggf. nicht optimal aufeinander abgestimmt) Viele kleinere Ursachen, die ein flüssiges Arbeiten erschweren Produktivität schlägt sich in Entwicklungszeit nieder: Wenn man für ein Projekt anbietet und es Mitbewerber gibt, die z.B. mit Rails unterwegs sind, weiß man schon, dass die zu geringerem Preis anbieten können. Next: Rails: Batteries included
- Rails (oder auch Django) ist also eher das Smartphone, das alles mitbringt, was man braucht, man kann schnell seine Aufgaben erledigen -> “Batteries included” - klick - Statement einer Firma, die Rails neben Java eingeführt hat und deutliche Produktivitätssteigerungen festgestellt hat. * Sie verlangen höheren Tagessatz für Rails Entwicklung, sind schneller fertig, und Entwickler bekommen auch mehr Geld Anderes Beispiel ist Thoughtworks... [switch] Anhang: Eric Knipp, Research Director at Gartner: “Many high-profile consumer Web firms are choosing Ruby on Rails to rapidly build scalable web applications. Ruby on Rails has the potential to emerge as a strong alternative platform to traditional choices based on Java and .NET for next-generation enterprise applications, as companies seek improved agility, development speed and time to market.” http://www.businessinsider.com/heres-why-ruby-on-rails-is-hot-2011-5 We pay ourselves (and our contractors) better for Rails work than Java work. This is good for everybody: Developers have more fun, make more money, and customers get better products cheaper and faster.
- Martin Fowler hat bei Thoughtworks nach der Einführung von Rails bei den Teams/Team Leads nachgefragt, wie die Einschätzung bzgl. Produktivität sei Ergebnis: Peak bei doppelter Prod. Schon Fowler weist darauf hin, dass das natürlich mit Vorsicht zu genießen ist und es so gut wie unmöglich ist, objektive Auswertungen zu erhalten. Die Aussagen deuten aber darauf hin, dass es in jedem Fall Produktivitätssteigerungen gibt. Natürlich gibt's bei Rails auch Nachteile, wir arbeiten ja aus bestimmten (und auch guten) Gründen mit Java (z.B. Typsicherheit, Performance, Wartbarkeit) Hier kommt nun Play in's Spiel: es vereint die guten Seiten von Java / Scala mit den Vorteilen von Rails oder Django
- * Es bringt alles mit, was man zum Entwickeln einer Webapp braucht * RESTful MVC Framework (Template-Engine Twirl, like ASP.NET Razor, JSON/XML) * Persistenz-Framework * Asset-Compiler / Integration von Frontend-Technologien * Akka f. Nebenläufigkeit/Remote Kommunikation (Event-basiertes Middleware Framework f. nebenläufige u. verteilte Systeme) * Guter Testing Support (versch. Ebenen) * Build-Environment sbt mit incremental compilation / continuous Testing * Integrierter HTTP Server * Flexibel : einzelne Komponenten sind austauschbar * Native Unterstützung f. Java und Scala Das war Überblick über Full-Stack, nun mehr zu Produktivitäts-Features anhand von Source-Code
- Auch bei Play gibt es noch Potential: IDE Support (bei Eclipse) ist ok aber nicht perfekt – viel Entwicklung (IDEA Ultimate besser) Hot-Code Reloading: mit vielen Templates können die sich bemerkbar machen. Alternativen: Scalate (SCAML, Jade, Mustache), Jade, Velocity Async: Optimally backends would be accessed using NIO Check: async http client (play comes with a great wrapper for ning async http client) Check: Reactive Mongo JDBC: blocking interface - API, Driver, ConnPool, ORM/Libs Many other drivers are also blocking (SolrJ) Experimental non-blocking driver: adbcj, async-mysql-connector
- Um die Vorteile von Play noch einmal kurz zusammenzufassen... * Einfach/leichtgewichtig – nur 1 Framework, intuitive u. ausdrucksstarke HTTP API (web-friendly, RESTful) * Scalable – Stateless / sehr gut horizontal skalierbar / Elastisch / keine Probleme mit Elastizität * Effizient – durch async/non-blocking Request-Handling können viele Clients parallel bedient werden (RT) * Productive – hat sich viel von Rails/Django abgeschaut und kombiniert das mit vielen Compile-Time Checks - v.a. erwähnenswert Full-Stack, Hot-Code Reloading, kompilierte Templates+Routes, Evolutions, Integration Frontend-Technologien Damit vielen Dank für die Aufmerksamkeit, noch ein paar Minuten für Fragen