Viele Clients ein Server

[Rahmspinat]

Hallo Leute,

Ich habe einige Applikationen die an eine zentrale Applikation Informationen senden soll. Diese Applikation soll diese Informationen dann einzeln abarbeiten und wieder zurück senden.

Hat einer eine Idee wie ich das ganze am besten mache?

Wirklich wichtig hierbei ist das einzelne abarbeiten.

gruß Rahmspinat

 

[Tomate_Salat]

Ich würde hier RMI oder SIMON nutzen. Wäre wohl das einfachste.

 

[tfa]

Ich empfehle Remoting mit Springframework. Die verwendete RPC-Implementierung kann mal leicht konfigurieren.
Ein Beispiel mit RMI gibt es hier: http://www.java-forum.org/blogs/tfa/43-how-spring-remoting-rmi.html

 

[FArt]

Ich würde eine asynchrone API verwenden. JMS wäre praktisch oder JGroups.

 

[Rahmspinat]

Danke für die vielen Antworten.

dann muss ich wohl einiges ausprobieren... von RMI hab ich auch schon einges gehört.

Ist es denn möglich damit ein Server aufzubauen, der die Sachen dann einzeln (nicht parallel) abarbeitet?

 

[tuxedo]

Danke für die vielen Antworten.

dann muss ich wohl einiges ausprobieren... von RMI hab ich auch schon einges gehört.

Ist es denn möglich damit ein Server aufzubauen, der die Sachen dann einzeln (nicht parallel) abarbeitet?

Das ist so ziemlich mit jeder RPC Technik möglich und davon eigentlich total unabhängig:
Kannst die "Tasks" ja in einen Executor-Service Pool mit der Größe 1 stecken. Dann wird alles in eine Warteschleife eingereiht und von einem Thread nacheinander abgearbeitet.

 

[despikyxd]

jetzt mal bitte ganz erlich ... warum soll es seriel und nicht parallel abgearbeitet werden ?
ich glaube hier hast du ein kleines verständnis problem der klausel "nach ein ander abarbeiten"
falls es begründet ist eine parallelität zu vermeiden wäre es sicher sinnvoll und den grund zu nennen ... ansonsten sehe ich nämlich für diesen speziellen punkt keine verwendung

 

[tuxedo]

Na vielleicht bauen die Nachrichten auffeinander auf, oder bilden zusammen einen Context der nur dann korrekt ist, wenn die Reihenfolge stimmt.

Stell dir vor du willst mit einem Client einen Chat betreten, eine Nachricht schreiben und dich dann wieder ausloggen. Dann kann der Server die auslogg-Nachricht nicht vor dem Chat-Nachricht verarbeiten. Das wäre etwas "doof".

Okay, das Beispiel war jetzt extrem vereinfacht und simpel. Gibt aber dennoch genug Szenarien wo Nachrichten in einer definierten Reihenfolge abgearbeitet werden sollen. Und wenn der TS solche ein Szenario hat: Von mir aus. Das tut dem eigentlichen Titel dieses Threads keinen abbruch.

- Alex

 

[Rahmspinat]

Ich denke auch dass es eigentlich nix zur Sache tut, denn ich frage das ja nicht umsonst genau so, wie ich es frage.

Eine Sache hierbei ist, dass ich einen Service im Internet anspreche, den ich nicht die ganze zeit nutzen kann, weil ich sonst blockiert werde. Seriell mit einer kleinen verzögerung, funktioniert das wesentlich länger.

Gibt aber noch ein paar Gründe.

Das ist so ziemlich mit jeder RPC Technik möglich und davon eigentlich total unabhängig:
Kannst die "Tasks" ja in einen Executor-Service Pool mit der Größe 1 stecken. Dann wird alles in eine Warteschleife eingereiht und von einem Thread nacheinander abgearbeitet.

Danke für die Antwort tuxedo, ich denke das wird mir weiter helfen