# Viele Clients ein Server



## Rahmspinat (27. Jan 2011)

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 (27. Jan 2011)

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


----------



## tfa (27. Jan 2011)

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 (27. Jan 2011)

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


----------



## Rahmspinat (27. Jan 2011)

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 (1. Feb 2011)

Rahmspinat hat gesagt.:


> 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 (2. Feb 2011)

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 (2. Feb 2011)

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 (2. Feb 2011)

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


----------

