Newsgroup: it.comp.java
Titolo: J2EE conviene davvero?

stiamo valutando l'opportunità di realizzare un progetto di medie dimensioni
riguardante la pubblicazione di notizie su web.
a tale scopo stiamo ricercando la tecnologia adatta, e ci stiamo chiedendo
se effettivamente la piattaforma J2EE possa essere di aiuto per svolgere il
lavoro in modo più efficacemente e rapidamente. l'alternativa sarebbe
utilizzare 'solo' JNDI.
qualcuno che ha già sviluppato potrebbe esserci di aiuto? tenete conto che
sappiamo già cos'è J2EE, svilupperemo in 4-5 persone e alcune sono
inesperte, e che uno dei requisiti che l'applicazione dovrà avere sarà
quello di potere scalare su più macchine. insomma, chiediamo un consiglio
'pratico'.
ciao
Nicola

 ha scritto nel
messaggio news:976700736.250501@linuxintra...


ti ringrazio.
vorrei precisare che in un seminario su J2EE che ho seguito si è notato come
il concetto di indipendenza dal server, di indipendenza dal database e di
sicurezza delle transazioni non sono ancora bene implementati.
inoltre sono dell'idea che solo in casi moolto specifici sia necessaria una
reale indipendenza dal database. o sbaglio?
un'altra cosa: l'overhead che si produce realizzando codice e configurazione
per entity/session bean vale davvero il miglioramento in
scalabilità/performance/disponibiltà di cui si parla tanto?
penso che questo argomento sia abbastanza complesso e quindi di aiuto per
molte persone che ne avranno a che fare in futuro. non trascuriamo il
dibattito!
Nicola

 dibattito!
Daccordissimo !
Ciao,
Lvc@

Ciao!
    certamente J2EE è una tecnologia *troppo* nuova per avere delle solide
basi sopratutto su architetture già esistenti. Ogni compagnia societaria che
sviluppa server J2EE ha alle spalle anni di altre implementazioni che,
seppur in parte, devono convivere con le future. Quindi la scelta di non
*buttarsi* completamente sull'architettura J2EE penso sia solo una fase di
migrazione.
Nell'immediato questo non può portare ad uno standard "de facto" ne tanto
meno ad uno standard *imposto* da J2EE (chi lo vorrebbe altrimenti?). Quindi
qui sta la scelta del server da utilizzare, scelta non semplice, ma che può
decretare il successo o meno dell'intero progetto. Sono drastico? Non penso;
sono dell'idea che in questa fase ci siano tante (o poche :P ) idee sul
mercato J2EE e che un server può da solo fare la differenza della ns
applicazione.
    Posso sbagliarmi perchè non ne ho provati molti ,( sig.
    Visto che la scelta era fra JNDI e J2EE ... Non ritengo JNDI superato,
ma parte integrante di J2EE, siccome l'ho trovato in numerosi documenti di
J2EE potrei sbagliarmi, ma mi sembra che J2EE sia come java2 per java.
Insomma un passo in più che può fare la differenza.
    La soluzione penso possa essere solo quella di vedere qual'è il progetto
... certo che questo compete a te, e non di certo a me, che per scelta e/o
imposizione, punto su J2EE.
    Per i Db sono in parte daccordo con te, visto che JDBC è il grosso punto
di forza dell'architettura dei DB di java ...... basterebbe solo quello :D
    L'ultima cosa per l'overhead: qui è come per la programmazione ad
oggetti. C'è ancora molta gente che sostiene che anche i programmi ad
oggetti non servono e anzi sono più "controllati" quelli procedurali. Posso
essere daccordo ma la mia risposta è: Come programmi ad oggetti?
    __café

 tutto è perfettamente integrato (anche se migliorabile :-)
vedi sopra...


 ha scritto nel
messaggio news:976713228.742410@linuxintra...


 essere daccordo ma la mia risposta è: Come programmi ad oggetti?
io sono fermamente convinto che la tecnologia ad oggetti possa offrire molto
di più rispetto ad un linguaggio di tipo procedurale, almeno per quello che
riguarda applicazioni di tipo proprietarie/web, dove la chiave del successo
non solo sta nelle funzionalità, ma nella manutenibilità. E utilizziamo al
nostro meglio tutte le possibilità offete da Java. Penso anche però che la
flessibilità delle strutture realizzate sia potenzialmente un'arma a doppio
taglio: aggiungere layers su layers sotto al proprio software porta
teoricamente a doversi preoccupare solamente della cosiddetta 'business
logic', ma in pratica costringe il programmatore ad imparare tecnologie su
tecnologie, interfacce su interfacce, perchè chiunque abbia un pò di
esperienza sa che quando qualcosa va male 9 volte su 10 è colpa sua, ma alla
10° deve andare a ricercare il bug nei manuali. E la tecnologia J2EE non è
proprio la cosa più semplice di questo mondo come tutti volgiono farla
sembrare: praticamente sotto c'è tutto il codice scritto finora per il
networking in java...
Noi qui i nostri patterns li abbiamo: la piattaforma J2EE ci serve solamente
per 'uscire' dallo spazio di memoria della singola Virtual Machine per
potere scalare su più macchine. ne varrà la pena....???
Nicola

 ha scritto nel messaggio
news:9181er$bnp$1...@news.IT.net...


Scusa se tolgo il resto ma diventerebbe un post lunghissimo :)
    La soc alla quale lavoro non è una grossa società.
J2EE non è una cosa semplice come non lo è NESSUNA altra tecnologia di quel
livello.
    Alla base di tutto non ci deve essere una buona programmazione (quella
dopo!) bensì una buona architettura. Hai ragione, se si progetta male la
struttura del software forse sarebbe stato meglio lasciar perdere gli
oggetti piuttosto che perdere gg_uomo a rimetterli a posto.
    Io continuo a pensare che se avete una risorsa da dediacare a questo
.... ne varrà la pena. Posso sbagliarmi, ma a me sembra un'architettura che
confrontata con le altre sul mercato ... bè ne ha da vendere di roba in più
ed in meglio.
    Questo è il mio semplice ed umile punto di vista. J2EE non è ancora
affermata ed è nuova, le potenzialità le ha, la flessibilità è l'arma più
affilata di Java e rendere questo disponibile e svincolata da vincoli
spazio/macchinistici (permettemi questa brutta battuta) è un grosso passo
avanti.
Nicola, se la tua società è già pronta su altro e se i vs partner non hanno
pretese .... bè fate fruttare quel che sapete.
    Ripeto: che non sia facile non c'è dubbio ... la pubblicità dell Microz.
può far sembrare facile IIS e ASP, ma poi comunque ti scontri con la loro
logica, con la programmazione che fanno loro, con i loro vincoli. Io sono
dell'idea che qui sia lo stesso, un po' meno vincolato alla mentalità
"generalizzata" Microz. ma con gli stessi problemi, solo che più reali e
meno _mascherati_ (se mi è permessa questa espressione).
    Per i servers J2ee "differenti" ... bè ora è un difetto non un pregio,
potresti non essere in grado di portare completamente tutto il codice, ci
vorrebbe un adattamento e quindi dispendio ancora di energie. Però su non
l'ho mai provato un porting su un server diverso di un progetto J2EE, ho
letto le documentazioni di differenti server.
    Tutto qui
    __c@fé

 ha scritto nel
messaggio news:976724525.864475@linuxintra...



JNDI è parte di J2EE, non capisco come possa da solo bastare alla
bisogna. J2EE può soffrire di giovinezza, ma non sei tenuto ad usare
cmp, oppure puoi integrarla con prodotti professionali di terze parti
tipo cocobase. Una cosa da valutare è il costo, che fra App server e
motore persistenza (se vuoi usare cmp non ti consiglio quelli integrati)
è fra i 50 e 100 milioni tranquillamente.
Se si parla di pubblicazione di notizie su web, puoi anche dare
un'occhiata a Cocoon, un publishing framework basato su XML che potrebbe
essere il best-fit nel tuo caso. (puoi sempre delegare a server corba o
EJB l'high availability e il fault tolerance successivamente)
-- 
Ugo
__________________________________________________________________________
"La perfezione si ottiene non quando non c'è nient'altro da aggiungere, 
 bensì quando non c'è più niente da togliere." Antoine de Saint-Exupéry
__________________________________________________________________________
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Enterprise Java Consulting
@mail:	
ugo.l...@flashnet.it
@work:	
ugo.l...@sun.com
Home Page: 
http://www.ugolandini.net
Home Page: 
http://ugolandini.hypermart.net
 (DNS is changing)
Fax Phone: 06/233207542 
Cell Phone: 0347/6310749 - 0347/4783580
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 
concordo. Jb4 e Inprise App server sono decisamente ottimi.


 ha scritto nel messaggio
news:918aop$hd4$1...@news.IT.net...


 cambiare implementazione (almeno si isola il problema).
Potresti approfondire (magari con un link a qualche esempio)?

 ha scritto nel
messaggio news:976784579.370990@linuxintra...


http://java.apache.org/turbine/peers.html
ogni commento è gradito


 Potresti approfondire (magari con un link a qualche esempio)?

nicola.muratori.TOGLInospam.@cnare.it
 (Nicola Muratori) wrote in
<976700736.250501@linuxintra>: 

Dipende dalla complessita' del sistema.
Nella mia esperienza finora, il prezzo che si paga per EJB (a parte conoscerlo, 
s'intende :) e' un certo maggiore overhead nello sviluppo e testing, e 
l'overhead runtime tipico di tutti i sistemi distribuiti. I vantaggi, 
ovviamente, sono quelli noti, e si sentono principalmente in sistemi non 
banali.
Tieni anche presente che i vari application server in giro non implementano 
tutti lo stesso livello di specifica di EJB e in alcuni (leggi, Websphere ;-) 
il re-deployment e' abbstanza macchinoso, anche se IBM nella sua roadmap 
prevede un analogo del "deployment tool" di J2EE reference impl. per Gennaio.
Ora "pubblicazione di notizie su web" - a seconda di cosa si intende, puo' 
essere una cosa estremamente semplice o, come dici, di media complessita'. Se 
non conosci i volumi da trattare, o semplicemente vuoi scalabilita', insieme ad  
un ambiente transazionale piuttosto efficace, allora val la pena. Se i volumi 
sono scarsi, e le transazioni veloci e affidabili, probabilmente no.
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun

 prevede un analogo del "deployment tool" di J2EE reference impl. per
Gennaio.
IBM dovrebbe basare San Francisco su EJB, no...?

PERDERE a mio avviso e secondo la mia esperienza.
Perche' mai? Noi qui usiamo entity beans con CMP interscambiabilmente :) su
DB2, MS SQL Server e Oracle, e non ci sono grossi problemi.
Il problema e' il deployment (di qualunque tipo di bean) che se non ti fai due 
tool da te resta macchinoso. 


 IBM dovrebbe basare San Francisco su EJB, no...?
si, so che stanno migrando i business objects che hanno creato per
renderli compatibili con J2EE
-- 
Ugo
__________________________________________________________________________
"La perfezione si ottiene non quando non c'č nient'altro da aggiungere, 
 bensě quando non c'č piů niente da togliere." Antoine de Saint-Exupéry


 wrote in message
news:976700736.250501@linuxintra...


 cambiare implementazione (almeno si isola il problema).
Quello che gli Entity Beans vogliono "SIMULARE" è un ODBMS, ossia un DBMS ad
oggetti. Purtroppo le attuali implementazioni lasciano MOLTO a desiderare.
Se si vuole lavorare ad oggetti anche sul database la scelta migliore è
senza dubbio utilizzare un ODBMS PURO come Versant (
www.versant.com
) o
Orient (
www.orientechnologies.com
).
Il nuovo standard SUN JDO (ora alla versione public 0.8) permetterà di
lavorare in modo trasparente con gli oggetti (vedi
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_012_dataobj.html
).
Altrimenti si può utilizzare qualche tool BEN FATTO come CocoBase...
Saluti,
Lvc@

ciao
anche io ero interessato, dato che adesso il nostro team non è assolutamente
pronto ad utilizzare tecnologie così dispendiose (sia in termini di ore uomo
che di 'sghei'), a cercare di costruire un piccolo set di interfacce che
facessero da ponte all'infrastruttura sotto, J2EE o quella che sia. stavo
pensando di utilizzare appunto il pattern 'bridge' abbinato al 'facade', in
modo da permettere in futuro di utilizzare sia queste mie interfacce sia le
specifiche EJB direttamente.
in pratica le mie servlet accederanno al micro-framework che reindirizzerà
le richieste ai metodi opportuni.
ho sentito, in proposito di architetture distribuite, l'esistenza di
progetti di Virtual Machines distribuite (DVM) che eseguono codice java
parallelamente su più macchine (penso un thread per CPU o qualcosa di
simile). Se cose del genere esistessero davvero, si butterebbe all'aria
tutto J2EE e robe simili almeno per il discorso prestazioni, tornando a
programmare 'alla vecchia'. tanto il load balancing lo si fa a livello di
VM!
qualcuno ne sa qualcosa di più?
Nicola


utilizzare sia queste mie interfacce sia le specifiche EJB direttamente.
Dal punto di vista del design cambiano due cose quando si pensa ad 
impacchettare un'interfaccia sia in un ambiente EJB che in uno no:
1) I metodi devono dichiarare throws RemoteException (e quindi il codice client
   deve gestire l'eccezione).
2) Si usano factory per ottenere reference alle istanze, e non new.
Ci sono poi vari tradeoff da considerare, ma un design efficace che salva capra 
e cavoli, e' come segue (nell'esempio, per implementare una classe "Services").
interface Services -> i servizi da offrire. Ogni metodo dichiara almeno throws 
RemoteException (ovviamente sono consentite eccezioni applicative). 
L'interfaccia *non* implementa EJBObject.
public interface Services { 
 public void service(...) throws RemoteException; 
}
class ServicesFactory -> una factory per istanze di "Services":
public class ServicesFactory  {
    	public void create(..parametri di costruzione..) throws CreateException, 
RemoteException {
    	...crea l'EJB o la classe "normale"...
    	}
} 
Ora, se si vogliono classi "normali", si costruisce un'implementazione di 
Services nel modo solito, e il codice della factory in modo che faccia 
semplicemente una new di tale implementazioni. Se non usate RMI, 
l'implementazione puo' tranquillamente tralasciare di dichiarare la 
RemoteException - come da JLS:
public class ServicesNormalImpl {
    	public void service(...) {
    	    	...implementazione...
    	}
}
Quando si passa ad EJB, si costruisce un EJB la cui remote interface estende 
Services e EJBObject in modo nullo:
interface ServicesEJB extends Service, EJBObject {
}
e si sostituisce il codice della factory con codice che faccia il lookup e 
create dell'oggetto via home interface. La javax.ejb.CreateException 
eventualmente sollevata dalla create() dell'home interface va incapsulata nella 
CreateException di cui sopra.
Per quanto riguarda le implementazioni, *in dipendenza da cosa fanno*, possono 
essere riscritte o incapsulate nell'implementazione EJB. Il primo caso vale 
quando si vuol fare uso di features di EJB ovviamente non fornite da java 
"puro" (tipo container-managed persistence o transazioni); nel secondo caso, 
l'implementazione EJB costruira' - nel relativo metodo ejbCreate() - un'istanza 
dell'implementazione originaria, che verra' usata per implementare i servizi:
public class ServiceEJBImpl implements SessionBean {
    	private ServicesNormalImpl impl;
    	public void ejbCreate(...parametri di costruzione...) throws Create


set di interfacce che facessero da ponte all'infrastruttura sotto, 
Dal punto di vista del design cambiano due cose quando si pensa ad 














    	private ServicesNormalImpl impl;

         throws CreateException {
    	    	impl = new ServicesNormalImpl(...parametri di costruzione...);
    	}
    	public void service() {
    	    	impl.service();
    	}
}
Massimo riuso, minimo sforzo. ;-)
