rilevante

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

Lemon wrote:

> 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?

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 !

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.

Lemon wrote:
> 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?

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 Trevisan wrote:
> Lemon wrote:
>
>> 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?
>> 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.

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...).

>ma se il problema è avere una interfaccia remota per le business rules
>non bastano i web services?

Appunto !!! Con il grosso vantaggio che usando WebServices queste
business rules sono utlizzabili anche da applicazioni .NET per esempio.

Lemon wrote:
> Marco Trevisan wrote:
>>
> 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...).

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.

Bingo wrote:
>>ma se il problema è avere una interfaccia remota per le business rules
>>non bastano i web services?
>> Appunto !!! Con il grosso vantaggio che usando WebServices queste
> business rules sono utlizzabili anche da applicazioni .NET per esempio.
>

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

Il 17 Giu 2005, 13:28, Lemon <lemon> ha scritto:



> 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...).

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/

n.n wrote:
> Il 17 Giu 2005, 13:28, Lemon <lemon> ha scritto:
>>
>
>>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...).
>> I web service sono come una 500 e gli EJB una Porche
>


non era mia intenzione paragonare EJB e web services anche perché mi
sembra siano cose diverse che risolvono problemi diversi. Anche per
rispondere a quello che diceva Marco: è possibile utilizzare RMI con
spring (nel senso che spring è predisposto per facilitare anche il suo
utilizzo, ci dovrebbero essere in giro vari tutorial).


>
> 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

si, ero a conoscenza di questo, non so se ci andrà anche molto AOP
(Aspect Oriented Programming), secondo alcuni dovrebbe e comunque era
nua cosa che volevo citare tra i "sostituti" (notare le virgolette) di EJB.

La questione che avevo posto era semplicemente se EJB è ancora così
necessario



> Spring e' una pattern/frame
> nato per superare il vecchio caro Struts ma poi fa molto altro.
> puo' andare con ejb o senza
>

ma di fatto nasce per superare alcuni dei problemi che nascono nella
programmazione EJB, per avere architetture più "loosely coupled".


> 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
>



non capisco bene cosa vuoi dire con "scrivere tutto nelle servlet".
Che vantaggio danno i Session secondo te rispetto a pojo + spring?


> 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.


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.

> 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
>

che significa E' IL DATABASE ?

Il 19 Giu 2005, 11:13, "a.g" <sdfs> ha scritto:
> > 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
> >
>
> 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

Nicola


--------------------------------
Inviato via http://arianna.libero.it/usenet/

"Lemon" <lemon> ha scritto nel messaggio
news:3038
> n.n wrote:
>> Il 17 Giu 2005, 13:28, Lemon <lemon> ha
>> scritto:
[CUT]
> La questione che avevo posto era semplicemente se EJB è ancora così
> 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.

Scorpio wrote:
[..]
> 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 ?


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).

Il 19 Giu 2005, 23:17, Lemon <lemon> ha scritto:


> Comunque Hibernate è un tool di mappatura Object/Relational e non un
> "talentuoso" framework open source che si propone di sostituire EJB ;-)

In effetti oggi Hibernate sostituisce gli Entity 2
coi 3 dovrebbe tutto andare in ordine, visrto che i 3 lo hanno ontegrato
loro stessi.
Per i tempi io credo 1 annetto abbondante, visto che i 3 sono appena usciti
in specifica e ora i vendor devono integrarlo e poi noi dovremi upgradare

> 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).

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.

ciao Nicola



--------------------------------
Inviato via http://arianna.libero.it/usenet/