Error cleaning up agent threads und WeakReference...

[flaite]

Das einzige Risiko bei rmi sehe ich in firewall Problemen (rmi port nicht offen).
Man kann das heute aber über http oder sogar ssh tunneln (http://www.pankaj-k.net/archives/2003/11/rmi_over_ssh.html).

Ansonsten ist rmi an vielen Stellen gut dokumentiert. Zb. im Handbuch der Javaprogrammierung (www.javabuch.de). Mit der Vor-Vor-Vorgängerversion hab ich das mal vor 5 Jahren aus Domino heraus gemacht. Der Aufbau ist erst einmal ein bischen fricklig. Geht aber.

[flaite]

Ansonsten wird das in Kapitel 46 der Version 3 von Javabuch.de ausführlich beschrieben.
Im Kapitel davor (45) wird Socket-Programmierung beschrieben.
Das sind die beiden Alternativen.
Falls du irgendwo hängen bleibst, kannst du ja posten.

[Mark³]

ich versuche das mal mit Socket-Programmierung.

Ausgehend vom Webserver-Example aus Javabuch (4. Auflage, Kap. 45.3.3) erstelle ich eine simple Server-Anwendung

Code

import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;

public class Server {
	/**
	 * @param port
	 *            the port which the server is listening to
	 */
	public static void main(String[] args) {
		{
			if (args.length != 1) {
				System.err.println("Usage: java Server <port>");
				System.exit(1);
			}
			try {
				int port = Integer.parseInt(args[0]);
				System.out.println("Listening to port " + port);
				int calls = 0;
				ServerSocket httpd = new ServerSocket(port);
				while (true) {
					Socket socket = httpd.accept();
					(new ClientThread(++calls, socket)).start();
				}
			} catch (IOException e) {
				System.err.println(e.toString());
				System.exit(1);
			}
		}
	}
}

die auf eingehende ClientThreads wartet:

Code

import java.io.IOException;
import java.io.InputStream;
import java.io.PrintStream;
import java.net.Socket;

public class ClientThread extends Thread {
	private Socket socket;

	private int id;

	private PrintStream out;

	private InputStream in;

	public ClientThread(int id, Socket socket) {
		this.id = id;
		this.socket = socket;

	}

	public void run() {
		try {
			System.out.println(id + ": Incoming call...");
			out = new PrintStream(socket.getOutputStream());
			in = socket.getInputStream();
			readRequest();
			createResponse();
			socket.close();
			System.out.println(id + ": Closed.");
		} catch (IOException e) {
			System.out.println(id + ": " + e.toString());
			System.out.println(id + ": Aborted.");
		}
	}

	private void createResponse() {
	}

	private void readRequest() throws IOException {
	}

}

Nun würde ich in readRequest() Befehle parsen, mit denen ich Transaktionen in Openview ausführe. Die Ergebnisse der Transaktionen gebe ich dann per createResponse() wieder an den Caller zurück. Der Caller wäre in diesem Fall ein Notes Java-Agent.

Irgendwelche Vorschläge, wie man am besten Befehle parsed oder Objekte zwischen readRequest() und createResponse() austauscht?
Im Webserverbeispiel wird natürlich Text ausgelesen da ja normalerweise URLs geparsed werden. Ich könnte Klartextbefehle ('Create Servicecall', 'Axel Janssen', 'Netzwerkprobleme, kein Anschluß ans Netz') nehmen, aber ich möchte möglichst wenig selber parsen. Leider habe ich da kaum Erfahrungen, was in Java so gebräuchlich ist. Mit StringTokenizer oder Vector() oder so kann man das ja recht flexibel machen.

[flaite]

Hätte RMI genommen, aber ich schau heute abend mal nach.
Das Problem besteht darin, dass du quasi irgendwann anfängst ein eigenes Protokoll zu designen, wenn die Anforderungen zu komplex werden. Das sollte auf jeden Fall vermieden werden.
Was spricht einfach dagegen einfach einen Tomcat als Server für die OpenView Geschichten zu nehmen?
- Von Notes kann das per jakarta.commons.HttpClient gut angesprochen werden. OpenView-Methodennamen, HttpParameter sind HttpPost-Felder.
- Servlet-Programmierung kannst du. Die Business Logik der OpenView Geschichten wird vom Servlet aufgerufen.
- Du generierst einfach xml als Response.

Gruß Axel

[Mark³]

wahrscheinlich ist Tomcat die einfachste Lösung, sonst komme ich vom Hundertsten ins Tausendste...

Ich habe bloß noch ein Problem, mir das gesamte Bild vorzustellen, da ich bei Webanwendungen immer die Webseiten vor Augen habe, die ich im Client öffne. Dann könnte ich doch eigentlich den ganzen Kram sogar über AJAX ansprechen
Allerdings ist das mit http und unseren Firewalls so eine Sache hier.
Angenommen ich habe einen Tomcat, dann erstelle ich ein J2EE-Projekt und stecke die Logik nicht in JSPs sondern nur in Servlets, die ich dann per Lotusscript- oder Javaagent anspreche?

[Ralf_M_Petter]

Ich glaube jetzt kommst du in ein falsches Fahrwasser. Man sollte nicht mit Kanonen auf Spatzen schiessen.

Ich würde es ganz einfach und effektiv lösen wie z.B. auf dieser Seite beschrieben.

http://java.sun.com/docs/books/tutorial/networking/sockets/clientServer.html

Grüße

Ralf

[Mark³]

das ist immer das Blöde, wenn man keine Übersicht hat. Sicher kriege ich alles irgendwie hin. Welche der zig Lösungen aber am schnellsten zum Ziel führt kann ich überhaupt nicht abschätzen...

[flaite]

Marc,

wieso Ajax? Du musst einfach mit jakarta.commons.HttpClient einen HttpRequest zusammenbauen, abschicken und synchron auf die Antwort warten.
Diese Antwort dann parsen.
Mach einfahc die Augen zu und bitte deinen Nachbarn ein paar Webseiten aufzurufen. Stelle dir dann die einlaufenden Antworten im Browser als Streams von Bytes vor 


Ralf,

Die Frage ist was hier die Kanonen sind. Ist es bei diesem Argument eigentlich immer.

ist nicht in Wirklichkeit die Implementierung dieses (Originalzitat) KnockKnock Protokoll schwieriger ist als Tomcat einzusetzen?
Denke an Errorhandling. Information der Administratoren. Und und und. 

Vor allem wenn die in der Organisation schon Erfahrungen mit Tomcat haben.
Für die Administratoren ist es einfacher.
Für die Maintainer ist es einfacher.
Erweiterungen sind einfacher.
Vielleicht kann man später Dinge nutzen, die schon in Tomcat implementiert sind.

Eingebettete Tomcats werden btw völlig ernsthaft als Komponente für Standalone Anwendungen verwendet. Zb. bei der Hilfe deines Eclipse/WSAD.

Gruß Axel 

[flaite]

Das letzte was ich mit apache.jakarta.httpClient gemacht habe war das verarbeiten der xml Datei über die Referenz-Wechselkurse, die täglich von der Europ. Zentral Bank (ECB) als xml veröffentlicht wird.
Jeden Tag um 15:00 Uhr wird eine Methode aufgerufen, die diesen Prozess anstösst.
Funktioniert echt ziemlich problemlos.

Theoretisch hätte ich auch das Programm auf der Seite der ECB schreiben können, dass diese Referenz-Wechselkurse erzeugt.

Da ich mich damit ganz gut auskenne, wäre das vielleicht ein Beitrag für "Show it on Thursday".

Ich kapiere das Problem nicht.

[Mark³]

Ich kapiere das Problem nicht.

Das Problem ist, dass ich nur für diese Anwendung einen Tomcat aufsetzen müsste. Natürlich muss ich mit der anderen Lösung auch nur für diese Anwendung meinen selbstgebauten Socket-Server aufsetzen (und sogar noch programmieren) aber ich verfolge erstmal diesen Weg weiter, da ich sowas auch noch nie gemacht habe. Wenn meine Lösung einfach bleibt kann ich sie evt. auch an anderen Standorten von uns implementieren lassen. Einen Tomcat-Server aufzusetzen ist dort schwieriger durchzusetzen als eine kleine Javaanwendung laufen zu lassen. Aber DIE gute oder DIE schlechte Lösung gibt es hier sowieso nicht.

[Mark³]

irgendwie bin ich zu blöd für die Socket-Geschichte...

Ich habe nun einen Server, der bei einem eingehenden Aufruf einen Clientthread startet, den ich von einem Notesagenten starte. Leider klappt der Ablauf Client schickt was, Server antwortet irgendwie nicht.

Im Clientthread lese ich den InputStream mit

Code

StringBuffer sb = new StringBuffer(255);
int c;
while ((c = in.read()) != -1) {
		sb.append((char) c);
}

Dies ist komischerweise eine Endlosschleife wenn ich vom Client aus dies sende:

Code

String s = "argument1#argument2";
out.write(s.getBytes());

Wenn ich aber out.close() mache dann läuft mein ClientThread weiter 
Zum parsen zerlege ich den StringBuffer.ToString mit dem StringTokenizer. Beim Prüfen der Werte .equals etc hänge ich auch noch fest 

Evt. fehlt

Code

out.write('\r');
out.write('\n');

bei meinem Client?

[Ralf_M_Petter]

Hallo Mark!

Warum arbeitest du nicht wie in dem Tutorial mit Readline? Im Tutorial ist doch genau deine Anwendung beschrieben. Du brauchst Sie nur herunterladen und die KnockKnock Protocol Klasse abändern. Am einfachsten wäre es wenn du als Kommunikation unr die Universal ID's der Dokumente schickst die überarbeitet werden und du diese dann in deinem Server abarbeitest.

@Axel. Für mich ist Tomcat für so eine mini Sache auf jeden Fall zu groß. Das ganze soll ja dann auch noch perfromant laufen und nicht unbedingt HSP Ende nie fressen. Ausserdem ist so ein kleiner Client viel leichter zu deployen und birgt auch nicht das Risiko, dass ich mir Sicherheitslücken einfange die irgendwo im Tomcat stecken.

Grüße

Ralf

[flaite]

Welche Sicherheitsprobleme?
Man braucht den Server ja nicht gegenüber dem Internet zu öffnen und ausserdem hat doch gerade Tomcat eine Menge an Sicherheitsmechanismen wie Authentifizierung, Autorisierung, SSL, uvam bereits implementiert.

Und wie sicher ist bitte der selbstgeschriebene Server?
Es ist doch eindeutig schwieriger dort Sicherheit zu implementieren.

Also so blöd finde ich die Idee mit Tomcat (oder Jetty) gar nicht. Wie gesagt: Beides kann in eine Anwendung embedded werden.

[flaite]

Hab jetzt die KnockKnock Plattform mit Hilfe von Eclipse implementiert.
Ist einfach.
Die 3 Dateien KnockKnockServer, KnockKnockClient und KnockKnockProtocol in 1 Projekt kopieren und kompilieren.
In KnockKnockClient muß man noch die Zeile
kkSocket = new Socket("taranis", 4444);
in
kkSocket = new Socket("127.0.0.1", 4444);
umändern.
Oder dein Server kann per http mit taranis angesprochen werden :-)

Dann die class Datei von Client irgendwohin exportieren.
Den Server in Eclipse starten (geht natürlich auch im debug modus).

Den Client auf der Festplatte von der cmd box aus starten.
Dann wie beschrieben in der Sun Doku.

In jedem Fall ist das Protokoll zu kompliziert. Du benötigst vermutlich nur einen einfachen Command (mit Parametern), der von Notes an den Server geschickt wird und dann schickt der Server die Antwort runter. Die naivste Lösung wäre:
-> Name des Command und jeder Parameter als String, getrennt durch (z.B.) ~. Geht mit Primitivtypen und Strings problemlos. Besser sind imho serialisierte Objekte.

Wenn ich das jetzt richtig verstanden habe, dann verwendet Mehran Habibi in seinem Buch zu Sun Java Dev Examen ein serialsiertes Command Objekt. Dieses wird vom Client an den Server geschickt. Und ich denke, dass dies ein vernünftiger Ansatz ist. Kommt bestimmt noch was von mir zu, wobei ich nicht weiss ob noch heute abend.

Zumindest zeigt das sun beispiel wie es geht. Es ist aber z.B. nicht multithreaded. D.h. es kann immer nur eine Sitzung zu einem User aufmachen. Auch dafür gibts bei Mehran Habibi eine Lsg.

Gruß Axel

[Ralf_M_Petter]

Hallo Axel!

Zur Ergänzung, in dem Tutorial ist auch der Link auf den Multithread source.

Grüße

Ralf

[Mark³]

euer Engagement ist großartig, ihr habt wahrscheinlich beide eine fertige Lösung bevor das bei mir läuft 

Im Prinzip nehme ich ja das KlopfKlopf-Protokoll, nur dass ich das nicht in einer extra Klasse ausgelagert habe. Ich möchte natürlich auch gerne verstehen, was ich tue. Und in allen Beispielen, die ich irgendwo gefunden habe, wird ein InputStream in einer while-Schleife ausgelesen:

Code

while ((c = in.read()) != -1) {
     sb.append((char) c);
}

Wieso ist das dann bei mir eine Endlos-Schleife? Sind alle Beispiele so stark vereinfacht? Oder läuft das nur, wenn die Gegenseite den dazugehörigen Outputstream mit einem Textprompt füllt und nicht programmatisch?
Natürlich läuft es bei mir, wenn ich auf der Gegenseite (im Notesagenten) outputStream.close() mache, aber das habe ich nirgendwo so gesehen.

Die Notesdokument-UID möchte ich übrigens nicht übergeben, da ich meine Mittelschicht gern unabhängig von Notes bauen möchte. D.h. der Server kennt bestimmte Befehle, die dazugehörige Anzahl von Parametern verlangen und gibt dann passende Antworten zurück. So kann ich das Tool dann auch von Nicht-Notesanwendungen nutzen.

[Mark³]

und multithreaded brauch ich natürlich auch, sollte bereits drin sein. Ich muss aber noch die maximale Anzahl von parallelen Threads einbauen da Openview nicht beliebig viele Verbindungen mit dem gleichen User erlaubt.

Multithreading:

Code

ServerSocket httpd = new ServerSocket(port);
				while (true) {
			Socket socket = httpd.accept();
	(new ClientThread(getOVSession(ovserver, ovuser, ovpw), ++calls, socket)).start();

[Mark³]

ich glaube ich habe meinen Fehler gefunden: Ich benötige überhaupt gar keine while-Schleife im Client oder ClientThread, da der Ablauf der folgende ist:

1. Client C öffnet Socket zum Server
2. Server erstellt neuen Clientthread CT1
3. C schickt eine Zeile mit einem Befehl und Parametern zum CT1
4. CT1 führt den Befehl in Openview aus und schickt eine Zeile als Antwort zurück zu C
5. C empfängt die Antwort und schließt den Socket, daadurch beendet sich CT1

So einfach ist das. Und läuft.
Das ist eben der Nachteil am Cut&Paste programmieren, solange man den Code nicht wirklich versteht passieren oft unerwartete Sachen 

[Mark³]

was natürlich ohne die Schleife nicht mehr funktioniert:

Ich kann nicht mehr während einer Client-Sitzung mehrere Befehle abarbeiten, was eigentlich ganz schön wäre. Also muss ich irgendwann doch mal das Problem lösen, wie Client und Server abwechselnd miteinander reden können ohne endlos auf den Abschluss der Eingabe zu warten.
In den Beispielen wurde ja immer System.in o.ä. genutzt und da merkt die Gegenseite scheinbar wann die Eingabe beendet ist (nach einem Enter also \r \n wahrscheinlich). Ich kann dann wohl ein Steuerzeichen definieren, welches die Kommunikation jeweils begrenzt (z.B. ~) da ein im String vorhandenes \n nicht klappte...

[flaite]

Bei mehreren Befehlen würde ich im Namen der Einfachheit für jeden Befehl eine neue Verbindung aufbauen.