Ingegneria del Web 2006/2007

MarDok ha scritto:

Ragazzi ma quanto sono importanti le slide riguardanti :
- Apache
- Generazione contenuti dinamici
- Sistemi web distribuiti localmete e geograficamente
- Web Service

Apache e Web distribuiti Geograficamente/Localmente: importanza elevata (non li ha chiesti a me personalmente, ma a parecchie persone che conosco sì, anche a livello di dettaglio piuttosto consistente).
Non so dirti riguardo agli altri due.

alexjohnp ha scritto:

MarDok ha scritto:

Ragazzi ma quanto sono importanti le slide riguardanti :
- Apache
- Generazione contenuti dinamici
- Sistemi web distribuiti localmete e geograficamente
- Web Service

Apache e Web distribuiti Geograficamente/Localmente: importanza elevata (non li ha chiesti a me personalmente, ma a parecchie persone che conosco sì, anche a livello di dettaglio piuttosto consistente).
Non so dirti riguardo agli altri due.

ciao!
ma su apache cosa intendi per livello di dettaglio consistente? roba tipo il demone httpd viene eseguito al lancio dello script apachectl, dire tutti i parametri che vanno impostati a seconda del modulo MPM scelto, ecc, oppure sapere cosa sono i moduli, il ciclo rich/risp, come funzionano i vari moduli MPM ecc?
Ma la tua ora e 20 minuti di orale da solo come è stata distribuita tra progetto e teoria?

grazie x le info! Ciao!

Smoking_Man ha scritto:

ma su apache cosa intendi per livello di dettaglio consistente? roba tipo il demone httpd viene eseguito al lancio dello script apachectl, dire tutti i parametri che vanno impostati a seconda del modulo MPM scelto, ecc, oppure sapere cosa sono i moduli, il ciclo rich/risp, come funzionano i vari moduli MPM ecc?

per livello di dettaglio intendo il pooling, alcune opzioni di configurazione sul preforking e sui worker threads, ciclo req/resp e il modo in cui i moduli sono integrati nel webserver.

Smoking_Man ha scritto:

Ma la tua ora e 20 minuti di orale da solo come è stata distribuita tra progetto e teoria?

Il progetto l'ha usato come 'scusa' per le domande di teoria. Anche quel poco di codice che mi ha chiesto (per testare la validità di alcune scelte che avevo fatto) è stato analizzato più che altro per vedere come si sarebbe potuto estendere, alla luce delle funzionalità di http, il funzionamento del software.

Domanda da un milione di dollari....
La differenza principale tra CGI/Servlet e PHP/JSP sta solo nel fatto che le prime sono peggiori perchè richiedono l'apertura di un nuovo processo ogni volta che il client fa richiesta di una risorsa dinamica a loro collegata??

MarDok ha scritto:

Domanda da un milione di dollari....
La differenza principale tra CGI/Servlet e PHP/JSP sta solo nel fatto che le prime sono peggiori perchè richiedono l'apertura di un nuovo processo ogni volta che il client fa richiesta di una risorsa dinamica a loro collegata??

ciao!
provo io:)
io non metterei CGI sullo stesso piano delle servlet (che offrono molti vantaggi in più) mentre l'accostamento si può fare per PHP e JSP (entrambi html-embedded) con la fondamentale differenza che JSP permette l'integrazione con applicazioni java (come anche le servlet) e quindi lo sviluppo di applicazioni enterprise usando un middleware mentre PHP, essendo interpretato da un modulo del web server, di fatto ha la limitazione di non poter essere impiegato per sviluppare applicazioni distribuite di grosse dimensioni. Aggiungerei pure che PHP4 non è neppure un linguaggio ad oggetti (il 5, OO, non ho mai avuto il piacere di provarlo purtroppo ma ho sentito che sta avendo successo)...
comunque quella parte sulle slide non è fatta benissimo e non ho trovato neanche tra i documenti consigliati dove approfondire meglio l'argomento..
voi che dite?

@alexjohnp: grazie x le info!

Smoking_Man ha scritto:

JSP permette l'integrazione con applicazioni java (come anche le servlet) e quindi lo sviluppo di applicazioni enterprise usando un middleware mentre PHP, essendo interpretato da un modulo del web server, di fatto ha la limitazione di non poter essere impiegato per sviluppare applicazioni distribuite di grosse dimensioni.

Vero in parte.
Ci sono dei contro abbastanza consistenti anche nel caso di JSP (ne parlo con una certa sicurezza perché mi occupo, per lavoro, di ottimizzazione di transazioni massivamente distribuite).
JSP (e, andando nel mondo non "open", anche le attualissime evoluzioni .net come aspx) ha due enormi punti deboli entrambi dovuti proprio alla presenza del middleware:
1) rispetto a codice eseguito e "embedded" interamente all'interno dello spazio dei processi del web server, la macchina virtuale aggiunge overhead. I tempi di setup (costanti, e maggiormente avvertiti nel caso di transazioni di piccola entità) e la necessità di dover stabilire un canale di comunicazione per lo scambio dati (i.e: comunicazione interprocesso: molto più "light" nel caso in cui l'elaborazione sia confinata all'interno di uno spazio di indirizzamento proprietario) non sempre rendono jsp un'alternativa valida.
2) Se la macchina virtuale "cade" nel bel mezzo di una transazione consistente (cosa molto più complicata nel caso di php, per via dei numerosi meccanismi di replicazione dei processi del web server), le risorse allocate dal webserver stesso vanno irrimediabilmente perdute senza possibilità di recupero (lo stato del middleware rimane comunque nascosto).

Inoltre, la necessità di dover utilizzare delle piattaforme dedicate (ad es. tomcat, per rimanere in ambito di progetti apache), potrebbe non essere auspicabile (o realizzabile) in ambiti in cui le piattaforme di produzione hanno delle necessità di estrema efficienza (e in questo gli application server non possono vincere contro un web server "vero"), ad esempio per veicolare servizi di calcolo distribuito, convergendo verso piattaforme operative unificate (quindi apache, iis,...).

Java, per contro, si fa apprezzare per altri motivi, più connessi alla security.

In bocca al lupo a tutti.