Suche
EnterpriseTales

Java EE 8 meets MVC: ein Blick in die Kristallkugel

Lars Röwekamp, Arne Limburg

©Shutterstock/imagedb.com

Für viele überraschend hat Oracle für Java EE 8 einen neuen Java Specification Request zur Ergänzung des aktuellen Web-Development-Stacks angekündigt: MVC 1.0. Obwohl bisher kaum Details zum neuen API bekannt wurden, spaltet der JSR 371 schon jetzt die Community. Grund genug, einen Blick hinter die Kulissen zu wagen.

Ist es sinnvoll, bei all den existierenden Web-MVC-Frameworks ein weiteres zu erfinden? Und wenn ja, muss es dann unbedingt in die Java-EE-Spezifikation einfließen? Schließlich gibt es doch JSF als die Lösung, wenn es um die Umsetzung von Webanwendungen im standardisierten Java-Enterprise-Umfeld geht.

Fakt ist, dass im Rahmen einer Java-EE-8-Umfrage von Oracle mehr als 60 Prozent aller Befragten der Meinung waren, dass der Standard dringend ein „Action-based“ Web-MVC-Framework benötigt. Lediglich 26 Prozent der befragten Teilnehmer waren der Meinung, dass ein solches Framework als De-facto-Standard bereits existiert. Gemeint war damit in den meisten Fällen Spring MVC.

Action- vs. Component-based

Um die aktuelle Diskussion rund um MVC 1.0 [1] besser einordnen zu können, lohnt sich ein Blick auf den wirklich guten Blog-Eintrag „Why another MVC?“ [2] von Ed Burns, seines Zeichens Co-Lead der JSF-Spezifikation. Burns beschreibt darin die wesentlichen Unterschiede zwischen „Component-based“ (JSF) und „Action-based“ (u. a. Spring MVC) Webframeworks.

Vereinfacht gesprochen abstrahiert JSF mit seinem komplexen Lifecycle von dem im Web allgegenwärtigen HTTP-Request/-Response-Modell und nimmt so dem Webentwickler eine Menge an lästigen Aufgaben ab, z. B. Request Parameter Mapping, Konvertierung, Validierung, Navigation und Rendering. UI-Komponenten, wie z. B. Eingabefelder oder Buttons, erzeugen Events, die zu einer Änderung des Modells führen. Die Kehrseite: Der Entwickler verzichtet auf einen Großteil an Freiheiten, insbesondere in Bezug auf das zu rendernde HTML. Das gilt zumindest, wenn der Lifecycle nicht explizit an die eigenen Bedürfnisse angepasst wird. Komponentenbasierte Frameworks wie JSF ergeben somit immer dann Sinn, wenn man von HTML/CSS/JS und HTTP abstrahieren und einen Satz von vordefinierten UI-Komponenten – inklusive UI-Logik – einsetzen möchte. Pixelgenaues HTML-Design mit JavaScript-Voodoo dagegen stellt bei dieser Art von Frameworks eine nicht zu unterschätzende Herausforderung dar.

Klassische „Action-based“ Frameworks dagegen gehen genau den umgekehrten Weg und stellen den HTTP-Request/-Response in den Fokus. Der eingehende Request wird auf einen Controller dispatched, der wiederum eine oder mehrere Actions triggert. Natürlich übernimmt auch hier das Framework einen großen Teil der Standardaufgaben, versucht dabei aber nicht von den zugrunde liegenden Technologien zu abstrahieren und erlaubt somit deutlich mehr Freiheiten in Hinblick auf Nutzung von HTTP, HTML und Friends – inklusive WebSockets und REST.

MVC 1.0 Sneak Preview

Bisher gibt es noch kaum Informationen darüber, wie das MVC-Framework bzw. das zugehörige API im Detail aussehen wird. Es gilt allerdings als sicher, dass sich das Framework stark an Jersey MVC [3] und Spring MVC [4] orientieren wird. Ein MVC-1.0-Controller könnte dabei in Anlehnung an Jersey MVC, wie in [2] von Ed Burns beschrieben, in etwa wie in Listing 1 aussehen. Ebenfalls als sicher gilt, dass MVC und JSF zukünftig einige Gemeinsamkeiten haben werden:

  • CDI Beans zur Repräsentation des Modells
  • Bean Validation als Validierungsmechanismus
  • Unifed EL als Verbindung zwischen Modell und View
  • JSP und Facelets als View Declaration
 @Path("/")
@Singleton
@Template
@Produces("text/html;qs=5")
@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Bookstore {

  private final Map<String, Item> items = new TreeMap<String, Item>();
  private String name;

  public Bookstore() {
    setName("Czech Bookstore");
    getItems().put("1", new Book("Svejk", "Jaroslav Hasek"));
    getItems().put("2", new Book("Krakatit", "Karel Capek"));
    getItems().put("3", new CD("Ma Vlast 1", "Bedrich Smetana", 
      new Track[]{
      new Track("Vysehrad",180),
      new Track("Vltava",172),
      new Track("Sarka",32)}));
  }
 
  @Path("items/{itemid}/")
  public Item getItem(@PathParam("itemid") String itemid) {
    Item i = getItems().get(itemid);
    if (i == null) {
      throw new NotFoundException(Response
        .status(Response.Status.NOT_FOUND)
        .entity("Item, " + itemid + ", is not found")
        .build());
    }
 
    return i;
  }
 
  @GET
  @Produces({MediaType.APPLICATION_XML, 
      MediaType.TEXT_XML, MediaType.APPLICATION_JSON})
  public Bookstore getXml() {
    return this;
  }
 
  public long getSystemTime() {
    return System.currentTimeMillis();
  }
 
  public Map<string, item=""> getItems() {
    return items;
  }
 
  public String getName() {
    return name;
  }
 
  public void setName(String name) {
    this.name = name;
  }
}

Das Ende von JSF?

Was genau bedeutet die neue MVC-1.0-Spezifikation nun aber für die Zukunft von JSF? Wird JSF zum Auslaufmodell und somit „Old School“? Sicherlich nicht. Wie bereits beschrieben, handelt es sich bei „Component-based“ und „Action-based“ Webframeworks einfach um zwei unterschiedliche Ansätze mit entsprechend unterschiedlichen Zielgruppen, von denen die eine in der Vergangenheit durch Java EE nur sehr unzureichend unterstützt wurde.

Bevor klar wurde, dass man MCV 1.0 in eine eigene Spezifikation auslagern würde, gab es übrigens Überlegungen, JSF einen zweiten Lifecycle zu spendieren, der das „Action-based“ Pattern realisieren sollte. Diese Überlegungen wurden allerdings schnell wieder verworfen, da die MVC-Fanfraktion eine nicht unerhebliche Aversion gegen JSF hegt und somit MVC 1.0 von Anfang an zum Scheitern verurteilt gewesen wäre. Und auch die Idee, MVC als Erweiterung von JAX-RS zu spezifizieren, wurde nicht weiter verfolgt, um so den REST-Ansatz nicht durch UI-lastige Zusätze zu verwässern.

Fazit

Mit der neuen MVC-1.0-Spezifikation möchte man in Java EE 8 der Tatsache Rechnung tragen, dass das derzeitige Java-EE-Webframework JSF nur bedingt auf die Bedürfnisse moderner Webanwendungen mit Fokus auf HTML5, JavaScript, CSS 3, REST usw. eingeht. Der in JSF gegebene komponentenbasierte und eventgetriebene Ansatz inkl. der damit einhergehenden Abstraktion von HTTP und HTML vereinfacht zwar viele Aufgaben der Webentwicklung, nimmt aber gleichzeitig auch einen gewissen Grad an Kontrolle – insbesondere im Bereich der HTML-Generierung.

Mit MVC 1.0 und JSF werden zukünftig somit zwei Webframeworks mit unterschiedlichen Zielgruppen parallel Bestandteil von Java EE werden, was in der Community nicht nur auf Gegenliebe stößt. Nach bisherigem Stand der Planung wird JSF in Zukunft auch Möglichkeiten zur direkten Integration von MVC 1.0 bieten. Wie genau diese aussehen wird, steht allerdings noch in den Sternen.

Bei all den aktuellen Diskussionen pro bzw. kontra MVC 1.0 sollte nicht vergessen werden, dass die meisten Entwickler, die sich bewusst für Spring MVC oder Jersey MVC entschieden haben, mit ihrer Wahl recht zufrieden zu sein scheinen. Es wird also spannend zu beobachten, inwieweit das bereits verlorene Feld „Action-based MVC“ durch den Standard zurückerobert werden kann. In diesem Sinne: Stay tuned.

Aufmacherbild: Close-up of a businessman looking at a crystal ball von Shutterstock / Urheberrecht: imagedb.com

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Arne Limburg
Arne Limburg
Arne Limburg ist Softwarearchitekt bei der open knowledge GmbH in Oldenburg. Er verfügt über langjährige Erfahrung als Entwickler, Architekt und Consultant im Java-Umfeld und ist auch seit der ersten Stunde im Android-Umfeld aktiv.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.