Newsgroup: it.comp.java
Titolo: [lungo] EJB: Oggetto = Dati + Metodi; come si adatta agli EJB?

Ciao a tutti
Uno dei vantaggi della programmazione OOP è
Oggetti = Dati + Metodi.
ovvero la possibilità di manipolare i dati (e altri oggetti) attraverso dei
metodi e trattare entità applicative in maniera logicamente parallela al
mondo reale. Questo, se ben sfruttato permette di avere un modello logico
molto più semplice e funzionale.
J2EE prevede invece che ci siano
EntityBeans che mappano i dati
SessionBeans che espongono i servizi applicativi.
Un'altra buona pratica è quella che ad un entity bisognerebbe accedervi
attraverso dei sessionBeans.
Un'altra buona pratica è che bisognerebbe preferire di utilizzare stateless
session beans agli stateful, poiché sono molto leggeri da gestire.
Quindi alla fine potremmo avere un engine applicativo sul server J2EE che
espone soltanto una serie di metodi raggruppati su alcuni stateless
sessionbeans (e qualche stateful, o magari nessuno poiché qualcuno potrebbe
preferire utilizzare dei javabeans sullo strato di presentazione; il che
però frammenta il business tier anche sul presentation-tier e non mi sembra
troppo pulito).
Ora il problema è: ciò non assomiglia un po' troppo alla programmazione
procedurale?
Stessa cosa vale se si utilizzano webservices dove di fatto al server si
spediscono messaggi, ovvero chiamate remote di procedure.
E' possibile scrivere dei metodi di business su degli entitybeans, evitando
di utilizzare dei sessionbeans appositi ma questo mi sembra un po' fuori
dagli usi comuni di EJB, anche perché il client verrebbe ad interagire
quindi (potenzialmente) solo con EntityBeans.
La mia obiezione a tutto questo è: con la suddivisione tra metodi e dati,
non siamo un po' ritornati alla programmazione procedurale? Quando viene
modellata la logica di un'applicazione object oriented, i dati e i metodi
vanno a comporre la stessa classe; perché poi dobbiamo ragionare a
"servizi".
Un pensiero che mi è venuto è quello di rimettere insieme dati e metodi
utilizzando uno stateful sb con un reference ad un entity ed un'altro ad uno
ad uno stateless in questa maniera:
    stateful-sb = entity + stateless-sb
per far calzare la vecchia equazione:
    oggetto = dati + metodi
Ma gli stateful, quando possibile sono da evitare, per vari motivi di
pesantezza.
Inoltre la migrazione di logica di business dall'application server verso il
web server o verso l'applicazione stessa, utilizzando dei "leggeri"
javabeans, non mi convince moltissimo.
E' evidente che mi manca qualche "tassello", qualcuno mi può aiutare?
Best regards :-)
Jigi
P.S. Sto leggendo il libro di Romans "mastering ejb 2.0", sono al capitolo 6
non mi sembra così bello come si dice in giro. Non sono un mago
dell'inglese, ma mi sembra che a volte la forma sia un po' compromessa dalla
voglia di fare "i letterati", preferisco l'inglese semplice adatto ai
tecnici. Poi ci sono delle imprecisioni (errori) sparse quà e la, a volte
nel codice a volte nelle tabelle riassuntive. comunque il mio giudizio è
relativo ai primi 6 capitoli, può darsi che mi piacerà di più quando sono +
avanti. Cmq per ora non mi ha deluso.

 E' evidente che mi manca qualche "tassello", qualcuno mi può aiutare?
In breve, perche' ho sonno, magari domani ne riparliamo: COP vs OOP. 
Oggetti e Componenti sono due cose diverse (anche se spesso correlate), 
ed il modello EJB e' un modello a componenti molto "forte". Il tutto 
spesso cozza con la OOP, hai ragione. Questo IMHO e' l'unico tassello 
che ti manca: programmare con EJB non e' detto che sia un buon modo di 
programmare ad oggetti, anzi per la verita', e' piu' un'altra cosa che OOP.
ciao
uL

 javabeans, non mi convince moltissimo.
** l'uso dei javabeans al posto degli ejb va benissimo per le applicazioni
web-centric. Perchè devo per forza usare un container se accedo ai dati ad
esempio usando degli oltp già esistenti? ad esempio il tuxedo della bea. Se
il pool di "statefull/stateless" non serve (prestazioni) credo bastino i
javabeans.
Ciao
carlo

 spediscono messaggi, ovvero chiamate remote di procedure.
Il che, di per se', e' perfettamente OOP, no? C'e' (quasi) tutto: 
creazione, information hiding, distruzione, etc. 
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun


In effetti, per usare una metafora, il modello proposto ad EJB a volte rompe un po' il
cazzo, ma comunque si puo' gestire :-) (vedi l'altro post)
Riguardo alla supposta "COP" preferisco autocensurarmi e non pronunciarmi :-) 
Semplicemente potrei dire: un bel lancio da 3?
Ciao,
    Bruno.
---
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://digilander.iol.it/bbossola


Mah, a me non e' dispiaciuto, effettivamente ci sono degli errori (specialmente nel
codice). Il problema piu' grosso secondo me e' che non ci sono effettivi esempi che tu
possa prendere e far girare ad esempio sulla reference implementation, devi essere tu che
ti smazzi il problema. Il libro sarebbe molto meglio con un taglio maggiormente
"operativo".


D'altra parte è anche vero che su un entity è possibile avere dei metodi di
business. Comunque è vero anche che alla fine il client di un'applicazione
J2EE non dovrebbe interagire con degli entity. Questo trovo che sia un po'
condizionante.

 allo stesso livello degli entity bean
Sì, condivido; infondo la differenza è che uno stateful sb ha una durata
di una sessione, mentre un entity ha una persistenza vera e propria.
Un'altro dubbio che un paio di volte mi sono posto è quale debba
essere la cardinalità tra stateful, stateless ed entity, in un buon design.
Ho letto in giro una opinione per cui uno stateful dovrebbe
corrispondere ad un caso d'uso. Di entity mi sembra abbastanza ovvio
che dipende dal numero di "elementi" su cui i dati vengono organizzati,
mentre di stateless personalmente li uso per evitare di creare entity per
le tabelle di sola lettura o per quelle tabelle su cui i set di oggetti
prelevati
sono generalmente corposi (esempio, per popolare combobox etc.).
Mentre invece, la preferenza di utilizzare dei JavaBeans al posto
di stateful-sb, io faccio fatica a considerarlo un bene: si tratta comunque
di logica di business, che non dovrebbe invece trovarsi sul server j2ee ?
E poi, sebbene più leggeri, gli stateful sb non dovrebbero garantire
maggiore scalabilità, essendo gestiti via attivazione/passivazione ed
eventualmente pooling sul server j2ee?
Credo che sia ora di cominciare ad esaminare a fondo il petstore per
vedere un buon design J2EE :-)))
Tnkx.
Luigi.

 vedere un buon design J2EE :-)))
Il petstore e' solo un contenitore di patterns, non e' detto che sia un 
esempio di buon design J2EE!
uL

 richieste del cliente.
Sì, capisco: ejb offre una buona soluzione ad una serie di problemi tra cui
computazione distribuita, transazioni, concorrenza, sicurezza, pooling (non
solo di connessioni al db), persistenza, scalabilità, etc.
Fatta salva la persistenza (richiesta praticamente in ogni gestionale) e
talvolta la concorrenza, ogni feature aggiuntiva di quelle elencate, credo
che dovrebbe far pendere la lancetta verso ejb.
Poi penso che un progetto di grosse dimensioni possa beneficiare di un
approccio EJB.
Concordo perfettamente che non si parte dalla tecnologia, ma dai requisiti.
Bisogna constatare però che invece si seguono le mode... il che per chi deve
imparare non è poi una disgrazia. Sempre che poi ciò non si traduca in un
flop.

 esempio di buon design J2EE!
Non so dove altro guardare; di sicuro non dove ho lavorato finora.

 attivazione/passivazione ed eventualmente pooling sul server j2ee?
Questo dipende da quanto e' buono l'appserver. E in certi casi, quando 
possibile, _vuoi_ spostare computazione sul client - i vecchi principi del 
C/S non sono morti, solo evoluti. Imho e' un peccato che ci siano - da 
sempre - tutti 'sti casini a far girare applet. E', per molti versi, il 
modello che mi piace di piu' - dove sul server ci sta solo la computazione 
che _deve_ per forza di cose essere sul server, mentre quella che puo' 
girare sul client gira li' (dato che in caso contrario il client non fa 
altro che aspettare risultati, con spreco di risorse). Purtroppo, MS volle 
altrimenti.. ;-)
