La façon la plus simple de prendre en charge l'intégration d'un client java avec un serveur java

Lorsque vous résolvez des tâches quotidiennes avec l'interface d'une application de bureau JavaFX, vous devez quand même faire une demande au serveur Web. Après l'époque de J2EE et la terrible abréviation RMI, beaucoup de choses ont changé et les appels au serveur sont devenus plus légers. La norme pour les sockets Web et son échange de messages texte simples de tout contenu convient à un tel problème. Mais le problème avec les applications d'entreprise est que la diversité et le nombre de demandes font de la création et du suivi des points de terminaison avec des services commerciaux sélectionnés séparément une routine terrible et ajoute des lignes de code supplémentaires.

Mais que se passe-t-il si nous prenons une stratégie strictement typée avec RMI comme base, où il y avait une interface java standard entre le client et le serveur qui décrit les méthodes, les arguments et les types de retour, où quelques annotations ont été ajoutées, et le client n'a même pas remarqué comme par magie que l'appel était passé sur le réseau? Que se passe-t-il si ce n'est pas seulement du texte, mais que des objets java sérialisés sont transmis sur le réseau? Et si on ajoutait à cette stratégie la facilité des sockets web et leurs avantages de la possibilité d'appels push clients depuis le serveur? Que se passe-t-il si la réponse asynchrone du socket Web pour le client est limitée à l'appel de blocage habituel, et pour un appel retardé, ajoute la possibilité de renvoyer Future ou même CompletableFuture ? Et si nous ajoutons la possibilité d'abonner le client à certains événements du serveur? Que faire si le serveur a une session et une connexion à chaque client? Il peut s'avérer être un bon bundle transparent familier à tout programmeur java, car la magie sera cachée derrière l'interface et lors des tests, les interfaces peuvent être facilement remplacées. Mais ce n'est pas tout pour les applications chargées qui traitent, par exemple, les cotations boursières.

Dans les applications d'entreprise de ma pratique, la vitesse d'exécution d'une requête SQL et de transfert de données sélectionnées à partir d'un SGBD est incommensurable avec les frais généraux de sérialisation et d'appels réfléchis. De plus, une terrible trace d'appels EJB, complétant le temps d'exécution à 4-10 ms même pour la requête la plus simple, n'est pas un problème, car la durée des requêtes typiques est dans le couloir de 50ms à 250ms.

Commençons par le plus simple - nous utiliserons le modèle d'objet Proxy pour implémenter la magie derrière les méthodes d'interface. Supposons que j'ai une méthode pour obtenir l'historique de la correspondance d'un utilisateur avec ses adversaires:

public interface ServerChat{ Map<String, <List<String>> getHistory(Date when, String login); } 

Nous allons créer l'objet proxy à l'aide des outils java standard et appeler la méthode nécessaire dessus:

 public class ClientProxyUtils { public static BiFunction<String, Class, RMIoverWebSocketProxyHandler> defaultFactory = RMIoverWebSocketProxyHandler::new; public static <T> T create(Class<T> clazz, String jndiName) { T f = (T) Proxy.newProxyInstance(clazz.getClassLoader(), new Class[]{clazz}, defaultFactory.apply(jndiName, clazz)); return f; } } //    //... ServerChat chat = ClientProxyUtils.create(ServerChat.class, "java:global/test_app/ServerChat"); Map<String, <List<String>> history = chat.getHistory(new Date(), "tester"); //... //    

Si en même temps vous configurez des usines et implémentez l'instance d'objet proxy via l'interface via cdi-injection, vous obtiendrez la magie dans sa forme la plus pure. Dans le même temps, l'ouverture / la fermeture d'une prise à chaque fois n'est pas du tout nécessaire. Au contraire, dans mes applications, le socket est constamment ouvert et prêt à recevoir et traiter des messages. Maintenant, cela vaut la peine de voir ce qui se passe dans RMIoverWebSocketProxyHandler :

 public class RMIoverWebSocketProxyHandler implements InvocationHandler { public static final int OVERHEAD = 0x10000; public static final int CLIENT_INPUT_BUFFER_SIZE = 0x1000000;// 16mb public static final int SERVER_OUT_BUFFER_SIZE = CLIENT_INPUT_BUFFER_SIZE - OVERHEAD; String jndiName; Class interfaze; public RMIoverWebSocketProxyHandler(String jndiName, Class interfaze) { this.jndiName = jndiName; this.interfaze = interfaze; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Request request = new Request(); request.guid = UUID.randomUUID().toString(); request.jndiName = jndiName; request.methodName = method.getName(); request.args = args; request.argsType = method.getParameterTypes(); request.interfaze = interfaze; WaitList.putRequest(request, getRequestRunnable(request)); checkError(request, method); return request.result; } public static Runnable getRequestRunnable(Request request) throws IOException { final byte[] requestBytes = write(request); return () -> { try { sendByByteBuffer(requestBytes, ClientRMIHandler.clientSession); } catch (IOException ex) { WaitList.clean(); ClientRMIHandler.notifyErrorListeners(new RuntimeException(FATAL_ERROR_MESSAGE, ex)); } }; } public static byte[] write(Object object) throws IOException { try (ByteArrayOutputStream baos = new ByteArrayOutputStream(); ObjectOutputStream ous = new ObjectOutputStream(baos)) { ous.writeObject(object); return baos.toByteArray(); } } public static void sendByByteBuffer(byte[] responseBytes, Session wsSession) throws IOException { ... } public static void checkError(Request request, Method method) throws Throwable { ... } @FunctionalInterface public interface Callback<V> { V call() throws Throwable; } } 

Et voici le client final EndPoint lui - même :

 @ClientEndpoint public class ClientRMIHandler { public static volatile Session clientSession; @OnOpen public void onOpen(Session session) { clientSession = session; } @OnMessage public void onMessage(ByteBuffer message, Session session) { try { final Object readInput = read(message); if (readInput instanceof Response) { standartResponse((Response) readInput); } } catch (IOException ex) { WaitList.clean(); notifyErrorListeners(new RuntimeException(FATAL_ERROR_MESSAGE, ex)); } } private void standartResponse(final Response response) throws RuntimeException { if (response.guid == null) { if (response.error != null) { notifyErrorListeners(response.error); return; } WaitList.clean(); final RuntimeException runtimeException = new RuntimeException(FATAL_ERROR_MESSAGE); notifyErrorListeners(runtimeException); throw runtimeException; } else { WaitList.processResponse(response); } } @OnClose public void onClose(Session session, CloseReason closeReason) { WaitList.clean(); } @OnError public void onError(Session session, Throwable error) { notifyErrorListeners(error); } private static Object read(ByteBuffer message) throws ClassNotFoundException, IOException { Object readObject; byte[] b = new byte[message.remaining()]; // don't use message.array() becouse it is optional message.get(b); try (ByteArrayInputStream bais = new ByteArrayInputStream(b); ObjectInputStream ois = new ObjectInputStream(bais)) { readObject = ois.readObject(); } return readObject; } } 

Ainsi, pour appeler n'importe quelle méthode de l'objet proxy, nous prenons une session de socket ouverte, envoyons les arguments passés et les détails de la méthode qui doit être appelée sur le serveur, et attendons la réponse avec le guide spécifié dans la demande à recevoir. Dès réception de la réponse, nous vérifions s'il y a une exception, et si tout va bien, nous mettons le résultat de la réponse dans Request et notifions le flux qui attend une réponse dans WaitList. Je ne donnerai pas l'implémentation d'une telle WaitList, car elle est triviale. Le thread en attente, au mieux, continuera à fonctionner après la ligne WaitList.putRequest (request, getRequestRunnable (request)); . Après le réveil, le thread vérifiera les exceptions déclarées dans la section des lancers et retournera le résultat via return .

Les exemples de code ci-dessus sont des extraits de la bibliothèque, qui n'est pas encore prête à être publiée sur github. Il est nécessaire de résoudre les problèmes de licence. Il est logique de regarder l'implémentation du côté serveur déjà dans le code source lui-même après sa publication. Mais il n'y a rien de spécial là-bas - une recherche est effectuée pour un objet ejb qui implémente l'interface spécifiée dans jndi via InitialContext et un appel réfléchi est effectué en utilisant les détails transmis. Là, bien sûr, il y a encore beaucoup de choses intéressantes, mais un tel volume d'informations ne rentrera dans aucun article. Dans la bibliothèque elle-même, le script d'appel de blocage ci-dessus a tout d'abord été implémenté, car il est le plus simple. La prise en charge ultérieure des appels non bloquants via Future et CompletableFuture <> a été ajoutée. La bibliothèque est utilisée avec succès dans tous les produits avec un client Java de bureau. Je serais heureux si quelqu'un partage son expérience de l'ouverture de code source lié à gnu gpl 2.0 ( tyrus-standalone-client ).

Par conséquent, il n’est pas difficile de créer une hiérarchie d’invocation de méthodes à l’aide d’outils IDE standard vers le formulaire d’interface utilisateur lui-même, sur lequel le gestionnaire de boutons tire des services distants. Dans le même temps, nous obtenons un typage strict et une faible connectivité de la couche d'intégration client et serveur. La structure du code source de l'application est divisée en un client, un serveur et un noyau, qui est connecté par dépendance au client et au serveur. C'est en elle que se trouvent toutes les interfaces distantes et objets transférés. Et la routine du développeur associée à la requête dans la base de données nécessite une nouvelle méthode dans l'interface et son implémentation côté serveur. À mon avis, beaucoup plus facile ...