Kommunikation zwischen Java und iSeries

[beegee]

Hallo an alle,

wir modernisieren unsere Anwendungen in Java und verwenden die DB2/400 als Datenbank. Weiters rufen wir auch per Socket Programme auf der iSeries auf (aus verschiedensten Gründen).

Meine Frage:
Die Programme, die über den Socket aufgerufen werden, werden auch submittet und arbeiten im Hintergrund.
Ich möchte jetzt, dass bei Ende so eines Jobs, dies dem Java-Job zurückgegeben wird, sodaß man in der Java-Anwendung dem User mitteilen kann, dass die Anwendung fertig ist (interaktiver Aufruf kommt aufgrund des Zeitaufwandes nicht in Frage).

Bin für Hinweise dankbar, wie man ein solches Service realisieren kann.

Lg

[RobertPic]

Wie ist denn der Socketserverteil auf der AS/400 realisiert - auch ein Javaprogramm?

Ich kann den Wunsch nicht ganz nachvollziehen. Da ich in Java Threads zur Verfügung habe, kann ein langer Aufruf ja parallel laufen.

Programme die nicht parallel laufen sollen, man man auch mit Javamitteln queuen. Das kann eine einfache Producer/Consument Lösung sein z.B. wie Consumer Producer Beispiel mit Java 5.0 - Java @ tutorials.de: Forum, Tutorial, Anleitung, Schulung & Hilfe
oder mittels JMS.

Wenn ich aus Java heraus 3GL-Programme (Cobol, CL, RPG von Casetool) aufrufen muss, mach ich das immer über SQL bzw. stored Procedures bzw. wenn ich keine Anwort brauche über DataQueues.

Ich habe hier eine Anwendung, bei welcher ein Java Socketserver auf der AS/400 läuft. Der Webshop startet seine Anfrage (Preise, Verfügbarkeit, offene Bestellungen...) via Socket (durch die Firewall) an den Socketserver, dieser schlüsselt die Anfrage auf stored Procedures um und sendet das Ergebnis über den Socket zurück.

Wenn man wirklich den Weg über Submit Job gehen will, würde es sich anbieten den Job mit Kürzel + Nummer (aus Nummernkreis) zu submitten und beim Submitjob eine bestimmte MessageQueue anzugeben. Diese könnte man abhorchen und aufgrund des Jobnames die Antwort zuordnen.
ABER: So eine Lösung würde ich nicht unbedingt anstreben.


/Robert

[beegee]

Danke für die Antworten:

naja, Java-Threads haben in dem Fall den Nachteil, wenn der Client sich verabschiedet, auch die Anwendung in der Luft hängt.

Wir denken jetzt in Richtung ApplicationServer, der auf der iSeries läuft.
Wenns interessiert, kann ich dann ja von der Lösung berichten.

Lg

[BenderD]

@LuftHängen: falls man da einen Timeout mitlaufen lässt sollte das kein Problem sein, rein RPG seitig gibt es da auch noch CEE4RAGE (ILE Exit Handler), damit kann man beim abnippeln des Jobs noch eine Aktion hinterherschieben.
@AppServer: falls ich euer Problem richtig verstanden habe, wollt ihr doch aus Java RPG aufrufen, sprich: Java ist Client und RPG benötigt einen Server Dienst? da hilft ein Java AppServer wenig!

D*B

Danke für die Antworten:

naja, Java-Threads haben in dem Fall den Nachteil, wenn der Client sich verabschiedet, auch die Anwendung in der Luft hängt.

Wir denken jetzt in Richtung ApplicationServer, der auf der iSeries läuft.
Wenns interessiert, kann ich dann ja von der Lösung berichten.

Lg

[beegee]

Ja, wir möchten vom Java-Programm ein iSeries-Programm submitten (bzw. ein CL-Programm aufrufen, welches submittet) und entweder gibt iSeries Bescheid an Java wenn Job fertig ist, oder Java-Client horcht bei iSeries, ob Job fertig ist.

[BenderD]

für "kurz" laufende Programme würde ich da stored Procedures vorziehen. Für Langläufer würde ich das auch asynchron entkoppeln und die Completion Message per DataQ oder MessageQ zurück senden. Aber ob du vom Aufrufer im selben Thread wartest, der aufgerufen hat, oder einen (zentralen) Listener hast, der auf die Antworten wartet, die Verhunger Problematik hast du immer identisch am Backen (und da bleibt nur Timeout oder ExitHandler)

D*B

Ja, wir möchten vom Java-Programm ein iSeries-Programm submitten (bzw. ein CL-Programm aufrufen, welches submittet) und entweder gibt iSeries Bescheid an Java wenn Job fertig ist, oder Java-Client horcht bei iSeries, ob Job fertig ist.