ich habe kleine eine Architekturfrage: Auf einem Hostrechner wird eine Instanz eines Java Programms ausgeführt, das aus technischen dort ausgeführt werden muss und dass neben einer DB viele Daten transient im Speicher halten muss. Nun soll es eine Gui geben, mit der man per Browser von beliebigen Rechnern im Netz die Daten dort einsehen und verarbeiten kann, und verschiedene Funktionen der Programminstanz ausführt.
Jetzt stellt sich die Frage nach der verwenden Technologie, wo meine Kentnisse noch nicht austeichen, das gut einordnen zu können. Klar, das Programm muss als Webserver fungieren oder einen mitbringen. Nun kann ich mir also vortsellen einen Jetty oder Tomcat einzubinden, der brav HTTP Anfragen entgegen nimmt. Doch was weiter? Wie soll es zur Anzeige der dynamischen Seiten kommen? Davon es viele geben müssen. Mir ist nicht klar, ob Servlets, JSP, Struts, etc. die richtige Wahl sind oder ich liebe zu Fuß einen Socket aufmache, GWT einsetze oder noch was Anderes benutzen soll. Die einzigen Bedingungen, die es gibt:
Alles was das Programm braucht muss es selbst mitbringen (z.B Webserver)
Jeder Webclient muss mmer das gleiche Programm-Objekt auf dem Host (mit seinen transienten Daten) ansprechena
Punkt 1 ist einfach, dass machen millionen andere Webanwendungen auch. Einfach Tomcat aufsetzen, eigene Webapp rein und gut.
Punkt 2 benötigt mehr Informationen:
Welche Erwartungen verknüpfts Du damit:[quote=Ulyssus]Jeder Webclient muss mmer das gleiche Programm-Objekt auf dem Host (mit seinen transienten Daten) ansprechen[/quote]Um sich den "State der Anwendung zu merken gibt es verschiedene Techniken, aber die Bedinung so konkret wirst Du wohl nicht auf einfache weise umgesetzt bekommen.
Hallo, vielen Dank für die Antwort. Zu Punkt 2 muss man sich das so vorstellen: Wenn das Programm gestarten wird, wird eine zentrale Manger Klasse instantiert. Diese hällt Verbindungen zur DB und zu anderen angeschlossenen Geräten. Viele Daten müssen aus technischen Gründen jedoch auch transient gehalten werden. Wenn nun ein Client z.B. einen Button auf der Website drückt um eine Aktion auszulösen, dann muss eine Methode von diesem anwendungsweiten Nanger Objekt aufgerufen werden, das entsprechende Objekt ist also Session übergreifend.
Mein naiver Ansatz wäre, das Webbackend und das zentrale Anwendungsobjekt wiederum per RMI o.Ä. zu verknüpfen. Oder gibt es eine einfachere Möglichkeit?
Ja, im Falle von JSF wäre das eine ApplicationScoped Bean. Für Formular getriebene Anwendungen bietet sich JSF sowieso an.
Puncto Cache muss du dir überlegen auf welcher Ebene du ansetzt. Z.B. mit Memcache, JPA-Optimierung oder in der Applikation (ApplicationScoped Bean z.B.).
ich würde erstmal klären, ob die GUI viele User-Interaktionen erfordert (Formulare, etc). Braucht man ein Benutzermanagement / Login? Wenn es nur einen ApplicationScope gibt und keine “Sitzungen”, dann reicht ein eingebetteter HTTP-Server doch höchstwahrscheinlich völlig aus (Netty, Grizzly, undertow…oder gleich den mitgelieferten Server) um HTML-Seiten zum Client zu schicken.
ja so etwas wie einen Application Scope suche ich! Das eigentliche ‘Programm’ ist ja schon da, nur die GUI soll ersetzt werden (von SWT auf Web). Und ja, am liebsten würde ich ich einen eingebetten Web Server haben (Jetty?), als ihn über einen externen Prozess starten zu müssen.
Bevor ich mich aufgrund dieser Infos in das Thema JSF stürze, nochmal zur Sicherheit:
Ist JSF ein solider Anstaz für ein solches Problem (Applicatio Scope, viele Formulare eingaben)?
Kann ein eingebetter Webserver wie Jetty oder Andere mit JSF umgehen?
Ja, wobei sich die Frage stellt ob der Anwendung ein Refactoring nicht gut tuen würde. Normalerweise lässt sich eine solche Anwendung nur schwer 1:1 in eine Web-Anwendung verwandeln.
Vor allem wenn ein jeder Aufruf der Seite immer auf die selbe Instanz der ApplicationScope zugreift, wird es sehr schnell Performance-Probleme geben.
Aber prinzipiell ist es so:
JSF ist für viele Formulareingaben designed worden. Du hast eine Bean und du hast eine XML-Beschreibungssprache die, die GUI erstellt. Zusätzlich ein wenig DI-Magie die alles ineinander greifen lässt mit der Möglichkeit über Annotations zu konfigurieren welche Bean welche Lebenszeit hat (Request, Session, Application, z.B.) Der DI-Container wird vom JSF-Servlet angestoßen, also keine Arbeit für dich.
JSF ist Teil des Java EE Standards und damit eine der gesetztesten Web-Technologien von Java.
Wenn du die dafür nötigen JARs mitlieferst schon. Ja, das geht. JSF ist ein Framework das auf einem normalen Servlet aufbaut.
IMO solltest du auf jeden Fall einen mehrstufigen Migrationsplan anpeilen in dem du schnell Ergebnisse lieferst aber den Umbau der Architektur fest mit einplanst, wenn denn dann wirklich mal mehrere Leute gleichzeitig mit dem Ding arbeiten wollen.
Von SWT zu Web? Hast du dir mal https://eclipse.org/rap/ angesehen. Es handelt sich dabei um etwas analoges zu gwt aber für swt anstelle von swing. Habe vor kurzem einen Prototypen damit gemacht und musste (von einigen Ausnahmen abgesehen) nur die swt.jar ersetzen.