Le classi in una libreria JRE supportano letture osservabili e / o asincrone da assembly esterni / non JRE?


12

Come posso implementare la mia libreria multipiattaforma (ad esempio su JRE) per operare in modo thread-safe su riferimenti a oggetti, in modo che front-end nativi su altre piattaforme possano osservare l'oggetto e trarre vantaggio da schemi osservabili?

Un po 'di background: esiste un concetto di associazione dei dati utilizzato nella maggior parte dei framework front-end. In C # e Java questo è legato alla caratteristica Osservabile che dà a una classe la possibilità di lanciare eventi quando si verificano cambiamenti, a cui possono sottoscrivere più controlli o "osservatori". In questo modo gli osservatori non devono continuare a sondare / leggere la risorsa, confrontando per gli aggiornamenti.

Voglio lavorare su un motore di analisi che apporti modifiche agli elenchi di dati nel tempo. Sarebbe bello poter avere il front-end in grado di osservare questi elenchi mentre l'analisi è in esecuzione. Mi sembra che ciò richiederebbe al front-end di essere in grado di passare un oggetto al motore di analisi, scritto in una libreria che si spera sia multipiattaforma, e di poter eseguire letture thread-safe su quell'oggetto. Oppure, fai in modo che la biblioteca soddisfi i contratti di osservabilità.

Il modo in cui questo viene gestito nei vecchi motori CLI in stile Unix consiste nell'utilizzare stdin / stdout / stderr e fare in modo che il motore invii aggiornamenti a intervalli regolari. Ciò richiede un overhead standard e l'analisi del testo che preferirei evitare, se possibile.


2
In genere è meglio rendere la domanda un po 'più ristretta di "È possibile X?", Poiché la risposta corretta è quasi sempre "Sì, se ci provi abbastanza". Sembra che tu voglia davvero chiedere "Come posso fare X senza il sovraccarico di stdin / stdout?" In tal caso, perché non usare semplicemente una libreria collegata staticamente o dinamicamente? È necessario che questa libreria sia un programma separato dall'interfaccia utente per qualche motivo?
Ixrec,

Grazie Ixrec. Pensi che l'abbia definito nel modo in cui mi suggerisci nel mio titolo? Il motivo per cui vorrei che la libreria fosse portatile e che il front-end fosse nativo, è perché penso che i framework dell'interfaccia utente nativi generalmente funzionano meglio (avviso di opinione!), Ma non voglio scrivere due volte la logica del motore .
Brandon Arnold,

Perché una libreria collegata staticamente o dinamicamente non può essere portatile? Ri: Il titolo, che è un esempio da manuale di una domanda "troppo ampia"; Non mi sono concentrato su questo perché sembravano esserci domande più specifiche nel resto della tua domanda.
Ixrec,

@Ixrec Può. La domanda presuppone che si tratti di una libreria che include tali possibilità. Vorrei solo assicurarmi che tutte le applicazioni che utilizzano questa libreria saranno in grado di osservare i riferimenti agli oggetti che le vengono passati in modo asincrono, mentre vengono utilizzati.
Brandon Arnold,

1
@Ixrec Ho aggiornato il titolo in modo che sia meno ampio
Brandon Arnold,

Risposte:


1

Puoi creare un livello di integrazione sul modello della tua libreria usando (ad esempio) il framework di integrazione di apache camel. Il componente Netty probabilmente potrebbe soddisfare le tue esigenze. Con un modello osservabile, il livello di integrazione dovrebbe trasformare le modifiche ricevute del modello e notificarle agli abbonati front-end. Un altro modo simile per interpretare le tue esigenze è quello di pensare a un'architettura guidata dagli eventi in cui quando il tuo modello cambia, gli ascoltatori di osservatori nel tuo livello di integrazione pubblicano un messaggio in un argomento JMS in modo che gli abbonati collegati nei front-end li riceveranno.


0

Ho scritto una risposta completamente diversa, suggerendo che il tuo editore scrive gli aggiornamenti in una coda o in una pipe, ma poi rileggo la domanda.

Se ho capito bene la tua domanda generale è che vuoi scrivere una libreria da eseguire in JRE, in cui un front-end nativo può interrogare lo stato degli oggetti Java in maniera thread-safe.

Questo è incredibilmente ampio perché ci sono centinaia di modi in cui un front-end può interagire con il codice della libreria in esecuzione in un JRE: JNI, EJB RPC, interfacce HTTP in stile RPC, richiesta-risposta su code di messaggi, ecc.

Qualunque cosa tu scelga, tuttavia, a un certo punto della catena, dovrebbe esserci una chiamata al metodo Java, ed è qui che puoi prendere il controllo della sicurezza dei thread. Lì hai tutto l'arsenale di strumenti di sicurezza del filo a tua disposizione. Puoi sincronizzare, puoi restituire copie difensive, lavorare con i dati memorizzati nella cache, ecc.

Tuttavia, considera se questo è il modello che vuoi seguire. Potrebbe essere più pulito passare a un modello "non chiedermelo, ti dirò", in cui la tua libreria invia aggiornamenti al front-end contenente informazioni sufficienti che non è necessario interrogare gli oggetti.


Commento aggiuntivo: hai preso in considerazione l'utilizzo di Redis (o simile) come intermediario tra i tuoi front-end e back-end?
magro
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.