Servlet e JSP

di il
4 risposte

Servlet e JSP

Da Marzo dovrò cominciare a studiare questi argomenti. Mi potreste gentilmente fare una panoramica del loro utilizzo attuale? Sono state rimpiazzate con l'arrivo dell'HTML5? E' importante studiarle e perchè?
Vi ringrazio.

4 Risposte

  • Re: Servlet e JSP

    Paolovox ha scritto:


    Da Marzo dovrò cominciare a studiare questi argomenti. Mi potreste gentilmente fare una panoramica del loro utilizzo attuale? Sono state rimpiazzate con l'arrivo dell'HTML5? E' importante studiarle e perchè?
    La questione è posta un po' male. Le Servlet servono per gestire le request HTTP da un client (e in certi casi per generare direttamente la response) mentre le pagine JSP sono similari come concetto a PHP o ad altri sistemi di templating: servono per generare dinamicamente dei documenti testuali, cioè documenti in cui certe parti sono espanse con dei valori dinamici o ripetute tramite un concetto di iterazione o anche generate da zero per importazione di altri documenti o dalla esecuzione di codice Java diretto o in custom tag.

    Cosa fai arrivare al client è indifferente alla tecnologia Servlet/JSP. Puoi generare dinamicamente tanto pagine HTML4 quanto HTML5 o XHTML o pure XML e qualunque suo dialetto (es. documenti SVG).
    E all'inverso, per il client è indifferente se quelle pagine arrivano dalla generazione fatta con PHP, JSP, ASP.NET, Perl, Python o quant'altro sul server.
  • Re: Servlet e JSP

    Quali sono alternative valide alle servlet? Una socket server-side scritta in C non potrebbe soddisfare le stesse richieste utilizzando anche il multithreading?
  • Re: Servlet e JSP

    Grazie per la delucidazione e i consigli. A Marzo mi farò sentire di nuovo su questo topic
  • Re: Servlet e JSP

    Paolovox ha scritto:


    Quali sono alternative valide alle servlet?
    Le servlet sono solo lo strato più basso offerto da JavaEE per realizzare web application in Java. Al "di sopra" delle servlet esiste una quantità innumerevole di framework: JSF, Struts, Spring, Tapestry, Stripes, Google GWT, Wicket, giusto per citarne alcuni tra i più noti. Ognuno è orientato allo sviluppo di web application a modo suo, chi più orientato al pattern MVC, chi più action-oriented, chi più component-based, chi con un forte supporto alla IoC/DI (Inversion of Control/Dependency Injection), ecc....

    Paolovox ha scritto:


    Una socket server-side scritta in C non potrebbe soddisfare le stesse richieste utilizzando anche il multithreading?
    "Nì" (sì e no). Tecnicamente sarebbe anche fattibile. Ma ci sarebbero non pochi problemi. Innanzitutto tutti gli aspetti tipo multi-threading, concorrenza/sincronizzazione, internazionalizzazione, gestione caratteri Unicode, gestione di database e sicuramente altro, non sono affatto "standard". Richiedono l'uso o di API native del sistema o di librerie di terze parti la cui "portabilità" (su altri S.O.) non è detto che sia garantita e/o facile.
    Inoltre c'è comunque il problema della gestione della memoria e dei potenziali memory-leak. Se non c'è un garbage collector (come in Java, .NET o altri linguaggi), rischi molto grosso specialmente nelle web application.
    Una web application deve poter stare "su" in runtime anche per giorni. Se ad ogni request dai client causi un memory-leak anche piccolo (es. 10 KByte), ti lascio immaginare l'occupazione di memoria a fine giornata ...

    Quindi: se vuoi farti del male, sì, sviluppa pure una webapp in C/C++.
Devi accedere o registrarti per scrivere nel forum
4 risposte