Evolution der Web-Entwicklung im Java-Bereich

[Medi]

Hallo Leute,

ich schreibe eine Diplomarbeit über Framework "Jboss Seam".
Ich hatte davor nichts mit Java zutun gehabt. Komme aus cgi-Programmierung php,perl,c.
ich hab mich soeinbisschen in gesammte Java EE-Kram eingelesen, und wollte Gurus fragen, ob
ich richtig das Ganze verstanden habe.

1) Alles hat mit Servlets angefangen. Das sind ganz normale Java-Klassen. Sie nehmen Benutzeranfrage entgegen, und erstellen darauf die Antwortseiten. Sie werden von Oberklasse HTTPServlet abgeleitet, dabei werden die Methoden doGet() und/oder doPost() überschrieben, man hat dort die URL-Parameter oder Formular-Daten zur Verfügung. Und macht man damit, was man möchte. Aber man hat gemerkt, dass Servlets scheisse sind, weil sie eine Mischung von HTML und Java-Kode sind. Also schlecht wartbar usw.

2) Dann haben die JSP erfunden. Jetzt umgegehrt, man schreibt HTML-Seiten und dort kann man java-Kode unterbringen. Die JSP-Seiten werden vom JSP-copmiler kompiliert, dann entstehen ganz normale servlets, die dann im webserver ausgeführt werden. Man bekommt aber bei dieser Technik auch eine Mixtur von HTML und Java-Kode.

3) Dann haben einige Leute nachgedacht, und Struts erfunden. Damit dieses Web-Framework eine Architekur vorgibt, um die verschiedene Aufgabe zu trennen. also statische Dartellung(HTML) und LOGIK(Java-Kode).

4) Sun hat gemerkt, dass Struts nicht schlecht ist, und aus positiven und negativen Erfahrungen von Struts und anderen Web-Frameworks JSF-Standart zusammengebastelt.

Auf der Seite der Anwendungslogik:

EJB2.1 war scheisse.
Einige Leute konnten das nicht aushalten, und machten ein leichten Framework "Spring".

Sun hat gemerkt, dass Spring nicht schlecht ist, und machte EJB 3.0

Dann kommt Jboss Seam. Seam nimmt das beste und stellt dem Entwickler ein einheitliches Programmiermodell.

JSF + EJB3 + JPA = SEAM

Liege ich falsch, wenn ich behaupte, dass man heute alles vergessen kann, und mit Seam arbeiten?
Ich rede nur von Webanwendungen!

 

[Guest]

Ich dachte Silverlite wäre die Krönung der Schöpfung.
Die Entscheidung, welches Framework am besten geeignet ist, hängt nicht zuletzt von den verfügbaren
Implementierungen ab. JSF Implementierungen wie IceFaces oder RichFaces sind inzwischen so weit,
dass man damit vernünftig arbeiten kann. JBoss Seam habe ich leider noch nie probiert.

 

[Guest]

Ich dachte Silverlite wäre die Krönung der Schöpfung.
Die Entscheidung, welches Framework am besten geeignet ist, hängt nicht zuletzt von den verfügbaren
Implementierungen ab. JSF Implementierungen wie IceFaces oder RichFaces sind inzwischen so weit,
dass man damit vernünftig arbeiten kann. JBoss Seam habe ich leider noch nie probiert.

JSF-Implementierungen sind Apache MyFaces und Implementierung von Sun

Servlets eignen sich für bestimmte Aufgaben, z.b Bilder, Dateien, ... dem Klient auszuspucken

 

[HLX]

Aber man hat gemerkt, dass Servlets scheisse sind, weil sie eine Mischung von HTML und Java-Kode sind. Also schlecht wartbar usw.

Servlets sind auch heute noch sehr beliebt. Sie sollten nur nicht für die Erzeugung der grafischen Oberfläche verwendet werden. Für webspezifischen Javacode sind sie jedoch immer noch erste Wahl.

2) Dann haben die JSP erfunden. Jetzt umgegehrt, man schreibt HTML-Seiten und dort kann man java-Kode unterbringen. Die JSP-Seiten werden vom JSP-copmiler kompiliert, dann entstehen ganz normale servlets, die dann im webserver ausgeführt werden. Man bekommt aber bei dieser Technik auch eine Mixtur von HTML und Java-Kode.

Nein. Richtig eingesetzt ergänzen sich Servlets und JSPs. Servlets für den Java Code und JSPs für die Darstellung. Um Java Code in JSPs zu vermeiden verwendet man Taglibs. Hierauf solltest du unbedingt eingehen, vor allem auf die JSTL.

3) Dann haben einige Leute nachgedacht, und Struts erfunden. Damit dieses Web-Framework eine Architekur vorgibt, um die verschiedene Aufgabe zu trennen. also statische Dartellung(HTML) und LOGIK(Java-Kode).

4) Sun hat gemerkt, dass Struts nicht schlecht ist, und aus positiven und negativen Erfahrungen von Struts und anderen Web-Frameworks JSF-Standart zusammengebastelt.

Es haben viele Leute nachgedacht und dabei sind auch viele Frameworks entstanden. Die Welt besteht nicht nur aus Struts und JSF. Weitere Framworks sind z.B. Webwork oder Cocoon. Alle haben gemeinsam, dass die Arbeit mit Webanwendungen erleichtert werden sollen, jedoch verfolgen sie unterschiedliche Ansätze und setzen unterschiedliche Schwerpunkte. JSF ist im übrigen schon länger in der Entstehung. Struts dürfte für JSF hier nicht der Auslöser gewesen sein.

Seit der Einführung von Web 2.0 entstehen wiederum AJAX-Frameworks. Stichworte sind hier RAP, GWT oder WingS.

Auf der Seite der Anwendungslogik:

EJB2.1 war scheisse.

Anwendungslogik gibt es auch schon in o.g. Webanwendungen. Ist dir klar worum es sich bei EJB handelt?

 

[foobar]

Groovy on Rails fehlt auch noch http://de.wikipedia.org/wiki/Groovy_on_Rails

 

[Medi]

Aber man hat gemerkt, dass Servlets scheisse sind, weil sie eine Mischung von HTML und Java-Kode sind. Also schlecht wartbar usw.

Servlets sind auch heute noch sehr beliebt. Sie sollten nur nicht für die Erzeugung der grafischen Oberfläche verwendet werden. Für webspezifischen Javacode sind sie jedoch immer noch erste Wahl.

Ja, so habe ich es auch verstanden. Servlets sind wichtig.
Scheisse habe ich in dem Sinne gemeint, dass der Entwickler 1996-1997 nur Servlets zur Verfügung hatte, damit hatte er Dartellung, Logik und Daten programmiert.
Obwohl....ich habe mir gedacht....Man könnte doch im Servlets die statische HTML-Vorlagen(dort difiniert man Platzhalter) einlesen, dann Platzhalter ersetzen und an den Klient ausgeben. So, wie man bei CGI-Programmierung mit Perl oder C macht.

2) Dann haben die JSP erfunden. Jetzt umgegehrt, man schreibt HTML-Seiten und dort kann man java-Kode unterbringen. Die JSP-Seiten werden vom JSP-copmiler kompiliert, dann entstehen ganz normale servlets, die dann im webserver ausgeführt werden. Man bekommt aber bei dieser Technik auch eine Mixtur von HTML und Java-Kode.

Nein. Richtig eingesetzt ergänzen sich Servlets und JSPs. Servlets für den Java Code und JSPs für die Darstellung. Um Java Code in JSPs zu vermeiden verwendet man Taglibs. Hierauf solltest du unbedingt eingehen, vor allem auf die JSTL.

Ja, hast du recht. Über JSTL habe ich auch gelesen. Aber in Büchern wird geschrieben, dass mann durch saubere Programmierung die Aufgabebereiche trennen kann, in dem man möglichts viel Java-Kode in JavaBeans auslagert und Taglibs benutzt, aber in der Realität sind JSP-Seiten sehr unübersichtilich. Vor allem bei der umfangreichen Anwendungen kommt man sehr schnell an die Grenze von JSP-Technik. Also was benutz werden kann, wird auch missbraucht.
Stimmt doch oder?

3) Dann haben einige Leute nachgedacht, und Struts erfunden. Damit dieses Web-Framework eine Architekur vorgibt, um die verschiedene Aufgabe zu trennen. also statische Dartellung(HTML) und LOGIK(Java-Kode).

4) Sun hat gemerkt, dass Struts nicht schlecht ist, und aus positiven und negativen Erfahrungen von Struts und anderen Web-Frameworks JSF-Standart zusammengebastelt.

Es haben viele Leute nachgedacht und dabei sind auch viele Frameworks entstanden. Die Welt besteht nicht nur aus Struts und JSF. Weitere Framworks sind z.B. Webwork oder Cocoon. Alle haben gemeinsam, dass die Arbeit mit Webanwendungen erleichtert werden sollen, jedoch verfolgen sie unterschiedliche Ansätze und setzen unterschiedliche Schwerpunkte.

Ja klar, in dieser Zeit sind viele Framework entstanden, aber Struts war der erfolgreichste und meist verwendete.Oder?

JSF ist im übrigen schon länger in der Entstehung. Struts dürfte für JSF hier nicht der Auslöser gewesen sein.

Bist du sicher? Von Büchern habe ich so verstanden!
Klar nicht nur Struts war der einzige Auslöser für JSF, aber der bedeutenste

Seit der Einführung von Web 2.0 entstehen wiederum AJAX-Frameworks. Stichworte sind hier RAP, GWT oder WingS.

Ja, davon habe schon was gehört...

Auf der Seite der Anwendungslogik:

EJB2.1 war scheisse.

Anwendungslogik gibt es auch schon in o.g. Webanwendungen. Ist dir klar worum es sich bei EJB handelt?

mit EJB implementiert man doch Anwendungslogik. oder wie? oder was?


Also worauf ich hinaus will...Webentwicklung mit der traditionellen Technologie, wie Servlet/JSP oder Frameworks wie Struts, Spring gehören der Vergangenheit. Man verwendet sie wegen schon existierenden, mit dieser Technik entwickelten Anwendungen, oder man hat kein Bock mit neuen Technik auseinander zu setzen.

Aber es gibt neue Techniken, die man produktiver einsetzen kann. sowie Seam oder (RAP, GWT, wahrscheinlich auch,)

 

[Niki]

Mit EJBs kann man die Anwendungslogik implementieren. In der Praxis werden EJBs aber eher selten tatsächlich eingesetzt (oder liege ich da falsch). Der Vorteil von EJBs ist, dass man damit skalierbare und eben verteilte Applikationen bauen kann.

 

[karatekid]

@Medi
dein Eingangsbeitrag macht mal wieder klar, dass man sich eben nicht mal im Vorbeigehen mit dem, im übrigen doch sehr überspannenden Thema befassen kann und dann darüber auch noch eine Diplomarbeit schreiben kann. ???:L
Jedenfalls macht es den Eindruck, du hast mal eben einige Dokumente überflogen und machst jetzt daraus eine Diplomarbeit.

@Niki
kommt darauf an, was du unter Praxis verstehst. Im Bereich grosser Konzerne, Banken, Behörden etc. werden EJB fast ausschliesslich eingesetzt da hier meist grosse Datenmengen bewältigt werden müssen und eine Ausfallsicherheit gegeben sein muss. Ok, letzteres kann man auch anders und weniger elegant bauen.
Bei kleineren Applikationen werden EJBs eher selten eingesetzt.

 

[Niki]

Ok, gerade da wo es um Ausfallsicherheit geht wird man um EJBs nicht herumkommen. Da geb ich dir recht.

 

[HLX]

Ja, hast du recht. Über JSTL habe ich auch gelesen. Aber in Büchern wird geschrieben, dass mann durch saubere Programmierung die Aufgabebereiche trennen kann, in dem man möglichts viel Java-Kode in JavaBeans auslagert und Taglibs benutzt, aber in der Realität sind JSP-Seiten sehr unübersichtilich. Vor allem bei der umfangreichen Anwendungen kommt man sehr schnell an die Grenze von JSP-Technik. Also was benutz werden kann, wird auch missbraucht.
Stimmt doch oder?

Also mit der richtigen Techik müssen JSPs nicht unübersichtlich werden. In den meisten Fällen kann man Standard-Taglibs verwenden und falls nicht schreibt man eben ein eigenes Tag. Falls man in Ausnahmefällen davon absehen möchte bleibt die Übersichtlichkeit trotzdem erhalten.

JSF und Struts basieren letzendlich ebenfalls auf der JSP und Servlet-Technologie. Die Frameworks liefern im Kern Tag-Libraries für die GUI und Servlets für die Anwendungskontrolle.

Ja klar, in dieser Zeit sind viele Framework entstanden, aber Struts war der erfolgreichste und meist verwendete.Oder?

Struts war schon sehr verbreitet, Zahlen habe ich allerdings keine dazu. Manche Frameworks haben allerdings auch andere Schwerpunkte. Das XML-basierte Cocoon konzentriert sich z.B. stark auf verschiedene Ausgabeformate. Struts ist m.E. ein flexibler Allrounder.

Bist du sicher? Von Büchern habe ich so verstanden!
Klar nicht nur Struts war der einzige Auslöser für JSF, aber der bedeutenste

Natürlich hat man sich die Erkenntnisse aus den ersten Struts-Releases zu Nutze gemacht, aber ob das nun die Motivation für die Schaffung eines neuen Frameworks war...

mit EJB implementiert man doch Anwendungslogik. oder wie? oder was?

EJB ist ein Modell für verteilte Komponenten.
Motivation:
Im Kern geht es darum Anwendungkomponenten zu erstellen, die man auf einer Serverlandschaft zur Verfügung stellen kann. In der Regel sind dies BL-Komponenten. Stell dir einen Konzern vor, der ein J2EE-Serversystem mit 4 Serverstandorten hat. Nun würde es Anwendungskomponenten wie z.B. Bestellwesen, Beschaffung oder ein Verkaufsmodul am jeweiligen Standort vorhalten, weil dies vielleicht aus Performancegründen sinnig ist. Das Controlling am 4. Standort braucht nun Informationen aus den Modulen der anderen Standorten. Über verteilte Komponenten ist es egal, wo sich diese gerade physisch befinden. Nach außen hin sind die Komponenten überall verfügbar. Möchte man eine Komponente nun aus irgendwelchen Gründen an einen anderen Standort verschieben, ist dies ohne Probleme möglich. Der Anwender merkt davon nichts.

Also worauf ich hinaus will...Webentwicklung mit der traditionellen Technologie, wie Servlet/JSP oder Frameworks wie Struts, Spring gehören der Vergangenheit. Man verwendet sie wegen schon existierenden, mit dieser Technik entwickelten Anwendungen, oder man hat kein Bock mit neuen Technik auseinander zu setzen.

Aber es gibt neue Techniken, die man produktiver einsetzen kann. sowie Seam oder (RAP, GWT, wahrscheinlich auch,)

Welche Technologie in Frage kommt ist ein Frage der Anforderungen. Für eine kleines Web-Reporting-Tool benötigt man z.B. keine Enterprise Java Beans. Da schreibt man die BL in Servlets.

 

[ARadauer]

Also was benutz werden kann, wird auch missbraucht.
Stimmt doch oder?

;-) yeah!!

 

[Medi]

@HLX
Danke für die Antowort. Ich verstehe, was du meinst.
Ich habe vergessen zu erwähnen, dass sich diese Evolution der Java-Webentwicklung auf grooooße Unternehmensanwendungen bezieht. Denn von Unternehmen kommen ständig wachsende Anforderungen, die die Technologie vorantreiben.

Deswegen, wenn ich sage Struts, Spring kann man heute wegschmeissen, bezieht sich das auf groooße Enterprise-Anwenungen, mit komlexer Geschäftslogik.

 

[Medi]

@karatekid
Ich schreibe Diplomarbeit über Applikation-Framework "Jboss Seam". Und muss mich mit verherrigen Technologien auseinander setzen, um sie mit Seam zu vergleichen.

 

[byte]

Deswegen, wenn ich sage Struts, Spring kann man heute wegschmeissen, bezieht sich das auf groooße Enterprise-Anwenungen, mit komlexer Geschäftslogik.

Da liegst Du vollkommen falsch. Spring ist alles andere als auf einem absteigenden Ast.

 

[Guest]

Flex ist auch ganz gut. Die Anbindung an Java funktioniert einwandfrei und die Entwicklung anspruchsvoller
Webanwendungen geht damit ziemlich schnell.

 

[HLX]

@HLX
Denn von Unternehmen kommen ständig wachsende Anforderungen, die die Technologie vorantreiben.

Von Unternehmen kommen auch unterschiedliche Anforderungen, die verschiedenen Technologien ihre Daseinsberechtigung geben.

Deswegen, wenn ich sage Struts, Spring kann man heute wegschmeissen, bezieht sich das auf groooße Enterprise-Anwenungen, mit komlexer Geschäftslogik.

Wie byto schon schrieb ist Spring aktueller als du denkst. Für GWT als AJAX-Framework gibt es z.B. bereits eine Spring-Anbindung als Erweiterung.

Noch ein Tipp: Es tut deiner Diplomarbeit nicht gut, wenn du Seam durch eine rosa Brille siehst. Ich kenne Seam nicht, aber auch dieses Framework muss für das entwickelnde Unternehmen bestimmte Anforderungen erfüllen. Frameworks verfolgen oft unterschiedliche Ansätze. Einige Kapseln zu lasten der Flexibilität sehr stark, bei anderen ist der Entwicklungsaufwand höher, dafür besteht jedoch auch höhere Flexibilität. Bei größeren Anwendungen kann diese Flexibilität entscheidend sein, weil man auf das Web-Framework sein eigenes unternehmensspezifisches Framework aufsetzen möchte.

Zu deiner Aussage von JSF im Bezug auf Struts hier noch eine Einordnung von SUN, die erklärt, dass JSF und Struts zwei verschiedene Dinge mit überlappender Funktionalität sind. JSFs Fokus liegt im Sinne von MVC auf dem View:
wiki.java.net/bin/view/Projects/JavaServerFacesSpecFaq