Application Server
Marco Sambin
imparare quindi non escludo che le domande che sto per porre siano banali o
persino ridicole. Se cosi' fosse, chiedo scusa in anticipo.
Premetto anche che prima di scrivere ho cercato nel web: probabilmente ho
frugato nei posti sbagliati, rimane il fatto che ho ancora molta confusione
in testa. Se scrivo qui, quindi, e' perche' attualmente non so dove sbattere
la testa, non per pigrizia.
La situazione e' questa: devo mettere su un progetto che faccia utilizzo di
java, jsp, servlet. La prima soluzione che mi e' venuta in mente e' stata
java+tomcat, cosi' ho installato entrambi gli applicativi e, usando
Netbeans, ho iniziato il lavoro.
Ieri pero' parlavo con un collega, il quale mi consigliava di valutare se
valesse la pena usare Tomcat, oppure piuttosto un prodotto piu' complesso
quale Jboss.
Pur non avendo mai sentito nemmeno nominare Jboss (sono un novizio di java,
appunto), mi son detto che valeva comunque la pena informarsi, visto che
attualmente lo sviluppo e' appena cominciato e che quindi sono ancora in
tempo a cambiare ambiente, se ne valesse la pena.
Purtroppo, girando per la homepage di Jboss (ma non solo li), non son
riuscito a farmi un'idea di cosa questo prodotto esattamente sia. Ho capito
che e' un'estensione di un normale application server (ed infatti contiene
Tomcat al suo interno), ma non mi e' chiaro quali siano gli "extra" che
mette a disposizione rispetto il normale Tomcat. E questa e' una questione
che invece mi dev'essere chiara, dal momento che devo decidere quale dei due
mi conviene usare. Senz'altro Jboss e' piu' completo, ma mi sembra anche
piu' complesso, volevo percio' capire se il gioco vale la candela, tenendo
conto che non so cosa siano i "Javabeans", e che quindi, se decido di
passare a Jboss, comunque dovrei studiare --> investire tempo.
Non che la cosa mi spaventi, solo devo capire se vale la pena o se Jboss e'
uno strumento invece eccessivamente sofisticato per quel che devo fare.
Quindi, ecco le domande:
- A che tipo di soluzioni e' orientato Jboss?
- Cosa offre in piu' Jboss rispetto a Tomcat?
- Uno dei motivi che potrebbe spingermi ad usare Jboss e' che avro' bisogno
della possibilita', da parte dell'application server, di istanziare delle
classi ed eseguirne dei metodi non a fronte di una chiamata esterna da una
jsp, ma al verificarsi di un evento specifico. Ad esempio: se viene inserita
una riga nella tabella PIPPO, voglio che venga avviato un metodo che
gestisca l'evento. Oppore: alle ore 12.00 di ogni giorno, o ogni 30 minuti,
voglio venga eseguito un metodo. Oppure: non appena un file viene scritto
all'interno di una directory, voglio venga eseguito un metodo. Tomcat e' in
grado di gestire simili situazioni o gestisce solo richieste via http?
- Lo sviluppo con Tomcat e' tutto sommato agevole. Lo e' altrettanto con
JBoss?
- Esiste online un sito, un documento, un corso che possa chiarirmi le idee,
considerando che, come potrete notare, sono un novizio in ambito java e
tutto cio' che vi ruota attorno?
- Ultima domanda: ho installato jboss. Tutto ok. Poi ho voluto provare ad
installare un "template" di progetto, anche solo per farmi un'idea di cosa
avessi tra le mani. Ho seguito le istruzioni, installando ant, e quant'altro
richiesto. Solo che, seguendo le istruzioni alla lettera, al momento del
lancio mi trovo la seguente eccezione:
javax.naming.NameNotFoundException: test not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:495)
ecc...
Avete idea di quale possa essere la causa?
Grazie mille: attendo fiducioso.
Giulio
http://www.mokabyte.it/2003/04/jboss-jndi.htm
e vedi se ti può essere utile.
--------------------------------
Inviato via http://usenet.libero.it
Marco Sambin
"Giulio" <hem...@wooow.it> ha scritto nel messaggio
news:217Z133Z121Z7Y1...@usenet.libero.it...
> Prova a leggere questo:
>
> http://www.mokabyte.it/2003/04/jboss-jndi.htm
>
> e vedi se ti può essere utile.
L'avevo gia' trovato, nel mio peregrinare prima del post, ma non risponde
purtroppo alle mie domande. Spiega com'e' strutturato, ma non mi aiuta a
capire se e' vantaggioso usarlo al posto di un semplice Tomcat.
Grazie lo stesso.
Cristiano Sadun
news:4_Jya.20085$Ny5.5...@twister2.libero.it:
> java, jsp, servlet
La cosa migliore e' semplicemente guardare nelle pagine di overview di
Tomcat e JBoss.
Tomcat e' principalmente un servlet engine. Siccome le JSP sono fondate e
strettamente in rapporto con le servlet, fa anche da JSP engine. E siccome
un servlet engine di solito si usa associato ad un web server, c'e' anche
impacchettato un piccolo web server.
JBoss e' un application server J2EE. Cio' significa che fornisce i servizi
J2EE - enterprise java beans, queueing, transaction management,
connection pooling, JNDI, security eccetera.
Siccome 'sti servizi oggidi' si usano molto spesso per web application,
vien fuori che e' quasi sempre necessario avere un application server che
_contiene_ un servlet engine (e di conseguenza supporta servlet e JSP).
Ergo, una delle distribuzioni di JBoss decide di usare Tomcat come servlet
engine e viene fornita con impacchettato Tomcat e una pre-configurazione di
base per usare Tomcat *dentro* JBoss.
--
Fighting for peace is like fucking for virginity
ObjectZone - http://space.tin.it/computer/csadun
Marco Sambin
"Cristiano Sadun"
> JBoss e' un application server J2EE. Cio' significa che fornisce i servizi
> J2EE - enterprise java beans, queueing, transaction management,
> connection pooling, JNDI, security eccetera.
Ok, il punto e' che mi serve chiarire se dieto ai nomi che tu citi, in parte
noti, in parte sconosciuti, esiste quel che mi serve.
A me serve, come detto, un servlet engine, un database, ed un meccanismo che
mi scateni dei metodi a fronte di certi eventi (l'inserimento di una riga in
una tabella, o la scrittura di un file, o anche semplicemente un metodo che
gira ogni tot minuti).
E' chiaro che se scoprissi che con Tomcat riesco a far tutto, non vado ad
incasinarmi la vita con un qualcosa di cui conosco solo il nome. Al database
gia' accedo, il servlet engine e' Tomcat stesso, l'unica incognita riguarda
l'esigenza di cui ti ho parlato.
Cristiano Sadun
>
> "Cristiano Sadun"
>
>> JBoss e' un application server J2EE. Cio' significa che fornisce i
>> servizi J2EE - enterprise java beans, queueing, transaction
>> management, connection pooling, JNDI, security eccetera.
>
> Ok, il punto e' che mi serve chiarire se dieto ai nomi che tu citi, in
> parte noti, in parte sconosciuti, esiste quel che mi serve.
Siccome il problema e' tutto nel dettaglio dei "meccanismi" che ti servono,
per risponderti bisognerebbe sapere esattamente cosa vuoi. Siccome pero'
tomcat fa quello che abbiamo detto non pare sufficiente. Quei "meccanismi"
non li offre (anche se certamente sono _implementabili_ con esso). Idem per
J2EE. Quale delle due sia piu' facile dipenda da cosa esattamente sono i
"meccanismi".
Marco Sambin
"Cristiano Sadun" <cris...@xtractor.com> ha scritto nel messaggio
news:Xns93835E8C16C4Bcr...@130.133.1.4...
> "Marco Sambin" <Sam...@yahoo.it> wrote in
> news:9iLya.20359$Ny5.6...@twister2.libero.it:
>
> >
> > "Cristiano Sadun"
> >
> >> JBoss e' un application server J2EE. Cio' significa che fornisce i
> >> servizi J2EE - enterprise java beans, queueing, transaction
> >> management, connection pooling, JNDI, security eccetera.
> >
> > Ok, il punto e' che mi serve chiarire se dieto ai nomi che tu citi, in
> > parte noti, in parte sconosciuti, esiste quel che mi serve.
>
> Siccome il problema e' tutto nel dettaglio dei "meccanismi" che ti
servono,
> per risponderti bisognerebbe sapere esattamente cosa vuoi.
Okkey, entro nel dettaglio.
Devo mettere su un servizio client-server (explorer-web server) dove sia
concesso a chi si connette di poter lanciare sul server delle attivita' che
richiedono un certo tempo. Nello specifico il rendering di un oggetto
tridimensionale. Cosi' Tizio si collega alla pagina, inserisce i dati
relativi a come vuole che sia fatto l'oggetto, clicka su GO e parte nel
server il CAD che in base alle richieste di Tizio gli produce il modello 3D.
Ora: il processo di rendering, come detto, e' lungo, e non ha pertanto senso
costringere Tizio ad aspettare col browser inchiodato fino al termine
dell'elaborazione, ma a tizio dovrebbe spuntare qualcosa tipo "Il rendering
e' in esecuzione, passa tra poco per vedere se ha finito".
Non solo: il processo di rendering non puo' essere avviato in parallelo ad
un altro rendering in esecuzione, cosi' se Tizio ha richiesto un oggetto 3D
che richiedera' un'ora di lavoro, e Caio arriva 5 minuti dopo Tizio,
richiedendo anche lui un rendering, il rendering di Caio dovra' per forza
iniziare 55 minuti dopo la richiesta.
La strada migliore sembrerebbe quindi il mettere in piedi una sorta di
meccanismo di coda: il jsp-server si limita ad accettare le richieste degli
utenti e di inserirle in una coda. Parallelamente, un task deve verificare
periodicamente se esistono richieste in coda. Se si, deve lanciare la prima
richiesta presente nella coda, passandola al CAD, e, terminata
l'elaborazione, deve rendere visibile nel server il prodotto finito (cosi'
Tizio potra' prenderlo). Se la coda e' vuota, il task deve terminare per
essere schedulato in seguito, non appena qualcuno fara' una richiesta.
Insomma in sostanza una sorta di "demone", un task che si attiva in
parallelo al jsp-server, che rimane "dormiente" (ma comunque in esecuzione)
quando non c'e' lavoro da fare, e che invece deve svegliarsi non appena
qualcuno richiede qualcosa, lavorando fino allo svuotamento della coda.
Ovviamente questo task non deve assolutamente interferire con il jsp-server
ma deve lavorare in parallelo.
Mi era stato detto da qualche collega che J2EE gia' prevede meccanismi tipo
quello che ti ho appena descritto, ed io, non conoscendo affatto J2EE
(fatico ancora a capire di preciso cosa sia), non ho faticato a credergli.
Ti domando: esposto il problema, ed esposta la naturale esigenza di
prevedere che in futuro il semplice servizio web possa diventare piu'
complesso e multifunzionale, cosa mi consigli?
Grazie mille.
Cristiano Sadun
> La strada migliore sembrerebbe quindi il mettere in piedi una sorta di
> meccanismo di coda: il jsp-server si limita ad accettare le richieste
> degli utenti e di inserirle in una coda. Parallelamente, un task deve
> verificare periodicamente se esistono richieste in coda.
Ci sono vari design possibili. Uno che non fa uso di code, ad esempio (per
cui basta Tomcat) e':
- la tua JSP/Servlet J riceve una richiesta su un url A e si limita a
lanciare un thread di calcolo C (magari controllando se un thread per una
richiesta identica e' gia' in esecuzione) e ritorna una pagina TEMP che fa
auto-refersh ogni tot secondi verso un url B, passando un nome-file
temporaneo F.
- C fa il suo lavoro e _alla fine_ produce F, e invia un messaggio sulla
coda.
- B si limita a verificare se, F esiste o no. Se non esiste, ritorna una
pagina TEMP identica. Se esiste, ritorna una pagina TEMP1 in cui (con un
opportuno parametro della request) comunica che _al prossimo refresh_ (dopo
un certo tempo Z) si dovra' servire il file F risultato (questo per dare
una certo tempo a C di completare F). La cosa migliore e' che F costruisca
il risultato in un certo file F1 e ne faccia un rename alla fine, cosi' Z
deve bastare solo per il tempo di renaming (che e' abbastanza costante o
cresce poco col carico), e non di produzione (che invece puo' crescere
notevolmente col carico).
- Voila'
Questo design e' ragionevole fino a carichi medi - dato che si concentra
tutto su un unica JVM. Estenderlo per supportare computazione distribuita
e' fattibile, ma non semplicissimo: per scalare a carichi grandi, la cosa
piu' facile e', come dici, usare code - e qui conviene usare J2EE:
- J invia un messaggio M su una coda C e ritorna una pagina TEMP che fa
autorefresh su un url B
- Un message-driven bean MB viene attivato da M e inizia la computazione
- quando la computazione e' terminata, MB scrive F e invia un messaggio
END su C
- La servlet che risponde a B verifica se C contiene END. Se si', serve F.
Se no, serve TEMP.
Ci sono infinite variazioni, ovviamente, ma il succo e' qui. :)
legolas
diciamo (molto sinteticamente) che se hai bisogno di far funzionare
jsp/servlet e javabean esterni, puoi realizzare benissimo
il pattern Model View Controller solamente con Tomcat senza far uso di
JBoss.
Tomcat è un motore di servlet e non un application server vero e proprio.
Se invece ti trovi ad affrontare applicazioni enterprise in cui ti servono
EJB (Enterprise Java Bean) allora non è sufficiente Tomcat
ma è necessario JBoss cioè un application server.
Se le applicazioni sono web oriented allora dovrai integrare anche il web
server. Infatti esiste la versione JBoss con Tomcat integrato.
Sugli EJB ci sono milioni di cose da dire e ti consiglio di scaricarti e
leggerti il "preziosissimo" libro su www.javaportal.it di Fabrizio Marini.
Inoltre JBoss ti offre una miriade di altri servizi ma le caratteristiche le
puoi trovare benissimo in rete con goole (load balancing, pooling di
risorse,DataSource, atomicità transizioni...etc molto etc.....)
ciao
legolas
ab
<disclaimer>
Mai usato JBoss e non conosco bene neppure tomcat
</disclaimer>
Secondo me, ma potrei sbagliarmi (vedi disclaimer), i meccanismi
di cui hai bisogno non si ritrovano normalmente in un application
server. L'invocazione di metodi a fronte di:
1) l'inserimento di una riga in una tabella
2) la scrittura di un file
3) tempo
(senza neanche perder tempo a valutare la correttezza dell'approccio,
vale a dire senza chiedersi se la soluzione più adatta al problema sia
veramente quella di invocare un metodo quando viene inserita una riga
in una tabella, piuttosto che altre)
dovrebbero/potrebbero essere competenza, rispettivamente, di:
1) database, utilizzando i trigger
2) classi specializzate (sviluppate in casa o meno)
3) schedulatore (vedi "cron", "at", etc)
Ciao