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

12

Come posso implementare la mia libreria multipiattaforma (ad esempio su JRE) per operare in modo thread-safe sui riferimenti a oggetti, in modo che front-end nativi su altre piattaforme possano osservare l'oggetto e sfruttare i pattern Observable?

Un po 'di background - esiste un concetto di associazione dei dati usato nella maggior parte dei framework front-end. In C # e Java questo è correlato al tratto Osservabile che dà a una classe la capacità di sparare eventi quando si verificano cambiamenti, a cui possono essere abbinati più controlli o "osservatori". In questo modo gli osservatori non devono continuare a sondare / leggere la risorsa, confrontando gli aggiornamenti.

Voglio lavorare su un motore di analisi che apporta modifiche agli elenchi di dati nel tempo. Sarebbe bello poter avere il front-end in grado di osservare queste liste mentre l'analisi è in esecuzione. Mi sembra che questo 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 in grado di creare letture thread-safe per quell'oggetto. Oppure, fare 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'usare stdin / stdout / stderr e fare in modo che il motore pubblichi gli aggiornamenti a intervalli regolari. Ciò richiede un overhead standard e un'analisi del testo che preferirei evitare, se possibile.

    
posta Brandon Arnold 26.08.2015 - 00:09
fonte

2 risposte

1

È possibile creare un livello di integrazione sul modello della libreria utilizzando (ad esempio) il framework di integrazione del cammello apache. Il componente Netty potrebbe probabilmente adattarsi alle tue esigenze. Con uno schema osservabile il tuo livello di integrazione dovrebbe trasformare le modifiche ricevute dal tuo modello e notificarle agli abbonati front-end. Un altro modo simile per interpretare la tua esigenza è pensare a un'architettura basata sugli eventi in cui, quando il tuo modello cambia, gli ascoltatori dell'osservatore nel tuo livello di integrazione pubblica un messaggio in un argomento JMS in modo che gli utenti iscritti ai front-end li ricevano.

    
risposta data 04.09.2015 - 01:41
fonte
0

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

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

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

Qualunque sia la tua scelta, ad un certo punto della catena, dovrebbe esserci una chiamata al metodo Java, ed è qui che puoi prendere il controllo della sicurezza del thread. Lì, hai a disposizione l'intero arsenale di strumenti per la sicurezza del filo. Puoi sincronizzare, puoi restituire copie difensive, lavorare con 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 gli aggiornamenti al front-end che contengono informazioni sufficienti a non richiedere la query sugli oggetti.

    
risposta data 31.05.2016 - 11:51
fonte

Leggi altre domande sui tag