Newsgroup: it.comp.lang.delphi
Titolo: Servizi: caso pratico e domande varie.

Premessa: non ho mai implementato un servizio. Parto dal caso pratico e 
pongo delle domande sui servizi.
Dovrei scrivere per l'ufficio dove lavoro un'applicazione di tipo 
"scadenzario": sostanzialmente un database (devo usare MS SQL Server), al 
quale le applicazioni client accedono (con componenti ADO) tramite 
un'interfaccia utente (scritta ovviamente in Delphi).
In più, l'applicazione server deve segnalare (via TCP, quindi componenti 
Indy) a tutte le applicazioni client quando una scadenza (o evento)..scade.
Per il rilevamento della scadenza degli eventi, ho pensato di dotare di un 
timer *solo* l'applicazione server, in modo da centralizzare la logica 
tutta in un solo posto (anche perchè gli orologi/calendari dei pc client 
potrebbero essere sballati). Le applicazioni client (oltre a fornire 
l'interfaccia di accesso ai dati, come visto sopra) fungerebbero 
nient'altro che da ricevitori dei pacchetti TCP inviati dall'applicazione 
server.
Se avete osservazioni da fare sull'architettura, naturalmente, sono le 
benvenute.
La domanda riguarda il come implementare le applicazioni sui client: un'EXE 
tradizionale, da far partire poi mettendo un link in "Esecuzione 
Automatica" (da parte di un programma di setup), oppure un servizio?
Siccome non ho mai scritto servizi, volevo sapere prima di 
cimentarmi(cisi). 
Inoltre, come far girare l'applicazione sul server? (non so che versione di 
Windows Server) Sempre come servizio?
Inoltre, come essere relativamente "sicuri" che l'applicazione sul server 
stia stia "sempre" girando? O perlomeno che giri almeno una volta al 
giorno...
Per esempio, c'è un modo per far sì che accada qualcosa se un servizio non 
si riesce ad avviare?
-- 
Mauro Falzari 
 
  La persona che conosce il vostro segreto
  diventerà il padrone della vostra libertà.
    (François La Rochefoucauld, 1613-1680)

si riesce ad avviare?
Puoi scrivere un'applicazione "Guardian" che giri anch'essa come
servizio e che si assicuri che il servizio sia su (Firebird ad esempio
lavora così).  Ovviamente se l'applicazione di guardia va giù, c'è
poco da fare.  Tuttavia è meno probabile che un'applicazione di
controllo vada giù rispetto a quella che, invece, fa il lavoro sporco.
Assicurati, in ogni caso, che tutti i tuoi servizi generino dei file
di log.  Per eventi drastici è anche possibile interfacciare l'Event
Viewer di Windows, ma è un'operazione veramente macchinosa.  Meglio il
file di log.  E' essenziale per i servizi.  Io generalmente scrivo il
log su database.

 il sistema compilerà un servizio.
ciao Andrea, ti ringrazio per i preziosi consigli, ora mi cercherò degli 
esempi in rete su come gestire il socket, come mettere un thread in ascolto 
su una porta, cosa fare quando il thread riceve dati (sugli help ho letto 
che bisogna creare un altro thread, per liberare il thread principale)...
Inoltre mi pare che sia meglio che, sui client, l'applicazione che 
interagisce col database sia diversa e separata dal servizio che riceve le 
notifiche dal server (ovvero dal servizio lato server). Ah, a proposito 
dovrò vedere anche come fa un servizio a mostrare una form, dal momento che 
TService è un DataModule (forse bisognerà usare il metodo Synchronize di 
TService.ServiceThread...).


dovrò vedere anche come fa un servizio a mostrare una form
Non può e non deve.  Se hai bisogno di mostrare a video informazioni
sul servizio, costruisci un'applicazione console (una normale
applicazione) che sempre via socket lo interfacci.