Newsgroup: it.comp.java
Titolo: EJB e RMI: breve spiagazione

Ciao a tutti!
Qualcuno potrebbe dirmi in poche parole (sempre se la cosa č fattibile!!
:-) ) se EJB č semplicemente RMI applicato ai Beans o c'č qualcosa di piů?
Ho cercato un po' di documentazione, ma alla fine non ho trovato molto piů
di quanto sopra......
Grazie!
Dario

: 

Oltre ad essere "RMI applicato ai Beans" :) (assumendo che tu per "bean"
non intenda quello della specifica JavaBeans) EJB1.1 offre servizi che
RMI non da': sincronizzazione, transazioni, persistenza e indipendenza
dai dattagli di persistenza, pooling, gestione del carico, eccetera e 
una classificazione gia' pronta ("entity" e "session") per componenti che
(logicamente) sono condivisi oppure proprieta' di un singolo client,
oltre alla definizione parziale di un processo di sviluppo di componenti
distribuiti e relativi ruoli che - teoria vuole - dovrebbe farti perdere
meno tempo a capire come diavolo organizzare lo sviluppo che a
sviluppare. :) 
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun

 wrote in message
news:Xns904FAC685E6...@194.19.1.61...


Ti concendo di usare 2 frasi, questa volta! :)
LOL vada per le due frasi. :)
Occhio che non c'e' qualcosa che tu "possa fare in EJB che ma non con RMI".
Nel senso, RMI di per se' e' un modo per invocare metodi su oggetti remoti, 
con un leggero layer di gestione dei nomi dei suddetti oggetti remoti, punto. 
EJB incorpora tutto cio', semplificandone la realizzazione, e offre, come 
dicevo, caratteristiche del tutto ortogonali (leggi: che non riguardano
l'invocazione di metodi remoti :).
Il problema e' la quantita' di lavoro che devi fare per ottenere il qualcosa, 
che EJB promette sia minore, e il grado di manutenibilita' e interoperabilita',
che con EJB dovrebbe essere maggiore che con soluzioni ad hoc. Dico "promette" 
e uso il condizionale, perche' mentre alcune parti sono semplificate, EJB aggiunge 
overhead altrove; e avendo lavorato con EJB solo su un paio di applicazioni per 
nemmeno un anno, non ho ancora abbastanza esperienza per avere un'opinione sul
fatto che che a medio/lungo termine il risparmio ci sia. Soprattutto visto 
il fatto ben noto che il costo maggiore per un software e' in genere sulla 
manutenzione. Ma sto divagando.
Esempio di semplificazione per RMI: la generazione e gestione degli stubs e'
automatica. Non "vedi" rmic, che e' usato direttamente dal server.
Esempio di caratteristica ortogonale a RMI: la persistenza. Se usi CMP 
(container-managed persistence) tutto cio' che devi fare e' indicare al server 
quali membri della tua classe sono persistenti, e l'effettiva implementazione 
della persistenza (compresa la generazione di tabelle SQL su un database
bersaglio, se usi db relazionali per persistenza come spesso accade) e'
a suo carico.
Ce ne sono molti altri, che per essere anche solo citati richiedono piu' di due
righe.. e ne ho gia' 7. :)


 Esempio di caratteristica ortogonale a RMI: [...]
Ah, ok.
Mi pare di aver inquadrato il problema. Credo che mi convenga cercare la
documentazione necesasria a farmi una panoramica di queste caratteristiche,
in modo da sapere quando convenga mettersi a studiare EJB.
Grazie mille!
Dario

Grazie mille!
Figurati. :) Giusto per concludere, tieni presente che ci sono altre
motivazioni nontecniche, ad esempio il fatto che per una serie di motivi
EJB sta avendo un gran successo di mercato anche in ambiti 
tradizionalmente "conservatori", che dopo averci messo 40 anni a passare
da COBOL a C++, buttano via C++ e passano a Java/EJB in cinque.
Non sono sicuro che la cosa mi piaccia :), ma tant'e'.


 Non sono sicuro che la cosa mi piaccia :), ma tant'e'.
Per fortuna io sono in un ambiente che definirei "dinamico", per cui la cosa
mi fa solo piacere! :) Però 'sto fatto di dovermi mettere con le EJB...
Spero che se mi serviranno veramente, avrò il tempo di studiarmeli, ma la
speranza è vana....
Ciao,
D

studiarmeli, ma la speranza è vana....
Considera che dopotutto sono divertenti. :)


 Considera che dopotutto sono divertenti. :)
Be', la speranza vana č, ovviamente, quella di avere il tempo!!! ;)))
D