Visualizzazione dei risultati da 1 a 5 su 5
  1. #1
    Utente di HTML.it
    Registrato dal
    Jan 2007
    Messaggi
    484

    Oggetto proxy di un application server

    Buonasera,
    qualcuno sarebbe così gentile da spiegarmi in modo semplice cos'è l'oggetto proxy di un application server?
    Ho provato a cercare online del materiale ma non ho trovato niente a me comprensibile.

    Grazie anticipatamente.

    tulipan

  2. #2
    Quote Originariamente inviata da tulipan Visualizza il messaggio
    cos'è l'oggetto proxy di un application server?
    Detto così vuol dire poco/nulla. Se intendi il "proxy" a livello di networking: https://it.wikipedia.org/wiki/Proxy
    Se intendi altro (es. il Design Pattern Proxy) allora è un'altra cosa ...
    AndreaSenior Java developerSCJP 5 (91%) – SCWCD 5 (94%)
    Il mio nuovo sito-blog italiano sulla programmazione: andbin.it

  3. #3
    Utente di HTML.it
    Registrato dal
    Jan 2007
    Messaggi
    484
    scusi , intendo il Design pattern Proxy.

  4. #4
    Quote Originariamente inviata da tulipan Visualizza il messaggio
    scusi , intendo il Design pattern Proxy.
    https://it.wikipedia.org/wiki/Proxy_pattern

    Se hai dubbi, chiedi pure.
    AndreaSenior Java developerSCJP 5 (91%) – SCWCD 5 (94%)
    Il mio nuovo sito-blog italiano sulla programmazione: andbin.it

  5. #5
    Utente di HTML.it
    Registrato dal
    Jan 2007
    Messaggi
    484
    mi scusi ancora ma riflettendo ho capito che ho formulato male la domanda......Io intendevo dire che mi hanno detto che gli EJB vengono salvati in una coda e quest'ultima ha a che fare con un oggetto proxy (il design pattern). Io vorrei sapere come avviene tutto il processo.
    Non so se è chiaro quello che voglio dire!

  6. #6
    Quote Originariamente inviata da tulipan Visualizza il messaggio
    Io intendevo dire che mi hanno detto che gli EJB vengono salvati in una coda e quest'ultima ha a che fare con un oggetto proxy (il design pattern). Io vorrei sapere come avviene tutto il processo.
    Non so se è chiaro quello che voglio dire!
    Sì, ora è chiaro. E sì, riguardo gli EJB, il concetto di "proxy" c'entra eccome! Innanzitutto non è proprio corretto parlare di "coda" ma semmai di un "pool" di bean.

    Prendiamo per esempio un bean EJB di tipo "stateless". Si fa prima la interfaccia locale di "business", es.:
    codice:
    @Local
    public interface MessageSenderLocalBusiness {
        void sendMessage(String text);
    }

    Poi si implementa il bean EJB vero e proprio:
    codice:
    @Stateless
    public class MessageSenderBean implements MessageSenderLocalBusiness {
        @Override
        public void sendMessage(String text) {
            // implementazione per mandare il messaggio da qualche parte ....
        }
    }

    A quel punto si può "iniettare" ad esempio il riferimento all'interno di una Servlet, es.:
    codice:
    @WebServlet("/send-msg")
    public class MessageSenderServlet extends HttpServlet {
        @EJB
        private MessageSenderLocalBusiness messageSender;
    
        @Override
        protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
            messageSender.sendMessage("Ciao");
            messageSender.sendMessage("Hello");
    
            // ....
        }
    }

    Il @EJB indica di "iniettare" lì in quella variabile il riferimento al EJB. Ma il punto fondamentale è che quello che viene iniettato NON è direttamente una istanza della classe MessageSenderBean ma è un "proxy", cioè un oggetto che sicuramente implementa la interfaccia MessageSenderLocalBusiness ma non è il bean EJB e funge solo da tramite. Questo approccio permette al container di fornire tutta una serie di servizi ai bean EJB: security, transazionalità, interceptor, ecc...

    La istanza della servlet di norma è una sola e il proxy iniettato quindi è uno solo ed è lo stesso e resta in "vita" per tutta la durata della servlet.

    Con gli EJB stateless, il container degli EJB può creare molte istanze di MessageSenderBean e tenerle in un "pool" di bean. Ma potrebbe anche crearne uno "al volo" ad ogni necessità e poi distruggerlo subito dopo. Queste sono strategie che possono variare da un application server all'altro e possono anche eventualmente essere configurate in qualche modo.

    Per il programmatore il concetto essenziale da sapere sugli EJB stateless è il seguente. Se ci sono nel pool 4 istanze di MessageSenderBean, #1, #2, #3 e #4, ad ogni invocazione di sendMessage il proxy sceglie un bean su cui dirottare la chiamata.

    Ad una chiamata di doPost, il primo sendMessage("Ciao") potrebbe passare nel bean #1, il secondo sendMessage("Hello") potrebbe passare nel bean #3.
    Ad una seconda chiamata di doPost, il primo sendMessage("Ciao") potrebbe passare nel bean #4, il secondo sendMessage("Hello") potrebbe passare nel bean #2.

    Il senso di "stateless" è relativo al fatto che non deve essere mantenuto nel bean uno "stato" che sia usato per fare "conversazione" tra più chiamate al bean. Ogni chiamata di un metodo deve essere a sé stante, proprio perché il proxy può far passare la chiamata nel bean che preferisce.

    Come il proxy venga creato e implementato da un application server, generalmente non è particolarmente importante per il programmatore. Per quanto ne so, se ben ricordo di aver letto, ad esempio JBoss sfrutta il dynamic proxy del JDK 1.3+ (java.lang.reflect.Proxy)
    AndreaSenior Java developerSCJP 5 (91%) – SCWCD 5 (94%)
    Il mio nuovo sito-blog italiano sulla programmazione: andbin.it

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2020 vBulletin Solutions, Inc. All rights reserved.