Play2Ein flexibles Full-Stack Frameworkfür skalierbare Webanwendungen        http://www.playframework.com
Martin Grotzke                                           inoio gmbh                              Twitter: @martin_grotzke ...
For the impatient...            “Play is a high-productivity Java and Scala            web application framework [..] base...
JEE Complexity                                           Servlet API                                 Mojarra ...          ...
Play simply                     Servlet API             Mojarra ...              JS            Play Framework             ...
CloudPlay2 ... für skalierbare Webanwendungen           6/18
Play ElasticPlay2 ... für skalierbare Webanwendungen         7/18
RealtimePlay2 ... für skalierbare Webanwendungen         8/18
RealtimePlay2 ... für skalierbare Webanwendungen         9/18
Play asyncPlay2 ... für skalierbare Webanwendungen        10/18
ProductivityPlay2 ... für skalierbare Webanwendungen         11/18
Productivity“On our next similar project, well be able to deliver 30% cost savings overthe Java bid [..]. And remember, th...
Productivity                                                                                        2xMartin Fowler: Is Ru...
Play full stack                                               Akka      DB                                 WebSockets     ...
Play demoPlay2 ... für skalierbare Webanwendungen    15/18
Play reality check ●   IDE Support: Continuously improved ●   Hot Code Reloading: Compile time + app reload ●   Async: Mor...
Play is...            “a high-productivity Java and Scala web            application framework [..] based on a            ...
Questions!                 @martin_grotzke                 http://inoio.dePlay2 ... für skalierbare Webanwendungen   18/18
Upcoming SlideShare
Loading in …5
×

Play 2 - ein flexibles Full-Stack Framework für skalierbare Webanwendungen, JAX 2013

1,775 views
1,673 views

Published on

The demo code is available on github: https://github.com/magro/play2-java-computer-database

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,775
On SlideShare
0
From Embeds
0
Number of Embeds
25
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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
  • Play 2 - ein flexibles Full-Stack Framework für skalierbare Webanwendungen, JAX 2013

    1. 1. Play2Ein flexibles Full-Stack Frameworkfür skalierbare Webanwendungen http://www.playframework.com
    2. 2. Martin Grotzke inoio gmbh Twitter: @martin_grotzke Web: http://inoio.dePlay2 ... für skalierbare Webanwendungen 2/18
    3. 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/HomePlay2 ... für skalierbare Webanwendungen 3/18
    4. 4. JEE Complexity Servlet API Mojarra ... JS F Facelets Seam ApplicationPlay2 ... für skalierbare Webanwendungen 4/18
    5. 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. 6. CloudPlay2 ... für skalierbare Webanwendungen 6/18
    7. 7. Play ElasticPlay2 ... für skalierbare Webanwendungen 7/18
    8. 8. RealtimePlay2 ... für skalierbare Webanwendungen 8/18
    9. 9. RealtimePlay2 ... für skalierbare Webanwendungen 9/18
    10. 10. Play asyncPlay2 ... für skalierbare Webanwendungen 10/18
    11. 11. ProductivityPlay2 ... für skalierbare Webanwendungen 11/18
    12. 12. Productivity“On our next similar project, well be able to deliver 30% cost savings overthe Java bid [..]. And remember, these numbers come after payingdevelopers more.”http://thinkrelevance.com/blog/2005/12/20/bidding-projects-with-ruby-rails-take-2 Play2 ... für skalierbare Webanwendungen 12/18
    13. 13. Productivity 2xMartin 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. 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 ServerPlay2 ... für skalierbare Webanwendungen 14/18
    15. 15. Play demoPlay2 ... für skalierbare Webanwendungen 15/18
    16. 16. Play reality check ● IDE Support: Continuously improved ● Hot Code Reloading: Compile time + app reload ● Async: More async drivers neededPlay2 ... für skalierbare Webanwendungen 16/18
    17. 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/HomePlay2 ... für skalierbare Webanwendungen 17/18
    18. 18. Questions! @martin_grotzke http://inoio.dePlay2 ... für skalierbare Webanwendungen 18/18

    ×