Newsgroup: it.comp.java
Titolo: Ejb e web application

Ciao , sto studiano enterprise java Bean  e mi pare di aver capito che
rientrano principalmente nell'ambito di un applicazione web (standard
MVC) deployato su un application server (che non sia Tomcat),è esatto?


No.
Gli ejb nacquero con vari intenti :
1) integration, nel senso che all'inizio un un ejb era chiamabile anche da
sw non java via CORBA. QUesto intento di fatto e' fallito e dimenticato.
2) Utilizzabilita' in un amboente scalabile e trasportabile aziendale. PEr
aziendale significa come avviene quasi sempre , un ambiente dove
l'applicazione e' distribuita su vaiie macchine, con SO differenti,
privilegi minimi o nulli. Questo intento e' c'entrato in pieno
3) Load balancing. Quando dici Application server "non tomcat" significa
application server con ejb container, che in pratica e' Jboss, Websphere e
BEa sono matti chi li compra perche' non fanno nulla piu' di Jboss che e'
free.
4)Transaction. Gli ejb hanno una gesytione "enbedded" deflla transaction sia
di dati ( db ) che di logica, cioe' se fallisce qualcosa viene rollbackata
tutta l'operazione
5) Dati. Gli ejb 3 oggi di fatto hanno inglobato l'ex hibernate che poi
sparira'. PEr sisntetizzare gli ejb offrono l'accesso a database
persistente, cioe' cachizzato in memoria, multi database, cioe' non
dialettale e a oggetti, cioe' trasoformano il db relazionale (
Postgres/oracle/SQLserver, per capirci ) in un db a oggetti come VErsant per
capirci. I db a oggetti per motivi pragmatico logistici non sono mai
decollati pur essendo ovviamente migliori dell'sql dei lontani anni 70 che
usiamo oggi. Con hibernate in pratica trasformi un db relazionale in un db a
oggetti, ovvviamente a scapito delle prestazione, che comunqe oggi non sono
quasi mai determinanti ( videogame a parte )
6) jndi. Gli ejb stanno sotto jnbsi, cioe' una naming convention
potentissima che permette di localizzare gli oggetti. Questo fu all'inizio
degli ejb un pronlema piu' che un vantaggio, oggi e' una cosa favolosa che
semplifica elgantemente la programmazione
Io utilizzo ejb anche in tomcat 5.5 inserendoci il microcontainer JBoss.
Mi pare che nel tomcat 6 vanno e basta.
Una volta Tomcat era inferiore agli altri sul load balancing, oggi credo che
piano piano li stia raggiungendo perche' scrivere un loadbalancer non e'
un'impresa da marziani.
Gli appserver entro pochi anni spariranno tutti dal software perche' di
fatto offrono dei servizi basilari che sono tipici dei sistemi operativi e
quindi oggi c'e' una ridonza e una inutile complicazione.
Se inizi oggi con ejb ovviamente usa ejb3. Ti studi 2 concetti e poi li usi
e basta sono abb semplici.
per ogni altro dubbio sugli ejb chiedi pure visto che per motivi personali
ho utilizzato, studiato odiato e amato gli 1 , i 2 i 3 .
Forse puo' anche ricordare megadix che scrive qua, che avevamo chiamato nel
2000 un guru corba/ejb dalla norvegia, che pagavammo cifre pazzesche al
giorno, e che parlava con un tono morbido e vellutato tanto che io mi
addormentai al corso :-)))))
Ciao e buon lavoro
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Mi pare che nel tomcat 6 vanno e basta.
Sempre con il microcontainer di JBoss pero', che tra l'altro mi sembra 
essere in alpha.
Visto che ci sei, mi diresti se con Seam e' possibile e in che modo 
utilizzare bean remoti? O il tutto va solo con i locali? Nel secondo 
caso che senso ha a quel punto tirarsi avanti il carrozzone EJB?
Ho come l'impressione che se volessero potrebbero portalo totalmente 
fuori da EJB come Spring (JPA a parte), ma per qualche strano motivo non 
lo vogliano fare.

 quindi oggi c'e' una ridonza e una inutile complicazione.
Interessante considerazione. A dire il vero non sono d'accordo, anche se 
IMHO hai centrato un problema
non da ridere.
Il compito di un appserver è tra le altre cose proprio quello di fornire dei 
servizi  di base, come giustamente
li chiami tu, a prescindere dal sistema operativo su cui li installi. Questa 
è una forza fondamentale per J2EE, che
se tutti ormai sappiamo che non realizza una portabilità tra vendor diversi, 
realizza una portabilità all'interno dello stesso vendor. Per esempio se io 
sviluppo un'applicazione J2EE per WebSphere su Linux, so che questa potrà 
essere installata senza troppi problemi su WebSphere su AIX.; non è così 
vero che un'applicazione per WAS sia deployabile senza problemi su WebLogic, 
ma questo è un'altro capitolo.
Non pensi che venendo meno il ruolo di un appserver - che di J2EE è una 
implementazione - venga meno il ruolo di J2EE stessa ? La domanda non è 
retorica nè provocatoria; se hai studiato gli EJB penso che avrei sentito 
parlare, ad esempio, della ..... apostasia, passami il termine, di 
Monson-Haefel che, dapprima grande sostenitore della tecnologia EJB, poi ha 
cambiato radicalmente idea.
Che ne pensi ?
Ciao,
    Scorpio.

 che senso ha a quel punto tirarsi avanti il carrozzone EJB?
Bella  domanda.... a cui non è certo facile dare una risposta. Gli EJB sono 
davvero utili, o sono strumenti superflui ?
Scorpio. 

 davvero utili, o sono strumenti superflui ?
Mi sembra difficile credere che siano superflui in generale?
La domanda da farsi è "quando possono essere utili?".
Io non so la risposta.
Sapendone poco mi viene da pensare che potrebbero essere utili quando è 
importante distribuire il calcolo su un cluster composto da diversi 
server in base a quanto sono carichi.
Boh?
-- 
Andrea Francia
http://www.andreafrancia.it/

 Scorpio.
Ciao Nicola


 eliminarlo spostando le feature o negli applicativi o nei SO
Già, ma questo vorrebbe dire integrare la JVM nel SO. In effetti questo 
darebbe un nuovo impulso alla programmazione Java, ma sarebbe una legnata 
sui denti ai vendor di J2EE.
Questo non so fino a che punto sia un bene per i destini del nostro caro 
linguaggio...


 linguaggio...
Secondo me e' in piena sslute il linguaggio, siamo sostanzialmente al
monoplio totale


 monoplio totale
Non so. La forza di Java č stata di essere multivendor, ora Sun ha 
coraggiosamente aperto al mondo open. Questo fornisce ottimi prodotti (e 
ottimi sistemi operativi), ma non pensi che sia difficile senza un supporto 
alle spalle reggere alla concorrenza ad esempio di .NET ?
Scorpio.

 Del resto lo stesso tomcat ormai e' in concorrenza con gli appserver
Poi c'e' anche glassfish che è gratuito. Anche se non so quanto è 
performante.


Scorpio ha scritto:

Veramente la mia domanda era rivolta a Seam e non a EJB. Non ho dubbi 
che un EJB remoto possa avere la sua utilita' in alcuni particolari 
contesti.
Quello che dico io e' che Seam non gestendo in alcun modo gli EJB remoti 
(cosi' mi sembra di aver capito) potrebbe benissimo essere implementato 
sopra Spring. Perche' insistono tanto su tutto il carrozzone EJB3 
allora? Forse per spingere l'application server di JBoss.
Resta comunque il fatto che Seam va alla grande anche solo in Tomcat e 
senza alcun microcontainer EJB, pero' perdi alcune delle piu' avanzate 
feature. Forse questa differenziazione non era proprio necessaria.
Magari mi sbaglio eh.

 Scorpio.


 Magari mi sbaglio eh.
Non so, le feature avanzate bisogna vederle una a una, io credo che per
usare tutto liscio liscio ovunque mancano un paio di anni, troopppo casino
in corso nel mondo Java al momento.
ciauz Nicola


 
Boh, mi pare una decina di mega...una cosa piuttosto normale se pensi a 
tutti i jar di apache piu' quelli di Hibernate da aggiungere.
Microcontainer no, non c'e' nulla che possa gestire uno statefull bean 
di EJB ad esempio.

 Nicola
Scorpio. 

 oggi, visto che postgres e mysql mi pare che siano oramai equivalenti.
Guarda che i GROSSI clienti, soprattutto per le applicazioni
"critiche", oltre che al prodotto in sè, guardano anche
all'assistenza.
Ci fai assai con Postgres se poi quando il db si sfascia non sai a chi
rivolgerti (e magari c'è qualcuno allo sportello di un bancomat che
scalpita...:)).
Oltre a ciò, per quanto riguarda IBM, (e parlo sempre per grossi
clienti) in genere IBM offre il pacchetto macchine + WebSphere +
assistenza (+ altre cosette tipo motore di workflow) e quindi alla
fine il cliente - che ha comunque il problema di "sapere" quando c'è
un problema a chi rivolgersi - accetta di buon grado l'offerta all
inclusive.

inclusive.
Posso confermare quanto scrivi: ad esempio dove lavoro abbiamo adottato
WebSphere e non application server open anche per questa ragione...
Scorpio.