Java Server mit verschiedenen Kommunikationsmöglichkeiten

[mmp]

Hallo,

Nachdem ich jetzt schon lange erfolglos gesucht habe, hab ich mich jetzt dazu entschlossen das problem hier zu posten.
Die Idee ist, dass mein Server verschiedene Möglichkeiten der Kommunication unterstützen soll. Zum Beispiel soll er sowohl über xml, jxta etc. kommunizieren können. Jetzt sitze ich hier und versuche dafür eine einfache und leicht erweiterbare lösung zu finden.

Eine möglichkeit wäre sicher für jedes Kommunikationsmöglichkeit einen eigenen Port zu reservieren, was ich allerdings etwas unschön finde.

Bin für jegliche Diskussion, Vorschläge dankbar

mfg mmp

 

[tuxedo]

Das Schlüsselwort "Interface" sagt dir was, oder etwa nicht?

 

[mmp]

naja, schon klar wie ich objekt kapselung und ersetzbarkeit erziele. Mir isses hier eher um architekturprobleme gegangen. Das im Grunde alles über Interfaces gezogen wird, ist ja wohl selbstverständlich.
Die Frage war ob es eine elegante Lösung gibt, wie ich es schaffe, dass der gesamte Server auf einen Port horcht, aber sowohl verschiedene Protokolle auf verschiedenen Transports unterstützt. (siehe Axis)

mfg mmp

 

[tuxedo]

Sorry, aber dann hattest du deine ursprüngliche Frage zu ungenau gestellt.

Wenn du nur einen Port offen haben willst und darüber verschiedene Kommunikationsarten fahren willst, dann frage ich mich zwangsläufig: Ist RMI eine Option? Wenn ja: Dann wird's aufwendiger. Da reicht es ja nicht das Protokoll zu wechseln.

Wenn es dir aber prinzipiell um eine Socket-Kommunikation geht, die verschiedene Protokolle unterstützt lautet meine Antwort wieder erstmal: Interfaces als Plugin-Konzept für Protokolle ;-)

Vielleicht kannst du näher erläutern was für Protokolle genutzt werden sollen und was für eine Kommunikationstechnik eingesetzt werden soll (Sockets, RMI, ...).


- Alex

 

[tuxedo]

Ah, ich glaub ich versteh worauf du hinaus willst. Du willst nicht das Protokoll hin und wieder mal austauschen, du willst einen Server haben den mehrere Protokolle über einen Port gleichzeitig kann... ?!

Wenn ich also richtig liege, dann kannst du die Protokolle doch nochmal in ein MasterProtokoll verpacken, damit der Server anhand der Header-Daten im MasterProtokoll weiß wie er die Daten auspacken muss (XML,...).

Das würde allerdings heißen dass deine Clients da mitspielen müssen.

Ansonsten weiß der Server ja nicht wie er die Daten jetzt behandeln soll.

Du könntest auch nen zweiten Port öffnen und den als SteuerPort nehmen: Die Clients teilen dem Server über diesen Port mit, welches Protokoll sie verwenden.

- Alex

 

[mmp]

Sehr gut, jetzt können wir diskutieren . Sorry, dass ich mich im ersten Post etwas unbeholfen ausgedrückt habe. Prinzipiell hast du genau meine Probleme jetzt angesprochen. Prinzipiell sollte es möglich sein, egal welches Protokoll + Transport einzubauen -> Interfaces. Das Problem hierbei ist natürlich herauszufinden was jetzt der Client für eine Sprache spricht. Das mit dem Steuerungsport ist ansicht keine schlechte Idee. Kritisch/schwierig wird es dann wenn wir uns in einer eher Service orientierten Architektur befinden. Da sollte der "Client" ja nichts vom Server mitbekommen und daher fällt diese Möglichkeit auch leider mehr oder weniger weg.

Die Schachtelung um ein weiteres Protokoll wird auf Grund des bereits fixierten Protokolls leider nicht möglich sein. Ich hätte da noch an eine Art des PreParse gedacht. Also, dass der Server soweit den Request zerlegt, bis er weiß welches Protokoll das ganze ist, wobei mir das auch sehr schwierig erscheint.
Der Overhead beim erst Aufbau der Verbindung ist eher zu vernachlässigen, da ja dann davon ausgegangen werden kann, dass ein Client im Grunde immer nur über ein Protokoll kommuniziert.

Mir fehlt leider zur Zeit, wie schon gesagt, eine gute architektonische Struktur die eben leicht erweiterbar ist.

mfg mmp

 

[tuxedo]

Naja, so wie du es formulierst bleibt dir ja nur eine Möglichkeit: Dynamisches erkennen des eingehenden Protokolls.
Ob es dafür schon was fertiges gibt: Gute Frage. Und auch kommt es drauf an was für Protokolle da unterstützt werden sollen. Es gibt sicher auch "primitive Protokolle" die keinen großartigen Header haben und somit von mal zu mal anders aussehen (Beispielsweise so ein simpler Paketaufbau wie: irgendeineId + Paketlänge + Rohdaten, alles ohne extra Header).

Wenn du die Clients auch unter deinen Fittichen hast, dann könntest du, statt den Steuerport zu realisieren, einfach vor dem eigentlichen Übertragungsbeginn eine Protokoll-ID senden, so dass der Server wieder weiß wie er reagieren muss. Wobei der Client da ja schon wieder in gewisser Weie Kenntnis vom server haben muss.

Wenn der Client gänzlich unverändert bleiben muss, dann bleibt ja eigentlich nur noch das "erahnen" des Protokolls.

Aber vielleicht ist das alles auch überflüssig weil es schon was fertiges gibt. Wie dem auch sei: Mir ist nix in der Art bekannt.

Finde die Idee aber eigenbtlich ganz interessant. Für Protokolle die sich auch identifizieren lassen ist das mit sicherheit recht gut realisierbar. Um das ganze "erweiterbar" zu machen müsste man so eine Art "Regular Expression" für die Protokolle definieren und dann auf den eingehenden Datenstrom anwenden.

- Alex