Newsgroup: it.comp.java
Titolo: EJB vs. resto del mondo

Un saluto a tutti quanti.
Mi interessava avere un vostro parere sull'opportunità o meno di 
utilizzare le funzionalità EJB per progetti "importanti".
Riformulando la domanda perché sia meno terribilmente generica: al di là 
delle abitudini consolidate in certi ambienti per le applicazioni 
"Enterprise" che cosa  in un progetto vi farebbe propendere decisamente 
per l'utilizzo di EJB?
Voglio dire che al momento esistono alternative più "leggere" ad alcuni 
dei problemi che ci si proponeva di risolvere con EJB (componenti 
riutilizzabili, accesso remoto e distribuito ai componenti, transazioni, 
persistenza ecc.), penso a strumenti come Spring Framework o Hibernate 
ma anche semplicemente all'utilizzo di web services per l'accesso 
remoto. Ok, nessuno di questi strumenti (e forse neanche tutti insieme) 
sostituiscono in tutto e per tutto EJB ma trovo che in moltissime 
situazioni (tutte?) possono contribuire a far trovare soluzioni con 
codice più pulito, più semplice, più "naturale", direi più "Object 
Oriented" per quello che era l'obiettivo iniziale di questo tipo di 
programmazione.
Grazie a chi vorrà dare il suo parere

 per l'utilizzo di EJB?
Concretamente, nessuna :)
Come dici bene te piu' in avanti una buona fetta delle funzionalita'
degli EJB sono facilmente utilizzabili con altre tecnologie.
Spesso pero' e' il cliente che esige una soluzione basata sugli EJB (O
su un determinato Application Server / EJB Container), a volte perche'
non ne capisce molto, a volte per via di "policy" aziendali molto strette.
IMHO, credo che con EJB3 abbiano comunque smussato diversi spigoli
dolorosi, EJB non e' ancora morto !
-- 
Giambo - Occhio al filtro antispam _e_ alla whitelist !

Non c'è nessuna valida ragione per sviluppare un importante progetto
basato totalmente sugli EJB. Anche l'ultima ragione che era rimasta,
ovvero esportare servizi verso altre applicazioni, è stata superata
dall'affermarsi dei WebServices, che peraltro consentono l'integrazione
anche al di fuori del mondo J2EE.
Se stai alla larga dagli EJB per un progetto importante è sicuramente
molto meglio, sia per quanto riguarda la complessità del disegno
dell'applicazione, sia per problemi di performance, sia per
manutenibilità del codice ed infine per problemi legati agli skill
degli sviluppatori (quanti programmatori Java conoscono davvero gli EJB
?).
Nella mia esperienza professionale le uniche organizzazioni che
richiedono esplicitamente EJB sono le grandi aziende soprattutto banche
ed assicurazioni. In queste aziende i processi decisionali sono molto
frammentati: chi sa cosa è J2EE non decide e chi non sa cosa è J2EE
decide... Spesso i 'decisori' si fanno guidare da consulenti esterni
(primi tra tutti IBM) che amano riempirsi la bocca con paroloni e
sigle... Tanto poi non sono loro a dover sviluppare e far funzionare le
applicazioni.

 per l'utilizzo di EJB?
Credo che accetterei di sviluppare per EJB se dovessi condividere le
business rules con altri progetti.
Questo per evitare di distribuire le business rules tra i client
o rimanere legato ad un particolare DBMS con le stored procedures.
.NET lo eviterei per non legarmi ad un solo fornitore.
Altri middleware non li vedo tutti i giorni, sarebbe interessante
se qualcuno esponesse le proprie esperienze.
--
Marco

 o rimanere legato ad un particolare DBMS con le stored procedures.
ma se il problema è avere una interfaccia remota per le business rules 
non bastano i web services? (o magari anche solo RMI che è un pezzo di 
J2EE ma non richiede necessariamente EJB...).

non bastano i web services?
Appunto !!! Con il grosso vantaggio che usando WebServices queste
business rules sono utlizzabili anche da applicazioni .NET per esempio.


I web services li intendo a "grana grossa": eventualmente aggregano
piu' processi di business in chiamate di alto livello. Non ti sembra
troppo pesante serializzare e deserializzare in XML i dati su cui far
operare le regole di  business, magari molto frequentemente ?
All'inizio della discussione citavi Spring+RMI: sinceramente non l'ho
mai esaminato. Qualcuno puo' spiegare come faciliterebbe la vita per
-esprimere dei vincoli su piu' entita'
-implementare regole di accesso
insomma quanto meno devo lavorare se esco dall'ambiente EJB ?
Quanta altra gente capirebbe il tuo lavoro realizzato
appogiandosi a Spring piuttosto che agli EJB ?
Se voglio valorizzare le business rules uno degli aspetti che
prediligerei sarebbe proprio quest'ultimo.
--
Marco


Non mi sembra cosi' difficile consumare business rules
EJB da .NET:
http://www.codeproject.com/csharp/iiop_net_and_EJB.asp
http://dev.mainsoft.com/Default.aspx?tabid=48
--
Marco

 J2EE ma non richiede necessariamente EJB...).
I web service sono come una 500 e gli EJB una Porche
Entity.
SOno andati sotto accusa, in gran parte a ragione , poi per un effetto
"moda" c'e' stato un eccesso di critica
Session
Nessun difetto
Hibernate
e' un framewark di persistenca, poi usandolo ho scoperto che di fatto e' "Il
databse"
Andra' negli entity 3 della Sun, quindi di fatto e' ejb
Spring e' una pattern/frame
nato per superare il vecchio caro Struts ma poi fa molto altro.
puo' andare con ejb o senza
GLi Ejb
per il programmatore
sono semplicemente classi con un un interfaccia xml di descrizione
Poi pero' hanno "Sotto" un App Server che e' un la base di tutti il J2ee
NOn usare gli ejb vuol dire scrivere tutto nelle Serclet
Su una scala da 0 a 10 di buona Architettura n tier vuole dire decidere di
fermarsi a 7
Una architettura completa comprende
client - servlet / jsp - action - session -entity ( stgrato persistente) -
dati
il 90% della logica va nei Session
questo e' il j2ee
quello che .Net ha ancora embrionale, per come e' nato forse non avra' mai
quello per cui Java rimane meglio di tutti lato Server.
Comprendo che i costi di sviluppo e manutenzione lievitano come il pan di
Spagna, ma l'alternativa e' fare applicazioni di qualita' inferiore
architetturalmente inferiori
Sorry ma hoi da fare, magari se vuoi discutiamo anche nei giorni prossimi
e' mio campo di alvoro e sono uno strenuo difensore di tutto il J2ee pur
ormai avendone ben chiari i difetti, derivati quasi sempre dall'uso
improprio della tecnologia, cioe'usando teconologie sovradimensionate per
progetti di dimensione media.
ciao Nicola
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 progetti di dimensione media.
forse è sempre la mia immaginazione limitata che non riesce a concepire 
  progetti di dimensione grande. Anche un'applicazione grande la 
immagino sempre come una serie di applicazioni medie (o piccole) che 
interagiscono tra di loro in maniera anche complessa ma che mi sembra 
sempre risolvibile con mezzi che non siano EJB.


che significa E' IL DATABASE ? 


Nell'uso + corretto si genera il DB a partire dagli hbm
quindi il DB sono gli hbm
di fatto le tabelle generate puoi anche non vederle + in relazionele, cosa
che fra l'altro manco ha molto senso +, visto il casino che crea per fare i
sottotipi ad esempio


 necessario
Questione legittima, visto il fatto che la stessa SUN per andare incontro
agli sviluppatori ha deciso di redisegnare l'API Ejb, proprio xchč si tratta
di strumenti sicuramente interessanti ma che richiedono tool di sviluppo
evoluti per gestire in tempi umanamente accettabili le fasi di test, deploy,
generazione del codice di distribuzione etc.
La risposta alla tua domanda non č certamente semplice: io sono dell'avviso
che gli EJB *oggi* siano lo standard Sun per la costruzione di architetture
distribuite (logica di business e logica di accesso ai dati) e, come
standard, siano da preferirsi a soluzioni come Hibernate o Spring che pur
gravitando strettamente nell'orbita di J2EE, standard non sono.
Non dico che siano soluzioni poco valide: pur non usandoli, ne sento parlare
bene, e personalmente mi piacerebbe provarli. Aggiungo, inoltre, che
questi framework (soprattutto JDO ed Hibernate) hanno tra gli altri meriti 
quello di aver
fatto emergere numerosi aspetti di EJB che ne rendono l'uso poco pratico... 
tant'č che Sun
č stata costretta a "ripensare" il mondo EJB.
Non so quando EJB 3.0 sarŕ pronta e vi saranno application server a livello
J2EE 1.5;ma quando saranno disponibili, preferiresti  aderire ad uno
standard accettato da tutti i maggiori vendor o scegliere un framework 
opensource, sia pure
bello e sviluppato da programmatori di  talento, come Hibernate ?
Scorpio.

 bello e sviluppato da programmatori di  talento, come Hibernate ?
si, anche io tendo a preferire gli standard (soprattutto se propugnati 
dai creatori del linguaggio stesso...) ma al momento queste sono ipotesi 
e lo standard EJB utilizzato non è ancora 3.0 né mi è ancora molto 
chiaro come si evolverà 3.0 (probabilmente mia ignoranza).
Comunque Hibernate è un tool di mappatura Object/Relational e non un 
"talentuoso" framework open source che si propone di sostituire EJB ;-)
P.S.
tra l'altro anche JDO è uno standard propugnato (tra gli altri) da Sun e 
(sempre tra l'altro) implementato anche da vari tool open source (ad 
esempio speedo).

 esempio speedo).
JDO quasi = a hibernate
PEr continuare il dibattito.
A mer piaca l'idea che gli input mi arrivano nelle servlet e li cracco e li
preparo
a logica sta in puri oggetti di logica quali i session stateless
il carrellino e' negli stateful
i messaggi nei MDB
il DB enegli entity
le prestazioni le controllo sui monitor dell'appserver
GLi interfacciamenti con sistemi esterni li gestiscono i servizi vari
dell'appserver con "dietro" un ejb dedicato
Insomma e' una questione di ordine di eleganza, chiamalo come vuoi, il costo
aggiuntivo nel realizzare tutto cio' lo dovresti poi comunque bilanciare con
la facilita' di manutenzione, di inserimentio di nuove persone al progetto
che sanno gia' dove trovare ogni cosa eccetera.
Cme dicevamo l'alternativa quale e' :
in una servlet mi instanzi 100000 package che se fatti mali conterrano
logica di businesss, logica dati, logica di integration
il solico calderone stile Microsoft insomma, da cui sempre cerchiamo di
differenziarci in qualita' spero.
