Java Standalone Prog zu Webapplikation umwandeln

[rodion311]

Hallo,

ich würde gerne wissen, wie man generell ein Java Standalone Programm umwandeln muss, damit man es per Browser und Server verwenden kann.

Ich habe ein Java Programm geschrieben (>10000 Zeilen Code), welches für den Standalonebetrieb gedacht ist. Dabei gibt es ein paar Fenster, in denen man Sachen machen kann, zB. Dateien einlesen, ein bisschen malen ... . Die Software liest die eingegebene Daten ein verarbeitet sie und stellt die Ergebnisse grafisch dar, wobei man in den Ergebnissen noch was ändern kann, indem man zB. Symbole verschiebt.

Nun soll mein Programm aber von einer Standalone Anwendung zu einer Webapplikation überführt werden und in ein php-System integriert werden. Ich will also in einer Webseite integriert meine Java-Anwendung benutzen können. Dabei wäre es prinzipiell ok, wenn für jeden Benutzer eine neue Instanz des Programmes auf dem Server ausgeführt würde.

Teilt man da das Programm in ein Applet für die Darstellung und einen Webservice für die Verarbeitung der Daten?
Also JSP alleine schreiben doch nur html, da kann man manipulation von Grafiken nicht so einfach realisieren, oder?

Es wäre echt supernett, wenn mir jemand einfach in ein paar Sätzen darlegen könnte, wie man so etwas am Besten angeht bzw. in Stichpunkten die Technologien für Gui und logik erwähnt!

Vielen Dank für die Hilfe

 

[The_S]

Eine Standalone Applikation sollte sich wesentlich einfach in Form eines Applets umwandeln lassen, da dieses grafische Benutzeroberflächen bereits unterstützt und du somit vermutlich nur ein paar Vererbungen und Verzeichnisstrukturen ändern musst und die Applikation ansonsten großteils erhalten bleiben kann. Außerdem müsstest du das Applet vermutilch signieren (jenachdem was du machst), was zur Folge hat, dass der User bei jedem Aufruf ein Popup bekommt, ob er der Signatur vertraut. Applets werden vom Server heruntergeladen und auf dem Client ausgeführt.

Eine andere Möglichkeit wäre (wie du schon erwähnt hast) eine JSP. Auch ist richtig, dass die JSP nur fürs Anzeigen der Daten gedacht ist und nicht für die Manipulation selbiger (MVC Prinzip). Hierfür wäre dann das Servlet (eine ganz normale Java-Klasse) zuständig. Dieses verarbeitet auch alle Anfragen etc.. Eine JSP bzw. ein Servlet muss nicht signiert werden. Allerdings müsstest du deine GUI komplett neu schreiben und schauen inwieweit du die Logik in dein Servlet bringen kannst.

Dritte Möglichkeit wäre Webstart. D. h. deine Anwendung wird so wie sie ist einfach übers Internet gestartet.

 

[Gast]

machs als webstart. applets sind mist.

 

[The_S]

machs als webstart. applets sind mist.

Wie ich solche unqualifizierten Gast-Postings liebe ... :roll:

 

[Yzebär]

Auch ist richtig, dass die JSP nur fürs Anzeigen der Daten gedacht ist und nicht für die Manipulation selbiger (MVC Prinzip).

Das ist nicht ganz richtig. Eine JSP wird benutzt um Daten anzuzeigen oder eingeben zu können. Oder wie sollte sonst ein Online-Shop funktionieren?

 

[The_S]

Und wo widersprechen sich jetzt unsere beiden Aussagen?

 

[Yzebär]

"Nur Anzeigen" vs. "Anzeigen und Eingeben" ist meines Erachtens ein Unterschied.

 

[The_S]

Mit "Anzeigen" meinte ich die GUI als Ganzes, also Eingabe und Ausgabe ...

Sry falls es missverständlich war

 

[SnooP]

Trotzdem Manipuliert man in JSP nicht die Daten - sondern schickt über Eingabefelder der View entsprechende Vorschläge für eine Änderung an einen Controller, der diese überprüft und dann tatsächlich im Model Änderungen vornimmt ..

eine JSP macht also wirklich nur Anzeige - selbst wenn man in einem HTML-Textfeld einen Wert ändert... davon wird automatisch das Modell nicht verändert - und wenn man das dann doch macht (z.B. SQL in einer JSP), dann ist das unheimlichst falsch

In deinem Fall wäre die Integration in die Seite als Applett vermutlich am sinnigsten, wenn es lediglich darum geht eine Art Web-Look zu generieren... - persönlich halte ich von sowas aber nix - sinnvollerweise sollte die GUI in die Webschicht transportiert werden und die eigentliche Anwendung auf einem Server laufen - meinetwegen könnte man dann die relevanten Funktionen (die tatsächlich die eigentlichen Berechnungen durchführen) via Webservice vom Client (der jsp-seite) starten... muss man aber auch nicht, man kann alternativ auch sehr schön entsprechende Business-Delegates verwenden, die von den Controllern hinter der JSP-Seite aufgerufen werden.

Aber wie gesagt - wenn schon fertig und du nicht mehr allzuviel Arbeit reinstecken willst - mach's halt als applett.

 

[The_S]

Trotzdem Manipuliert man in JSP nicht die Daten - sondern schickt über Eingabefelder der View entsprechende Vorschläge für eine Änderung an einen Controller, der diese überprüft und dann tatsächlich im Model Änderungen vornimmt ..

eine JSP macht also wirklich nur Anzeige - selbst wenn man in einem HTML-Textfeld einen Wert ändert... davon wird automatisch das Modell nicht verändert - und wenn man das dann doch macht (z.B. SQL in einer JSP), dann ist das unheimlichst falsch

Besser hät ichs nicht erklären können! :applaus:

 

[rodion311]

Vielen Dank für die Antworten!

Ich glaube, Applets alleine sind ein Problem, da ich evtl mehr als 64 MB Hauptspeicher für die VM brauche. Als Standalone App konnte ich einfach mein jar über eine batch-Datei starten, die der VM mehr speicher gegeben hat. Es geht mir auch gar nicht darum, dass ich mich scheue, Aufwand zu betreiben, ich weiß nur nicht wie ich es angehen soll. Meine Software muss meiner Meinung nach geteilt werden in einen Server teil (Model und Controller) und in einen Client Teil (View).
Allerdings kann die View meiner Meinung nach schlecht mit JSPs gemacht werden, da ich da was mit interaktiven Grafiken mache.
Ich stelle mir das optimaler Weise so vor:
ich hab eine php Seite oder jsp, in der ein Bereich durch Java funtkioniert (wie z.B. bei map24, da hat man doch auch html, bzw jetzt ajax und da eingebaut ist ein grafischer Java-Bereich, oder versteh ich da was total falsch?).
Der java-Bereich auf der Webseite muss halt mit dem front-controller auf dem Server kommunizieren.

Kann ich also ein applet in die Seite einbetten (bzw eine WebstartApp), welches mit dem Server kommuniziert? Und was liegt dann auf dem Server? EJB, JavaBeans?

Sorry dass ich so ins Blaue fragen muss, aber ich steh halt noch am Anfang meiner Reise, was das angeht und J2EE ist so umfangreich, dass ich gerne erstmal wissen muss, in welche Richtung ich genau recherchieren muss.

Vielen Dank

Rodion

 

[robertpic71]

Wie schon oben gesagt: Am wenigsten Aufwand wahrscheinlich ein Applet bzw. die Webstartlösung. Wobei man da unter Umständen schlechter/gar nicht an die Serverdaten rankommt (z.B. Datenbank) und die Serverkommunikation via Webservice machen muss.

Wie du schon erkannt hast, wäre auch eine gemischt Applet/Html-Lösung ala map24 möglich.

Eine weitere Möglichkeit wäre HTML + Javascript/Ajax für den Browser zu verwenden. Ein Drag&Drop ist mit Ajax drinnen. Ich kenne deine Anwendung nicht - aber möglicherweise kommt man auch mit Ajax ans Ziel. Je nach Anforderung muss man nicht zwingend Javascript erlernen - es gibt ja auch schon einige fertige Ajax-Componenten (wie z.B. Goolge Maps, FCKEditor...) und Java-Ajax-Frameworks (z.B. ZK).

Ob das wirklich eine Option für dich ist, hängt aber stark von dem ab, was deine Anwendung tun soll.

 

[rodion311]

wie gesagt, meine ganze App als Applet umzuschreiben oder als webstart-app auszuliefern funktioniert glaube ich nicht, wegen dem Speicherbedarf von >64 MB

ich glaube dann muss ich irgendsoetwas wie folgt machen:

applet+ rmi+ serverkram?
webstart + rmi+ serverkram? (wenn das geht)

wie sieht denn dann die Serverapplikation aus?

meine grapfiksachen sind flussdiagramme, die man verändern kann, die sachen habe ich mit jgraph gemacht, was ich gerne weiter verwenden würde.

beste Grüße

 

[SnooP]

als webstart-app ... würde ich schon sagen wegen speicher, da kann man doch auch ganz gut konfigurieren, oder?... - aber wenn du interaktive grafiken generierst... dann würde ich doch eher in richtung applet - sprich hybride lösung gehen...
RMI kann man dann natürlich verwenden... evtl. wären webservices aber sogar schöner an der Stelle... - die Serverapplikation - naja ... das ist halt dann das Backend, ich weiß ja nicht, wie das bei dir aussieht, was da gemacht werden muss etc. - wie doll die Berechnungen tatsächlich sind - ober ob das ganze primär GUI ist, veränderbare Flussdiagramme z.B. ist ja GUI-pur was man natürlich auch mit AJAX und Co. schwer nachbauen könnte... - also geht sicher alles, aber ich bezweifel mal ganz stark, dass das so ne einfache Geschichte werden könnte - zumal du dich ja dann auch erstmal in zich sachen einarbeiten müsstest...

 

[rodion311]

naja mein prog ist schon etwas mehr als gui, also da gibt es schon ein wenig zu tun für den Server, bis die diagramme in der gui auftauchen.

Das es nicht trivial werden würde, hatte ich schon gedacht. Mir ist auch klar, dass das sehr zeitaufwändig wird, gerade weil ich mich extremst in das ganze J2EE Universum einarbeiten muss. Deshalb hab ich hier auch so ins Blaue gefragt, damit ich Tips bekommen kann, auf was ich mich bei der Einarbeitung stürzen muss.

Also was ich bisher gelesen habe, was glaub ich möglich wäre:

applet + sockets + serverApp
appplet + rmi + serverApp
applet + rpc+ serverApp
applet + soap + serverApp
applet + xml(jax-ws) + web services
applet+ jakarta httpClient+ irgendwas

was ist denn da zu empfehlen?
ich würde ja fast denken, dass variante 1 und 2 am ehesten sinn machen, damit es für mich nicht der overkill ist.

Und ach ja, es geht um keine anwendung, bei der 1000 leute gleichzeitig arbeiten können müssen (ca 30 gleichzeitig). Webservices können ja von allen clients in allen Sprachen angesprochen werden, das brauch ich auch nicht unbedingt, ich will nur, dass meine java applets oder apps mit dem Server kommunizieren.

Vielen Dank für die unermüdlichen Antworten

rod