Ho bisogno di un'interfaccia per un servizio di back-end, principalmente per i comandi di controllo (stop, status, cancel, reload config). Il servizio potrebbe essere in Python, Perl, Java o altro, e viene eseguito continuamente. L'interfaccia mi consentirà di inviare comandi poco frequenti al processo in esecuzione.
Un gestore di segnali può dire a un processo di fermarsi, e i segnali USR1 e USR2 lasciano fare ancora due cose. Tomcat imposta un listener speciale su un numero di porta fisso per farlo arrestare, forse a causa delle limitazioni della gestione dei segnali Java.
Ma mi piacerebbe che risponda, non solo reagire. E mi piacerebbe usare questo per un servizio scritto in qualsiasi lingua su qualsiasi piattaforma. Spero di evitare che il middleware o i database comunichino, poiché si tratta semplicemente di una richiesta / risposta (Q: "come stai?" / A: "Ho eseguito per 3 ore al massimo dell'efficienza").
Ho dato un'occhiata a questi, ma sembra eccessivo per una semplice interfaccia di controllo:
- dBus - bus di messaggi di interprocesso generale
- UPnP - comunicazione dispositivo
- Avahi - Domande DNS per trovare servizi
- Hadoop YARN - Distribuisce il lavoro attraverso una rete, l'elaborazione parallela
Ognuno di essi sembra convincente, ma è pesante, oppure richiede l'installazione di software speciali in anticipo o non è disponibile per tutte le lingue o tutte le piattaforme.
Se scrivessi il mio, potrei scrivere un listener TCP a thread singolo con richieste / risposte JSON. Sembra leggero e universale come si può ottenere, ed è abbastanza piccolo per un servizio "ciao mondo", e abbastanza grande per parlare con qualsiasi servizio. JSON su TCP sarebbe molto amichevole da riga di comando (curl o netcat), e quindi facilmente scrivibile. Molte lingue hanno già una libreria JSON (C ++, Java, ecc.), In qualsiasi piattaforma.
Un approccio più difficile consiste nell'aggiungere la semantica HTTP alla richiesta / risposta JSON in modo da poter esplorare l'applicazione o utilizzare l'arricciatura per controllarla. Ma l'integrazione di HTTP sembra un sacco di spazio e complessità quando supporterà solo alcune risorse (PUT text / plain "true" to / stop per arrestare l'app, GET application / json da / status per vedere come è in esecuzione).
Francamente, sono sorpreso che nessuno abbia inventato un'interfaccia di controllo di servizio standard per cose semplici come i comandi di controllo di base. Al lavoro abbiamo utilizzato CORBA e registrato in un servizio di denominazione e poi abbiamo dovuto affrontare problemi di connessione ORB Java / C ++ e sembrava un sacco di codice per qualcosa che dovrebbe essere semplice.