Newsgroup: it.comp.java
Titolo: Iniziare con J2EE

Ciao a tutti,
vorrei approfondire un pò la mia conoscenza del java...specialmente di
J2EE, che mi manca completamente (ahiahiahi).
Per ora ho sempre usato J2SE e realizzato qualche applicazione SWING/
AWT in Eclipse (sfruttandolo al 10% delle sue potenzialità,
sinceramente potevo usare il Notepad++).
Vorrei sapere come "muovermi", nel senso...mi conviene installare solo
il J2EE sulla macchina che utilizzerò per programmare (ovvero potrei
cmq realizzare applicazioni per le quali basterebbe il solo J2SE)? Per
ora sto utilizzando il tutorial di JavaPortal e ho scaricato il pdf
Sun...però se qualcuno ha qualche buon consiglio sul metodo da
utilizzare ben venga!
Ciao!
                 Chiara

ti posso suggerire:
- il tutorial della sun che mi sembra hai già trovato:
http://java.sun.com/javaee/5/docs/tutorial/doc/
- iniziare con servlet, jsp, custom tags, e compagnia (lato web insomma)
- web services
- per quanto riguarda gli ejb con jee5 ci sono la versione 3.0, se ti va 
puoi anche guardarti la precedente la 2.1 ma mi sembra che comunque non sono 
molto utilizzati, non si sono molto affermati a causa della loro 
complessità. La versione 3.0 è molto più semplice.
Esistono comunque alternative, nel senso che non sei obbligata a usare ejb 
per fare un'applicazione enterprise ;)
- dai un'occhiata ai pattern:
"core j2ee patterns" e "gof design patterns"
- prendi un application server e sperimenta: tomcat è soltanto servlet 
container, mentre di completi ci sono ad esempio glassfish che è nuovo..... 
ce ne sono diversi qui...
- comincia a vedere qualche framework tipo: struts2 / webwork per il web, 
spring, e poi ne scoprirai
- per ora basta :)
buon divertimento

 complessità. La versione 3.0 è molto più semplice.
Solo una considerazione : gli EJB 2.x non saranno IMHO totalmente 
soppiantati da EJB 3.0. Peraltro,
che non siano utilizzatissimi è vero, però non è neppure vero che siano così 
poco diffusi.
Scorpio.

 cosě poco diffusi.
il fatto č che col tempo specie coi web service il grande pregio di essere 
remotizzabili č venuto meno, nel senso che riesci a remotizzare con un web 
service semplicissimo, addirittura binario (guarda caucho hessian, cioč 
senza soap).
e magari anche con l'aiuto di framework di supporto come spring
per gli entity bean piiuttosto c'č diffusione di framework come hibernate o 
a un livello prima ibatis e suppongo altri,
i session bean magari sono sopratutto comodi se hai bisogno di 
un'applicazione stateful, mentre gli stateless in effetti perchč dovresti 
usarli se puoi remotizzare agevolmente con un web service senza tante 
complicazioni? :)
io i 3.0 non ne ho mai scritto uno ma da quel che ho letto sono molto molto 
piu semplici pensi che si affermeranno piů dei precedenti ?
alla fine i piů utili sono i message driven bean, che poi manco sono 
propriamente degli ejb, ma necessari per le operazioni di scodamento dalle 
code jms ;-)

 molto piu semplici pensi che si affermeranno più dei precedenti ?
Secondo me sì. Uso quotidianamente gli EJB 2.1 ma senza un ambiente di 
sviluppo integrato che
mi consente di gestirne facilmente il deploy e lo sviluppo la loro gestione 
sarebbe ardua, per non dire
impossibile. Gli EJB 3.0 sono essenzialemente - e mi perdonino i puristi - 
classi annotate in modo
particolare, il cui ciclo di vita è delegato all'application server.
E, tanto per riconciliarci, supportano "nativamente" l'uso dei WebService 
(possono essere cioè annotati
in modo che i metodi remoti siano visibili come servizi web).
Saluti,
    Scorpio.

 overhead di una chiamata XML/SOAP.
concordo con te.
per me un ws è semplice da fare e gestire, mentre per l'overhead da test 
casarecci che ho fatto io stesso, sicuramente rmi è molte volte più veloce 
di un ws ;)


Credo che questa affermazione abbia validita' solo quando i session bean non 
fanno parte anche del front-end.
Recenti framework come Seam di JBoss itendono utilizzare i session bean 
(stateful o meno) come bean anche per il front-end. Se conosci JSF possiamo 
dire che gli stateful bean in Seam svolgono anche i compiti dei managed-bean 
di JSF. 

 Chiara
 
Ciao Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/


Essenzialmente perchè un EJB Stateful implicherebbe una relazione 1:1 con il 
client remoto
del quale, se mi passi l'immagine un po' grottesca, è una "propaggine" sul 
server. Ora, tutto dipende
da quanti sono i clien e da che macchine uno ha a disposizione: per 
esperienza indiretta, gli EJB stateful
si sono rivelati abbastanza "pesanti" in termine di carico.
Scorpio. 

 managed-bean di JSF.
JSF lo conosco di sfuggita, posso intuire la logica sottostante ma ho 
qualche perplessità sull'uso degli EJB
Statefull. 

 Statefull.
2 frammenti della documentazione di seam
The two core concepts in Seam are the notion of a context and the notion of
a component. Components are stateful objects, usually EJBs, and an instance
of a component is associated with a context, and given a name in that
context. Bijection provides a mechanism for aliasing internal component
names (instance variables) to contextual names, allowing component trees to
be dynamically assembled, and reassembled by Seam.
.........................
Stateful session bean components are able to hold state not only across
multiple invocations of the bean, but also across multiple requests.
Application state that does not belong in the database should usually be
held by stateful session beans. This is a major difference between Seam and
many other web application frameworks. Instead of sticking information about
the current conversation directly in the HttpSession, you should keep it in
instance variables of a stateful session bean that is bound to the
conversation context. This allows Seam to manage the lifecycle of this state
for you, and ensure that there are no collisions between state relating to
different concurrent conversations.
Stateful session beans are often used as JSF action listener, and as backing
beans that provide properties to JSF components for display or form
submission.
ciao Nicola
