State-of-the-art J2EE: was ist sinnvoll

[mschlegel]

Hallo alle zusammen.

Nehmen wir mal an wir haben ein grüne Wiese auf der wir uns austoben können um eine mittlere bis große Webanwendung in Java zu basteln.

Um dies zu realisieren gibt es ja nun diverse Ansätze

• EJB
• Spring
• JSF
• JSF mit Facelets
• Portlets
• JSP mit Spring MVC und Webflow
• JSF mit Spring
• ...

Für mich persönlich fällt EJB schonmal raus da eine verteile Datenbank selten nötig ist und das ganze sich schön leichtgewichtig mit Spring machen lässt (meine Meinung).

Aber wie schaut es jetzt mit der Präsentationsschicht aus?
JSP allein ist heutzutage nicht mehr ausreichend, weswegen Sun JSF entwickelt hat und mir daran besonders gefällt dass es Komponenten von Drittanbietern gibt. Spring MVC hängt sich ja faktisch nur hinter die JSP und bietet den ApplicationContext an der dann über EL angesprochen werden kann.
Facelets machen Sinn da man einen normalen Webdesigner mit der Layout beauftragen kann und dann nur die JSF-Logik anhängt.

Daher wäre meine Frage, welche Kombination ist aus heutiger Sicht sinnvoll einzusetzen und später dann noch gut wartbar?

Es wäre doch schön das Layout von dem angesprochenen Webdesigner entwickeln zu lassen. Komponenten von Drittanbietern (JSF) zu verwenden und im Hintergrund Spring laufen zu haben wo man einfach über eine Konfigurationsdatei eine Testkontext und einen Produktionskontext einhängen kann.

Oder hab ich hier etwas völlig falsch verstanden? Denn mein Wissen in all diesen Gebieten ist noch nicht sehr ausgeprägt und ich möchte mich in naher Zukunft in die richtige Richtung weiterbilden (es gibt Blogs im Netz die behaupten JSF 2.0 wird JSP ablösen => JSP = tot).

 

[Thomas Darimont]

Hallo,

Für mich persönlich fällt EJB schonmal raus da eine verteile Datenbank selten nötig ist und das ganze sich schön leichtgewichtig mit Spring machen lässt (meine Meinung).

EJB hat (in der alten <= 2.x wie auch in der neuen >= 3.x Fassung)
nichts mit verteilten Datenbanken zu tun. Das Konzept auf das
du hier anspielst ist allgemein die Verteilung von Komponenten /
Services.

Weiterhin ist die Verteilung bei EJB zwar möglich jedoch nicht
erforderlich (Stichwort LocalClientView).

Außerdem ist IMHO EJB in Version 3.0 bzw. 3.1
(http://www.tutorials.de/forum/java-...sicht-ueber-die-neuen-features-ejb-3-1-a.html)
mittlerweile sehr brauchbar als Backend für so ziemlich jede Form von Serverseitiger Anwendung.

Die alten Argumente aus der "grauen" Vorzeit (<=2.x) zählen IMHO heute nicht mehr. Auch mit EJB lässt
sich mittlerweile schnell und einfach Software entwickeln.

Letzten Endes schreibt man bei EJB ebenso wie bei Spring eigentlich nur noch seine POJOs mit POJIs hin und
gibt ein paar Annotationen an (oder Konfiguriert das ganze via XML). Zumindest von diesem Aspekt her unterscheidet
sich die Entwicklung mit "reinem" EJB (>=3.x) nicht allzusehr von der mit Spring.

Der Vorteil von Spring liegt hier ganz klar beim Framework Aspekt. Durch die hervorragende Unterstützung in allen Möglichen
Bereichen (Security, Persistenz, Web, Jobs / Scheduling etc.) muss man neben ein wenig Konfiguration kaum noch technischen
Code schreiben und kann sich ganz auf die Anwendung konzentrieren. EJB kann in Kombination mit JPA und den JEE Apis
zwar auch relativ einfach sein, jedoch muss man für Funktionalität die etwas vom Standard abweicht etwas mehr in die
Trickkiste greifen als bei Spring.



Aber nun zum Vorschlag.


Bei der Wahl der Technologie kommt es bei der Realisierung natürlich immer auf die Anforderungen an. Da du hier nur Java
vorgegegben hast....

Mittlere bis großen Webanwendung heißt dann genau was? Nenne mal Vergleichbare Seiten und ein paar weitere Anfoderungen
wie geschätzte Benutzeranzahl (insgesamt, parallel), Verfügbarkeit, Interaktivitätsgrad,
Art der Anwendung (Mashup, Web 2.0 Social Network?), Anfoderungen an Sicherheit, Content-Lastigkeit (Wegen Speicherplatz,
Content Delivery Network, Amazone EC2 Storage)?, Wiederkehrende Jobs (Backup, Austausch mit Fremdsystem), verwendete Datenbanken etc.

Nur mit diesen Informationen kann man wirklich "sinnvolle" Empfehlungen aussprechen.

Ansonsten fühle ich mich gerade mit
HTML / JSP / JavaScript / GWT / Spring / Tomcat bzw. ganz wohl.

weitere Alternative, die ich im Moment sehr Reizvoll finde ist google AppEngine (mit java oder python).

Gruß Tom

 

[mschlegel]

Danke für die EJB-Aufklärung (du hast recht, in der Uni haben wir damals 2.1 genutzt und das war schon ziemlich viel Aufwand). Und noch ein Grund nicht EJB zu nutzen ist, dass ich einen AppServer ala JBOSS, WebSphere, usw brauche wo sonst ein Tomcat/Jetty reichen würde.

Ich denke hier nicht an die nächste Web 2.0 alla Facebook, Twitter, Stackoverflow, ... wo pro Minute mehrere tausend requests eintreffen.

Ich denke eher an eine Produktlösung, sprich ein Anwendungen die ein bestimmtes Problem für bestimmte Kunden lösen kann. Die Anzahl der Aufrufe wird sich hier wahrscheinlich zwischen 50 und 500 bewegen.
Viel wichtiger bei so etwas ist meiner Meinung nach die Datensicherheit und gaanz wichtig die Wartbarkeit/Erweiterbarkeit (Customizing) denn nichts ist so konstant wie Änderungen.(insbesondere Kundenwünsche).
Des Weiteren habe ich auch immer einen Rich-Client (Eclipse RCP) im Hinterkopf. aber das hat jetzt nix mit J2EE zu tun

EDIT zum Thema EJB: Hab gerade diesen Post hier gelesen und Unit-Test oder Test-Driven-Development sind meiner Meinung nach auch extrem wichtig und müssen auch einfach sein (wenn der Test zu lange dauert oder zu kompliziert wird, dann macht ihn keiner). Und dafür extra noch ein Framework nutzen oder den Container "faken" klingt eindeutig kompliziert.