[PLUTO-help] CGI->JSP

[Gian Uberto Lauri]

>>>>> "CAF" == Carlo Alberto Filiberti <kain1985 a libero.it> writes:

CAF> Scusate raggazi so che la richiesta può sembrare strana ma avrei
CAF> bisogni di materiale riguardante un confronto fra la tecnologia
CAF> CGI e la JSP...vorrei documentare il perchè del progresivo
CAF> passaggio dalla prima alla seconda nella programmazione Web..

Non è documentazione, comunque...

* In CGI il protocollo di  comunicazione non è immediato, ad esempio i
  parametri  ti arrivano  grezzi,  devi separarteli  da solo.   Questo
  vuole dire un  lavoro che non tutti i  programmatori riescono a fare
  senza morire dietro ai SIGBUS o SIGERROR (programmazione C e affini)
  ed inoltre  possono cascare  facilissimamente in codice  poco sicuro
  (buffero overflow per C e  affini, problemi di sostituzione in SHELL
  e PERL).

* Con sistemi come ASP (bleah) o PHP risolvi questo problema.

* Con  Java hai  armi per  affrontare problemi  di grossa  taglia. Con
  paragoni marinari possiamo paragonare PHP ad una motosilurante (o al
  massimo  ad  un caccia  torpedinere),  Java  è  una task  force  con
  incrociatori,  portaerei  e  corazzate  dove  JSP ha  il  ruolo  del
  naviglio leggero d'appoggio.  Ovviamente NON usi una task force dove
  un  cacciatorpediniere o un  mas sono  adatti, e  viceversa. D'altro
  canto puoi non schierare la parte più pesante della flotta (gli EJB)
  ed  anzi la maggior  parte delle  applicazioni web  fa uso  del solo
  servlet container (gli incrociatori).

Creare  CGI risulta quindi  costoso (perché  o ci  metti programmatori
*BRAVI* -merce rara e  tendenzialmente esosa-) oppure la realizzazione
e la manutenzione saranno dei dolori.

Molto, molto  meglio affidarsi a  PHP o Java  (ASP se si gode  molto a
colpirsi i testicoli con un maglio da fabbro)

PHP  e orridumi  proprietari  si sono  diffusi  per progetti  leggeri,
spesso PHP si fa preferire per l'infrastruttura più economica.

Java richiede una  infrastruttura più tosta. Ma offre  tutta una serie
di servizi in più, non sempre realizzati in modo elegante. Ma permette
di sostituire un sistema transazionale basato su mainframe e di creare
applicazioni che scalano con le esigenze dell'utente.

O.K. questa la teoria.

Ora la pratica.

Nella   visione   teorica   JSP   dovrebbe   essere   puramente   lato
presentazione,  con pesante uso  di custom  tag per  non frammischiare
logica e presentazione (e due sintassi diverse, che rendono i sorgenti
un bordello - questo è un problema comune anche a PHP(*)).

In pratica  vien farcito  di codice perché  non viene  impiegata gente
addestrata a sufficenza.

Java ha comunque  una grande fortuna, ammettiamolo, perché  è di moda,
ma  ho  visto  spesso Java  preparare  per  il  Web dati  macinati  da
mainframe o da codice che gira sotto Oracle...

Nonostante tutto questo,  Java ha dei suoi punti  forti. Regge a tutta
una serie di attacchi (ma non  a tutti, hijacking e SQL injection sono
sempre possibili se i programmatori sono baucchi :) ), è un linguaggio
elegante, coerente. Quindi non è  stupido sceglierlo, se la taglia del
problema è di dimensione sufficiente.

Molti dei problemi  che si hanno con Java non  sono intrinseci a Java,
ma sono dovuti a chi programma. Java NON è facile.

E dove  va Java va JSP, la  diffusione di JSP è  strettamente legata a
Java Enterprise (o Web (**)) edition.

Peraltro  non  è che  con  PHP si  sia  automaticamente  al riparo,  e
sinceramente fare dei web services con  PHP 4 non è una cosa piacevole
e facile.

(*) Ci sono buoni programmatori PHP che non cascano in questo errore.
(**)Termine coniato dalla comunità che fa riferimento appunto all'uso
    dei servlet container, tralasciando gli EJB.

Spero sia servito

-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software