Frontend mit Java

Moinmoin,
nachdem ich mich nun ausgiebig mit Hibernate, JUnit und allgemeinen Designpatterns im Backend beschäftigt habe, will ich so langsam anfangen auch meine Daten auf den Monitor zu bringen. Nach einigem Lesen, habe ich schon ein paar Ideen, die mir durch den Kopf spuken. Allerdings waren die Infos für den Einstieg ziemlich harter Tobac und irgendwie bekomme ich meine Gedanken noch nicht so richtig geordnet und stehe ziemlich aufm Schlauch. Vielleicht kann mir der eine oder andere einen Tipp geben oder vielleicht ergibt sich auch eine schöne Diskussion oder zumindest eine Runde Buzzword-Bingo
Die Oberfläche selber soll die Daten weitestgehend dynamisch nachladen. Da die Daten dafür sowieso irgendwie XMLerisiert werden müssen, bietet es sich an, das Backend als Webservices zu kapseln. Um mir alle Wege offen zu halten, möchte ich die Backend-Funktionen in einem normalen SOAP/http Webservice anbieten. Um speziell für die Browserumsetzung Bandbreite zu sparen, will ich aber auch JSON als Output der Webservices haben.
Geht das überhaupt einen Webservice zu erstellen, der als Antwort verschiedene Formate anbietet (kann Tomcat das?). In welchem Format übergeben ich die Parameter einem solchen Webservice überhaupt? Gibt es schon irgendwas fertiges, mit dem ich die Aufrufe auf Clientseite machen kann (irgendwelche Toolkits)?
Als MVC-Handler will ich Struts 2.0 verwenden. Ist das sinnvoll? Bietet mir Struts was ich für ein Browsergame (mit vielen bunten Bildern und viel Drag&Drap, aber wenigen Steuerelementen) brauche, oder ist das eher lästig? Zumal die ganze Logik ja schon in den Webservices ist. Wo soll ich eigentlich mit meinem JavaScript hin? Schreibe ich das einfach in meine JSPs oder erzeuge ich eigene Taglibs? Ist es sinnvoll ein JavaScript-Toolkit zu benutzen? Mit welchem habt ihr gute Erfahrungen gemacht?
Ansonsten bin ich mir auch noch nicht ganz sicher wie ich das Rechtemanagement regeln soll. Mir schwebt irgendwas in Richtung Authorisierung im Backend, Athentifizierung im Frontend vor. Aber ist das wirklich sinnvoll? Das Frontend muss letztlich auch wissen, welche Seiten es anzeigen darf und welche Links eingeblendet werden sollen (z.B. Admin Links, Game Op Links).
Gibt es vielleicht schon eine ganzheitliche Lösung für das alles, was ich vor habe? Vielleicht sogar schon eine, die ein Forum und eine Wiki einschließt ? Fragen über Fragen... Vielleicht kann die Java-Fangemeinde ein Schwank aus ihrem Projekt erzählen.
Gruß Michael

Nur zum Thema Authentifizierung & Logik: Die muss immer in beiden Instanzen ausgecodet werden. Du kannst nicht entweder das Frontend oder das Backend wissen lassen was der User darf - was du tun könntest, ist das Frontend immer wieder nachfragen zu lassen beim Backend, das halt ich aber mittelmässig sinnvoll.
Wie sinnvoll es ist, zusätzlich ein Frontend in Java zu machen, will ich deinem Ermessen überlassen - ich finds unnötig.

Dass die Authorisierung in beiden Bereichen zugreifbar sein soll, leuchtet ein: Das Frontend muss wissen, ob es irgendwelche Seiten anzeigen soll, das Backend muss jede Anfrage, die ankommt, trotzdem noch mal verifizieren. Aber das doppelt zu coden und doppelt zu pflegen kanns auch nicht sein.
Ob Java oder nicht Java kann ich mir ja noch überlegen. Wenn das Backend durch Webservices abgekoppelt ist, bin ich da ja frei. Momentan ist bei meinem Projekt der Weg das Ziel. Es geht also weniger um ein fertiges Spiel, als um Skill-Aufbau. Und da liegt meine Priorität klar auf Java. Daher soll das Thema auch wirklich lauten "Wie setze ich das in Java um?".

Original von Nuky
Nur zum Thema Authentifizierung & Logik: Die muss immer in beiden Instanzen ausgecodet werden. Du kannst nicht entweder das Frontend oder das Backend wissen lassen was der User darf - was du tun könntest, ist das Frontend immer wieder nachfragen zu lassen beim Backend, das halt ich aber mittelmässig sinnvoll.
Wie sinnvoll es ist, zusätzlich ein Frontend in Java zu machen, will ich deinem Ermessen überlassen - ich finds unnötig.

Naja Wieso über die Sache mit dem Sinn des Frontendes geredet wird, weiß ich nicht so recht. Aber es wird wohl seine Sache sein.
Warum soll man die Authentifizierung in allen beiden Teilen ausprogrammieren? Wenn das Frontend eine Anfrage ans Bakcend stellt und dieses eine "OperationNotAllowed"-Exception wirft, dann weiß das Frontend immer, wie es damit umgehen muss. Nämlich dem User begreiflich machen, dass er die Daten nicht bekommt, die er will.
Auch würde ich mal wissen, was ihr euch unter Frontend vorstellt. Also clientseitig oder immernoch serverseitig? Wenn von struts die Rede ist, dann kann es ja nur serverseitig sein.

Wenn das Backend durch Webservices abgekoppelt ist, bin ich da ja frei. Momentan ist bei meinem Projekt der Weg das Ziel. Es geht also weniger um ein fertiges Spiel, als um Skill-Aufbau. Und da liegt meine Priorität klar auf Java. Daher soll das Thema auch wirklich lauten "Wie setze ich das in Java um?".
Naja dein Hauptproblem werden sicher die Webservices sein, dass die ja stateless sind. Also musste dir deine Sessionverwaltung selber schreiben (Gibt zwar irgendeine WS-Spezifikation, aber die war nicht wirklich so das, was ich mir unter Sessionverwaltung vorstelle )
Wie das nun alles, was du fragst mit struts geht, kann ich dir nun nicht genau sagen, weil ich mich mit struts nie auseinander gesetzt habe. Aber im Endeffekt ists dir überlassen, ob du dein Javasacript direkt in die JSP schreibst oder eine separate Javascript-Datei includierst (normale HTML-Tags halt).
Kommt auch drauf an, ob du eine Javascript-Variante und eine NonJavascript-Variante haben willst. Fürs erstere gibts zb. das GWT, wo du in Java dein Javascript-Code erstellst.

Mir fehlen da noch die Erfahrungen mit Struts und Co., aber wenn du alternative Ausgabetypen haben willst (was ich auch begrüßen würde), dann würde ich das System auch so konzipieren - notfalls mit einem Aufsatz in dem Framework deiner Wahl. Das sehe dann so aus, dass du alle Ausgaben zentral durch eine Instanz (bsp. XML->XHTML, oder XML->JSON) jagst. Das ließe sich beispielsweise sehr gut mit XSL lösen.
Problemantisch wird das nur, wenn das Framework selber schon HTML ausgibt, das finde ich aber persönlich heutzutage dann etwas zu statisch (bei einer Anwendung, die tatsächlich Java braucht.)

Jo oder du machst es in der Art wie Knalli es meint. Mach dir dein eigenes Frontend und bastel ein wenig mit Filter rum ( java.sun.com/javaee/5/docs/api/javax/servlet/Filter.html ). Da kannste deine Daten, die du in irgendeiner Art ausgeben willst, in Beans stecken (oder irgendeine Klasse, die die Daten hält) und dann mittels xsl-Templates und so weiter dann im Filter zusammenfügen.

Ich würde von den Webservices zur Kapselung der Logik abraten, da sie enorm Overhead mitbringen.
Stattdessen würde ich alles was die Ausgabemethode nicht kennen muss in eine eigene Library packen und mir eine klar definierte Struktur mit sinnvollen Schnittstellen zurechtlegen. Für jede Ausgabemethode kannst du dann die entsprechenden Views/Controller einzeln bauen und immer auf die selbe Schnittstelle im Code zugreifen. Ist vielleicht nicht hyper-flexibel, aber der Performance wäre es sicher dienlich.

Auch würde ich mal wissen, was ihr euch unter Frontend vorstellt. Also clientseitig oder immernoch serverseitig? Wenn von struts die Rede ist, dann kann es ja nur serverseitig sein.

Das ist schon eine sehr gute Frage.
Meine Planung sieht folgendermaßen aus: Das Backend ist für mich alles, was das Spiel ausmacht. Also theoretisch könnte man jetzt schon spielen, aber man müsste halt für alle seine "Spielzüge" einen Java-Aufruf machen. Wenn das Backend in Webservices geht, kann das Frontend prinzipiell alles sein: eine RCP-Anwendung, eine Web-Seite, eine C++ Applikation, usw.
Das Frontend, über das ich jetzt rede, ist eine Webapplikation. Aber die Frage ist nun, was macht diese Webapplikation eigentlich alles? Wenn ich davon ausgehe, dass alles dynamisch über AJAX läuft, dann bleibt im Extremfall eine Seite, in der das komplette Spiel abläuft, dann vielleicht noch eine Willkommens-, Login- und Registrierseite (wie gesagt Extremfall). Alles andere sind die Webservices und viel JavaScript.

Naja dein Hauptproblem werden sicher die Webservices sein, dass die ja stateless sind. Also musste dir deine Sessionverwaltung selber schreiben (Gibt zwar irgendeine WS-Spezifikation, aber die war nicht wirklich so das, was ich mir unter Sessionverwaltung vorstelle )

Wozu brauche ich Stateful WSes? Das Spiel selber ist eine Statemachine. Dazu gibt es als Schnittstelle lesende Services, die den Status der Statemachine wiedergeben und schreibende, die den Status verändern. Das einzige, was ich brauche ist bei jedem Aufruf die Id des Spielers, damit klar ist wessen Daten zurückgegeben oder manipuliert werden sollen.

Jo oder du machst es in der Art wie Knalli es meint. Mach dir dein eigenes Frontend und bastel ein wenig mit Filter rum ( java.sun.com/javaee/5/docs/api/ja...let/Filter.html ). Da kannste deine Daten, die du in irgendeiner Art ausgeben willst, in Beans stecken (oder irgendeine Klasse, die die Daten hält) und dann mittels xsl-Templates und so weiter dann im Filter zusammenfügen.

Der Filter hilft da nicht mehr viel. Wennich im Filter bin, dann ist die Response schon erzeugt und ich kann da nicht mehr viel beeinflussen. Oder wie hast du dir das mit dem Filter vorgestellt? Da bin ich echt noch auf nen Tipp scharf. Wo bekomme ich meine eierlegende Wollmilchsau her? Ich will Webservices, die unterschiedliche Formate zurückgeben können und das am liebsten nicht selber implementieren, sondern irgendwas in Richtung Annotations nutzen.
@Webservice
@Output(format=JSON, format=SOAP/http)
Somebean getInfo(OtherBean bean) {
...
}

Ich würde von den Webservices zur Kapselung der Logik abraten, da sie enorm Overhead mitbringen.

Gefühlt oder in echt? Bei einer "normalen" Webanwendung verstehe ich den Einwand noch: Es wird ein http-Request erzeugt, an den Server geschickt, muss dort verarbeitet werden und für die Verarbeitung muss man weitere Requests erzeugen, um auf die WSes zugreifen zu können. Wenn aber AJAX zum Einsatz kommt, dann hat man doch sowieso nur einen Request. Ob man nun einen Request erzeugt, ein undefinertes XML-Format zurückgibt oder JSON zurückgibt und das ganze "AJAX" nennt. Oder ob man einen Request erzeugt, ein definiertes Format zurückgibt und das ganze "Webservice" nennt, das dürfte sich doch nicht viel tun.
Sehe ich das richtig, dass die Java-Entwickler auf irgendwelche Frameworks wie Struts und Co. verzichtet haben und auf Servlets und JSP setzen?
Gruß Michael

Original von MichaelB
Der Filter hilft da nicht mehr viel. Wennich im Filter bin, dann ist die Response schon erzeugt und ich kann da nicht mehr viel beeinflussen. Oder wie hast du dir das mit dem Filter vorgestellt?

Schau dir mal das Beispiel auf www.jguru.com/forums/view.jsp?EID=1072839 an. Da wird mittels eines Wrappers der Response abgefangen und dann halt mittels xslt in das gewünschte format verwandelt. Nun könnte man auch diverse Parameter, Annotations usw. auslesen. Wie man halt beliebt. Ich denke du wirst Axis oder Axis2 nutzen. Nun weiß ich nicht, ob man da nochn Filter dahinter hängen kann.

Original von MichaelB
Sehe ich das richtig, dass die Java-Entwickler auf irgendwelche Frameworks wie Struts und Co. verzichtet haben und auf Servlets und JSP setzen?

Ich verwende momentan Struts 2, was seine Aufgabe auch ganz gut erledigt, aber bei dem man deutlich merkt, dass es noch aus "Vor-AJAX-Zeiten" kommt. Beruflich arbeite ich im Moment sehr viel mit Wicket, aber ob das für ein BG geeignet ist muss ich noch entscheiden...war selten so geteilter Meinung zu einem Framework
Also was die Framework-Wahl angeht kann ich im Moment keinen brauchbaren Tipp geben...stecke einfach nicht drin was derzeit alles verfügbar ist.

Wir verwenden Java in Verbindung mit Flash und übergeben die Daten bzw. Updates über eine Socketverbindung, die einen Fallback auf sogenanntes Remoting (Http-Pulls) bekommen soll.
Als Framework dient Red5, eine OpenSource-Lösung für Streaming.