# Langlebige Berechnungen auf Server ausführen



## musiKk (10. Mrz 2009)

Guten Tag,

ich hatte jetzt die Ehre, mich auch mal auf die Enterprise-Ebene zu begeben und fühle mich wie am ersten Tag Java. Aber man wächst ja mit seinen Aufgaben...

Die Anforderung ist ein WebService (im Moment auf Geronimo), über den man auf der Servermaschine Jobs starten kann. Das kann absolut alles sein, Sachen im Dateisystem, Datenbankoperationen, völlig offen. Das habe ich über eine Plugin-Engine gelöst. Für die Jobverwaltung habe ich einen JobManager, der die ganze Threadverwaltung durchführt. Nicht schlagen, alles natürlich Singletons, irgendwie muss ich bei verschiedenen Requests ja wieder an die Referenzen kommen. Und Plugin- respektive JobManager sollen auch nur einmal existieren. Das klingt für die Experten sicher schon wieder grausam, aber das sind halt meine ersten Schritte, da ist noch fast alles POJO. Die Jobs können durchaus ne Weile dauern und der Client soll zwischendurch immer mal nachfragen können, ob das Ergebnis inzwischen fertig ist oder nicht.

Das Projekt ist nicht so groß, darum kann man da recht schnell viel umschreiben. Da ist halt meine Frage: Wie würde man das von der Architektur her gescheiter machen? Es läuft im Moment zwar und ich würde auch sagen, sehr gut, aber vom EE-Standpunkt ist das sicher gar nichts. Ich versuche mich auch in die EJB-Thematik einzuarbeiten (ich weiß nichtmal, ob das hier relevant ist, überall nur Akronyme und Buzzwords...), aber das fällt mir auch nicht so einfach. Gerade, wenn ich z. B. lese, dass eine EJB java.io.* nicht verwenden darf. Die Plugins liegen als JARs auf der Platte, irgendwie muss ich die doch lesen können?

Vielleicht kann mir der ein oder andere einen Denkanstoß geben.

Danke schonmal
mK


----------



## grischan (21. Mrz 2009)

Grundsätzlich ist das nicht falsch was du da machst. Die Sache mit dem java.io ist besonders auf Portabilität zurückzuführen. Die jeweiligen Jobs müssen bei dir bestimmt ein Interface implementieren (oder eine abstrakte Klasse erweitern). Du könntest dann jedes plugin als eigenes EAR bereitstellen lassen, welches seine "Hauptklasse" über JNDI nach außen bereitstellt und der JobManager hollt sich die Klasse über einen JNDI-Lookup (Damit wärst du die java.io Beziehung los, weil das Lesen der JARs nun der App-Server übernimmt.)
Nur das Polling der Clients würde ich nicht durchführen. Gib den Clients doch ein WebService- (oder anderes Remote-)Interface, über welches der JobManager sie benachrichtigen kann, wenn der Job abgeschlossen ist. Oder nimm eine MQ-Anwendung um beide Seiten zu entkoppeln.


----------



## maki (21. Mrz 2009)

> Für die Jobverwaltung habe ich einen JobManager, der die ganze Threadverwaltung durchführt.


Dir ist klar dass du auf einem ApplicationServer keine Threads selber starten darfst?



> Gerade, wenn ich z. B. lese, dass eine EJB java.io.* nicht verwenden darf.


java.io darfst du beuntzen, aber eben keine File Operationen aus java.io.
Wobei manch AppServer  das zwar erlaubt, ist aber schlecht wenn man irgendwann dann einen Cluster aufziehen will.


----------



## musiKk (22. Mrz 2009)

Danke für die Ratschläge.



grischan hat gesagt.:


> Die jeweiligen Jobs müssen bei dir bestimmt ein Interface implementieren (oder eine abstrakte Klasse erweitern).



Richtig.



> Du könntest dann jedes plugin als eigenes EAR bereitstellen lassen, welches seine "Hauptklasse" über JNDI nach außen bereitstellt und der JobManager hollt sich die Klasse über einen JNDI-Lookup (Damit wärst du die java.io Beziehung los, weil das Lesen der JARs nun der App-Server übernimmt.)



Ok. Wie gesagt, ich bin noch im kalten Wasser, darum kann ich die Möglichkeiten, die man hat, noch nicht richtig einschätzen. Ich werde mich in der Richtung mal umschauen.



> Nur das Polling der Clients würde ich nicht durchführen. Gib den Clients doch ein WebService- (oder anderes Remote-)Interface, über welches der JobManager sie benachrichtigen kann, wenn der Job abgeschlossen ist. Oder nimm eine MQ-Anwendung um beide Seiten zu entkoppeln.



Da hatte ich auch schon dran gedacht. Diese Entscheidung liegt aber vermutlich nicht bei mir. Ich hatte sonst noch als Mittelweg in Erwägung gezogen, dass ein Job seine voraussichtliche Restzeit angeben kann, sofern das abschätzbar ist.



maki hat gesagt.:


> Dir ist klar dass du auf einem ApplicationServer keine Threads selber starten darfst?



Wie gesagt, ich bin mir bewusst, dass das nicht so toll ist. Ich kann vieles schlicht noch nicht einschätzen und/oder umsetzen. Ich bin mir z. B. immer noch nicht im Klaren, wie ich "legal" Aufgaben im Hintergrund starte, die auch mal ein paar Stunden dauern können.


----------



## maki (22. Mrz 2009)

> Wie gesagt, ich bin mir bewusst, dass das nicht so toll ist. Ich kann vieles schlicht noch nicht einschätzen und/oder umsetzen. Ich bin mir z. B. immer noch nicht im Klaren, wie ich "legal" Aufgaben im Hintergrund starte, die auch mal ein paar Stunden dauern können.


Da helfen ohl nur sog. Message Driven Beans.
Denn selbst wenn du norm. SessionBeans (Stateless/Stateful) wird der Timeout immer ein Problem sein.


----------



## musiKk (23. Mrz 2009)

Gut, danke für das Stichwort. Dann werde ich mich mal nach entsprechender Literatur umsehen.


----------

