Se non puoi avere le informazioni "spinte" a te, devi costruire la tua "spinta".
Cioè, dovresti avere un'applicazione che esegue il polling FTP e l'altra, non direttamente connessa alla prima, che recupera i nuovi dati e li tratta. La tua seconda applicazione dovrebbe "iscriversi" al primo per ricevere una notifica per la disponibilità di un nuovo file. In questo modo, dovresti utilizzare pochissime risorse poiché l'applicazione principale verrà avviata / funzionerà solo quando riceve una notifica. La disconnessione in almeno due applicazioni è anche più flessibile poiché con l'architettura del notificatore / sottoscrittore qualsiasi altra nuova applicazione che scrivi dovrebbe solo essere abbonata al servizio di polling per poter lavorare con esso.
Inoltre, per utilizzare meno risorse, puoi eseguire il polling con un intervallo di tempo crescente. Ad esempio, supponiamo che la durata del sondaggio sia compresa tra un minimo di 2 e 10 minuti. Si inizia con 2 minuti. Se l'applicazione di polling non trova un nuovo file, il tempo viene aumentato di 1 minuto, fino a raggiungere un massimo di 10 minuti. Se l'applicazione di polling trova un nuovo file, l'ora è impostata su 2 minuti. Puoi anche immaginare un intervallo di tempo decrescente ...
Infine, per migliorare ulteriormente la tua architettura, puoi persino suddividere il problema in 3 applicazioni: una per il polling, una per il recupero dei dati e l'archiviazione da qualche parte (come una cache) e un'altra applicazione che tratta i dati ( e quindi non ha alcuna relazione con la "fonte" dei dati, che si tratti di FTP, HTTP o di un servizio web)
Modifica : sotto, un esempio di architettura basata su applicazioni Web e servizi Web per la mia prima proposta (due applicazioni).
Il servizio Poller può essere un'applicazione web composta da:
-
Un servizio Web composto da due metodi:
-
Iscriviti per consentire a un'applicazione / servizio Web client di registrarsi per la ricezione
informazioni che un nuovo file è disponibile. Uno dei parametri di questo metodo web dovrebbe essere l'indirizzo HTTP a cui questo "client" potrebbe essere raggiunto.
-
Annulla iscrizione per non ricevere più nulla.
-
Un servizio ha attivato ogni x minuti per il polling di un FTP per i nuovi file. Quando viene trovato un nuovo file, il servizio chiama ogni metodo Web NewFile "client" sottoscritto (che descrivo qui sotto)
Ora, un'applicazione client può essere qualsiasi cosa ma dovrebbe avere una facciata del servizio web con almeno il seguente metodo web:
-
NewFile , per consentire al poller di inviare le informazioni sulla disponibilità del nuovo file. All'interno di questo metodo web, il poller può anche inviare ulteriori informazioni sul file come la dimensione, quando è stato modificato e, naturalmente, la sua posizione esatta.
-
Quando questa applicazione inizia, chiama il metodo Iscriviti del servizio web di Poller.
- Quando questa applicazione termina, chiama il metodo Annulla sottoscrizione del servizio web di Poller.
Modifica: hai chiesto come sarebbe stato con i servizi REST .
Bene, le definizioni dei servizi non cambiano. Il servizio Iscriviti REST dovrebbe ricevere un URL che è in realtà il percorso del servizio REST NewFile nell'applicazione Web client. Per quanto riguarda la modalità di scrittura dei servizi:
- il Iscriviti e Annulla iscrizione sull'applicazione web del server dovrebbe probabilmente accettare rispettivamente POST e DELETE richieste HTTP ( per entrambi credo che anche POST funzionerebbe).
- il servizio REST NewFile sull'applicazione Web client deve accettare le richieste HTTP POST .
Quando viene rilevato un nuovo file, l'applicazione Web del server pubblica la posizione del file su ogni URL che è stato registrato come servizio REST compatibile NewFile compatibile. Questo è tutto.