Brauche Ideen zur Umsetzung (JBoss Server <-> Client GUI)

C

chronos23

Grünschnabel
Hallo,

ich bräuchte von ein paar erfahrenen J2EE Entwicklern einen Rat bzgl. des besten Vorgehens bei einem Projekt.

Gegeben:
- bestehendes Projekt
- Einsatz von Threads und I/O
- 2 bis 4 GB Memory per Session
- wird zurzeit mit einer Config File gestartet
Ziel:
- Projekt für JBoss portieren
- Config File soll später durch GUI ersetzt werden

Da ich außer etwas EJB noch nicht mit JBoss gearbeitet habe, wollte ich fragen, wie ihr das am besten umsetzen würdet.
Meine Idee war, eine Schnittstelle zu schreiben mit der Funktion do(XMLString), diese dann zu deployen. Dann würde ich eine kleine GUI programmieren (Swing) und dann die do Methode per JNDI ansprechen. EJBs kommen funktionieren leider nicht, da ich Threads brauche.

Danke schon einmal für alle Antworten
 
Was heißt "bestehendes" Projekt? Ist das bereits eine Serveranwendung? WIe sieht die aus?

Threads sind eigentlich ein NoGo im J2EE Bereich. Wenn du Nebenläufigkeit brauchst musst /solltest du die Organisiation dessen dem AppServer überlassen. Das Zauberwort heißt Messaging in dem Bereich. Wie gesagt, entweder über den AppServer - oder halt von Hand.

Config in Richtung GUI. Wenn es eine Serveranwendung ist, bist du mit einem kleinen Webfrontend wahrscheinlich schneller am Ziel. Ansonsten bietet sich für sowas noch JMX an.

Umso mehr ich drüber nachdenke, finde ich, dass Spring die sinnvollere Alternative gegenüber EJB ist. Erstens ist die Plattform wesentlich leichter inkrementell in ein Projekt einzuführen, zum anderen viel breiter aufgestellt als EJB und weiterhin könnt ihr euren Code technologieunabhängig halten und die Asynchronität z.B. Vollständig hinter AOP Proxies verstecken.

Wie gesagt, man müsste Details erfahren um detaillierter Rat zu geben. Allerdings ist das sicher bestimmt nicht möglich ;).

Gruß
Ollie
 
Hallo,

danke schon einmal für die Antwort.
Bestehend bedeutet, dass es sich um eine Konsolenanwendung handelt. Zurzeit startet man das Programm mit einer Konfigurationsdatei, die wie eine Art Skript die einzelnen Aufgaben beinhaltet. Dort steht dann zum Beispiel Mache XYZ mit den Optionen abc, Mache XXZ mit den Optionen cug usw.
Diese Konfigurationsdatei soll nun durch eine GUI ersetzt werden, in der man zum Beispiel Mache XXZ anklickt, woraufhin dieser Prozess auf dem Server ausgeführt wird. Da das ganze auch noch Rückkopplungen haben soll (Log/Ausgabe etc.) wäre ein Grundansatz eigentlich eine typische Client / Server Anwendung per Socket bzw. in diesem Fall am besten per RMI.
Was mir "am liebsten" wäre, wäre folgende Option:
Ich habe eine Schnittstelle mit einer Funktion do(XMLString, ID), diese läuft unter JBoss, dazu gibt es dann noch einen Client (Swing), der per JNDI/RMI o.ä. verbunden wird mit der Schnittstelle, so dass ich einfach eine neue Instanz von dem Server erzeuge (AppServer server = new AppServer(ID) ) und dann auf dessen in dem Interface definierte Funktionen (server.do(...) ) zugreifen kann. Ich möchte mich wenn es geht nicht um den Datenaustausch kümmern müssen, sondern möchte eigentlich nur auf Methodenebene arbeiten.
 
Für den Anwendungsfall würde sich Spring durchaus als Lösungsplattform anbieten. Du kannst damit Services (einfache Javaklassen) einfach per Konfiguration auf der Serverseite per RMI exportieren und auf der Clientseite über einen Proxy konsumieren.

Ich weiß nicht, inwie weit du schon mit Spring gearbeitet hast, aber das wäre eine sehr elegante Lösung für das Problem. Was immer noch bleibt ist die Asynchronität der Abarbeitung. Da wirst du dann um einen MessageDriven Ansatz nicht herum kommen - Threads sind in Serverumgebungen definitiv tabu. Auch das ließe sich mit Spring implementieren. Dabei hast du dann trotzdem einfach einen Methodenaufruf
Code: 
public void doWork()
, der dann aber durch einen Proxy in eine MessageQueue geleitet wird und von einer anderen Komponente konsumiert. Wie gesagt, im Code ist das alles sehr transparent bzw. nicht zu sehen. Was du allerdings trotzdem brauchst ist das Verständis über die Technologien / Abläufe (JMS usw.)

Klingt aber nach nem interessanten projekt ;)
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück