javascript à l'interface java méthode distante

Question

Contexte:

Il y a quelque temps j'ai travaillé sur une application Java serveur-client (bâtiment était la portée automatisation). Après un premier essai, où nous avons écrit à la fois le serveur et le client en Java et les avons connectés via Java RMI (Remote Method Interface), nous avons trouvé que l'écriture du client en Javascript serait meilleure pour plusieurs raisons (je ne les donnerai pas ici , n'a pas d'importance).

Comme RMI ne fonctionne pas entre Javascript et Java, nous avons ensuite utilisé WebSockets pour les connecter et obtenir une connexion presque en temps réel. C'était il y a environ 3 ans, les websockets étaient encore en début de beta avec absolument aucune documentation et beaucoup de fonctions "pas encore implémentées". Pour la partie protocool, j'ai écrit quelque chose comme un RMI basé sur JSON. J'ai désérialisé les objets JSON provenant du client et interrogé ma propre application serveur en utilisant java.lang.reflection pour obtenir les méthodes que le client voulait exécuter.

Tout ce qui fonctionnait bien, je l'avais assez générique, donc je pouvais insérer d'autres sous-classes dynamiquement à l'exécution et mon RMI serait toujours en mesure d'y accéder.

TL; DR:

Je me demandais toujours s'il y a un moyen standard pour connecter java javascript quelque chose comme un RMI (comme d'avoir à étendre une interface et étant alors en mesure d'accéder à ces méthodes d'interface avec javascript) Je ne peux pas être le premier à avoir ce problème.

Pour moi: Je suis ingénieur électricien, donc les technologies Java, Javascript ou Web en général ne sont rien que j'ai apprises à l'université. Je sais de quoi je parle quand il s'agit de Java, mais je suis un Noob complet à javascript.

Answer 1

Pour la réalisation de la communication asynchrone entre le serveur client & il y a quelques-uns des cadres disponibles comme Atmosphere, Spring Reactor, DWF, Spring websockets.

L'approche de base est de ces cadres ont le dossier du côté client qui agit comme un talon au serveur méthodes secondaires. Les cadres ne permettent pas au cycle de réponse à la demande de se fermer à partir du navigateur. Ils continuent à envoyer les messages vierges périodiquement pour maintenir la connexion ouverte & garder les données en synchronisation.

Il y a aussi une partie de l'API propriétaire disponible sur le marché pour y parvenir comme Pusher