Les classes d'une bibliothèque JRE prennent-elles en charge les lectures observables et / ou asynchrones à partir d'assemblys externes / non-JRE?


12

Comment puis-je implémenter ma bibliothèque multiplateforme (par exemple sur JRE) pour fonctionner de manière thread-safe sur les références d'objet, afin que les frontaux natifs sur d'autres plates-formes puissent observer l'objet et tirer parti des modèles observables?

Un peu d'histoire - il existe un concept de liaison de données utilisé dans la plupart des frameworks frontaux. En C # et Java, cela est lié au trait Observable qui donne à une classe la possibilité de déclencher des événements lorsque des changements se produisent, auxquels plusieurs contrôles ou "observateurs" peuvent souscrire. De cette façon, les observateurs n'ont pas à continuer d'interroger / lire la ressource, en comparant les mises à jour.

Je souhaite travailler sur un moteur d'analyse qui modifie les listes de données au fil du temps. Ce serait bien de pouvoir faire en sorte que le frontal puisse observer ces listes pendant que l'analyse est en cours. Il me semble que cela nécessiterait que le front-end puisse transmettre un objet au moteur d'analyse, écrit dans une bibliothèque qui, espérons-le, soit multiplateforme, et être capable de faire des lectures thread-safe sur cet objet. Ou bien, demandez à la bibliothèque de respecter les contrats d’observabilité.

La façon dont cela est géré dans les anciens moteurs CLI de style Unix consiste à utiliser stdin / stdout / stderr et à faire publier régulièrement les mises à jour du moteur. Cela nécessite une surcharge standard et une analyse de texte que je préfère éviter, si possible.


2
Il est généralement préférable de rendre la question centrale un peu plus étroite que "Est-ce que X est possible?", Car la bonne réponse est presque toujours "Oui, si vous essayez assez fort". On dirait que vous voulez vraiment demander "Comment puis-je faire X sans la surcharge de stdin / stdout?" Dans ce cas, pourquoi ne pas simplement utiliser une bibliothèque liée statiquement ou dynamiquement? Avez-vous besoin que cette bibliothèque soit un programme distinct de l'interface utilisateur pour une raison quelconque?
Ixrec

Merci, Ixrec. Pensez-vous que je l'ai formulé comme vous le suggérez dans mon titre? La raison pour laquelle je voudrais que la bibliothèque soit portable et le front-end natif, c'est parce que je pense que les frameworks d'interface utilisateur natifs fonctionnent généralement mieux (alerte d'opinion!), Mais je ne veux pas écrire deux fois la logique du moteur .
Brandon Arnold

Pourquoi une bibliothèque liée statiquement ou dynamiquement ne peut-elle pas être portable? Re: Le titre, c'est un exemple de manuel d'une question «trop large»; Je ne me suis pas concentré sur cela parce qu'il semblait y avoir des questions plus spécifiques dans le reste de votre question.
Ixrec

@Ixrec C'est possible. La question suppose qu'il s'agit d'une bibliothèque, qui inclut ces possibilités. Je voudrais juste m'assurer que toutes les applications qui consomment cette bibliothèque pourront observer les références aux objets qui lui sont transmis de manière asynchrone, pendant leur fonctionnement.
Brandon Arnold

1
@Ixrec J'ai mis à jour le titre pour qu'il soit moins large
Brandon Arnold

Réponses:


1

Vous pouvez créer un niveau d'intégration sur le modèle de votre bibliothèque en utilisant (par exemple) le cadre d'intégration d'Apache Camel. Le composant Netty pourrait probablement répondre à vos besoins. Avec un modèle observable, votre niveau d'intégration devrait transformer les modifications reçues de votre modèle et les notifier aux abonnés frontaux. Une autre manière similaire d'interpréter votre exigence est de penser à une architecture pilotée par les événements où, lorsque votre modèle change, les auditeurs observateurs de votre niveau d'intégration publient un message dans une rubrique JMS afin que les abonnés connectés dans les frontaux les reçoivent.


0

J'ai écrit une réponse complètement différente, suggérant que votre éditeur écrit des mises à jour dans une file d'attente ou une pipe - mais j'ai ensuite relu la question.

Si je comprends bien, votre question générale est que vous voulez écrire une bibliothèque à exécuter dans le JRE, dans laquelle un frontal natif peut interroger l'état des objets Java d'une manière thread-safe.

C'est incroyablement large car il existe des centaines de façons dont un frontal peut interagir avec le code de bibliothèque s'exécutant dans un JRE - JNI, EJB RPC, interfaces HTTP de style RPC, demande-réponse sur des files d'attente de messages, etc.

Quoi que vous choisissiez cependant, à un moment donné de la chaîne, il devrait y avoir un appel de méthode Java, et c'est là que vous pouvez prendre le contrôle de la sécurité des threads. Là, vous avez à votre disposition tout l'arsenal d'outils de sécurité des filetages. Vous pouvez synchroniser, vous pouvez retourner des copies défensives, travailler avec des données en cache, etc.

Cependant, déterminez si c'est le modèle que vous souhaitez suivre. Il peut être plus judicieux de passer à un modèle "ne me demandez pas, je vais vous dire", dans lequel votre bibliothèque envoie des mises à jour au front-end contenant suffisamment d'informations pour ne pas avoir à interroger les objets.


Commentaire supplémentaire - avez-vous envisagé d'utiliser Redis (ou similaire) comme intermédiaire entre vos frontaux et vos backends?
slim
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.