Quote Originariamente inviata da Curiosone90 Visualizza il messaggio
1) le solite pagine web memorizzate in locale
Ok ma scusa ... perché "in locale"? Le pagine non le può servire il server HTTP??

Quote Originariamente inviata da Curiosone90 Visualizza il messaggio
2) un server HTTP embedded incorportato (in Java SE), prendendo spunto da questo codice: http://www.java2s.com/Code/Java/Netw...eWebServer.htm
No, quella è sostanzialmente una "schifezza". E' solo l'esempio super-ultra basilare per fare "vedere" che una applicazione Java può rispondere ad una richiesta HTTP. Ma se operi direttamente a livello di socket ti esponi ad un sacco di "grane" oltre al fatto che DEVI conoscere benissimo tutte le minuzie del protocollo HTTP (e questo potrebbe richiedere settimane, se non mesi, se parti da zero o quasi).

L'ideale è usare una libreria di "server" HTTP. O incorporare un server come Jetty o Tomcat. Ad esempio tramite Spring Boot (ma questo richiede comunque anche "altre" competenze, cioè su Spring in generale).

Quote Originariamente inviata da Curiosone90 Visualizza il messaggio
La mia domanda sorge spontanea: se realizzo un webserver in java (vedi punto 2), non realizzo una CGI, con tutti i problemi derivanti? Quindi all'aumentare di utenti collegati ho un grande sforzo della CPU e delle risorse in loco?
CGI (Common Gateway Interface) è lo standard che si usa(va) (una volta...) per far sì che un web server potesse lanciare script/eseguibili esterni che "rispondevano" alle richieste ricevendo/inviando i dati tramite i suoi standard input/output. Quindi ogni richiesta creava un processo esterno. Questo E' pesante.

Tutte le moderne web application, che siano con un "vero" application server, che siano con un server HTTP embedded o altro, sfruttano il multi-threading. Quindi molto più leggero. E quindi NON è un CGI.