Introduzione
Un servizio windows, per definizione non è dotato di interfaccia utente, è un po’ come una scatola nera con dei plug che riceve input e produce output ma senza alcuna interazione con l’utente.
Un servizio semplice, potrebbe avere bisogno esclusivamente di una console, come quella da noi costruita nei post precedenti, per configurarlo e per verificare che parte e si ferma. Potremmo anche aggiungere alla console creata un sistema veloce per consultare i log del servizio e fermarci qui.
Se il servizio è più complesso di quello che scrive dati su un file di testo che fin qui abbiamo sviluppato, l’amministratore potrebbe aver bisogno anche di valutarne il carico di lavoro, la funzionalità e quindi profilarne il funzionamento per potere ad esempio rispondere alla domanda: “Ma perché è così lento.” facendo un fine tuning della parametrizzazione del servizio.
Per fare questo abbiamo bisogno che il servizio sia in grado di essere monitorato in tempo reale, usando il log verboso che abbiamo introdotto nel primo sviluppo del servizio potremmo usare un file system watcher e monitorare il file di log, ma è un approccio un po’ troglodita, soprattutto se il log è massiccio.
A questo punto entrano in gioco gli oggetti che abbiamo inserito nel titolo di questo post. Un servizio può essere dotato di una interfaccia per comunicare con il mondo (in questo caso con il PC che lo ospita) utilizzando il protocollo HTTP, l’interfaccia può essere bidirezionale, quindi il servizio potrebbe ricevere dei comandi da un programma esterno e potrebbe trasmettere dati e richieste ad un programma esterno.
Ecco perché abbiamo deciso di sviluppare le classi necessarie a creare questo tipo di comunicazione.