Welche "Technologie" würden Sie vorschlagen, um eine Art von Nachrichten zwischen einem Java-Server und mehreren in C#, Javascript und Java geschriebenen Clients auszutauschen?java server <-> C# + javascript + java + * clients
Die Hintergrundgeschichte:
In unserem aktuellen Projekt versuchen wir, einen generischen UI-Backend in Java (läuft auf dem Server), die „überbrückte“ dann mittels in mehr UI-Frontends zu bauen von verschiedenen UI-Adaptern (die auf dem Client, dem Server oder beiden ausgeführt werden). Während unsere Servertechnologie immer Java sein wird, wird es C# (Silverlight), JavaScript und Java Clients geben. Vielleicht noch mehr in der Zukunft (verschiedene Smartphones, Tablets).
Das UI-Backend und die UI-Frontends kommunizieren über eine Reihe von mehr oder weniger einfachen Nachrichten (meist Name/Wert-Paare), die jeweils eine bestimmte Eigenschaft/Status/Datenänderung auf dem Client bzw. Server kapselt. Innerhalb eines einzigen Anfragezyklus werden mehrere solche einfachen Nachrichten zu einer großen Nachricht zusammengefasst, die dann vom Backend an das Frontend oder umgekehrt übergeben wird. Im Moment erfolgt das Senden und Empfangen von Nachrichten an einem einzigen Eingangspunkt auf dem Client sowie auf dem Server. Es werden also keine Servermethoden als WebService etc. angezeigt - einfach weil das in unserem Fall definitiv zu langsam wäre.
Unser aktueller Prototyp besteht ausschließlich aus einem Java-Server, einem Java Desktop Client (Swing) und einem Java Web Client (Vaadin). Die Nachricht, die zwischen dem Backend und dem Frontend ausgetauscht wird, ist effektiv eine Liste von POJOs (die jeweils eine spezifische "Änderung" repräsentieren), die zu/von XML serialisiert/deserialisiert sind. So weit, ist es gut.
Jetzt kommen C# und Javascript auf den Tisch. Da wir mit jeder Art von Objekt in jeder Technologie arbeiten wollen, dachten wir, es wäre eine gute Idee, die Nachrichten/Änderungen/Pojos in einer Art abstrakter Sprache zu spezifizieren und dann Objekte für jede Zielsprache zu generieren. Irgendwann könnten diese Objekte dann serialisiert/deserialisiert und über die Leitung gesendet werden (wahrscheinlich über http/s). Zu diesem Zweck haben wir an die Protokollpuffer von Google oder Thrift gedacht. Was denken Sie?
Für den Moment ist unser synchroner Anfrage-Antwort-Zyklus ausreichend, aber wir werden bald eine asynchrone Anfrage-Antwort bzw. einen Server-Push benötigen. Aus diesem Grund haben wir uns vorgenommen, so etwas wie ActiveMQ zu verwenden. Was denken Sie? Zu viel? Wenn nicht, wie können wir die oben erwähnte Objekterzeugung erreichen (xsd, jaxb,? Für js)? Gibt es bessere Wege? Ich habe ActiveMQ noch nie benutzt, aber laut der Website sollte es mit Java, C# (Spring.NET) und irgendwie auch mit Javascript (STOMP) möglich sein. Allerdings scheint das für mich ziemlich komplex zu sein ...
Irgendwelche Tipps, Hinweise, Erfahrungen oder Kommentare zu diesem oder verwandten Themen wären wirklich hilfreich.
Vielen Dank im Voraus.
Wie gesagt, derzeit gibt es einen einzigen Einstiegspunkt auf dem Server/Client. Im Grunde kommt später die (HTTP-) Anfrage, in der mehrere Nachrichten eingekapselt sind, von denen jede einem POJO zugeordnet ist. Ich bin kein Experte in Webservices, aber nach meinem Verständnis müsste ich mehrere Methoden als Webservice (einen für jede Änderung/POJO) verfügbar machen, um die entsprechende WSDL dazu zu bringen, die Objekte in der Zielsprache zu generieren. Wahrscheinlich irre ich mich, aber das würde dann zu einer HTTP-Anfrage pro Änderung führen, die von Natur aus sogar langsamer als WS wäre. Und was ist mit WSDL und JavaScript? – Pauli
Sie können Ihren WS jedoch für Sie sinnvoll gestalten. Kein Grund, es müssen viele feinkörnige Anfragen sein. Es können ein paar komplexe Anfragen sein. Entwerfen Sie einfach Ihre Service-Eingabe und Ausgabe entsprechend. –