Newsgroup: it.comp.java
Titolo: [Richiesta parere] Applicazioni distribuite.

Salute a tutti,
spero di non "rompere" con l'ennesima domanda un po' particolare. C'è 
l'intenzione di sviluppare un'applicazione *pesante* in Java e l'idea di 
base è la seguente:
- rich client in Java, distribuito e deployato via Java Web Start;
- logica applicativa su Application Server centralizzato.
Il dubbio è su come  realizzare il colloquio fra le due parti. Stiamo 
sperimentando il passaggio, via HttpConnection, di un'estensione di una 
HashMap contenente, di volta in volta, tutti i bean e le informazioni 
necessarie alla business logic remota. L'hashmap è serializzata e compressa, 
in modo da minimizzare la banda.
Che ne pensate di quest'idea ? Follia ? Sciocchezza ?
E se non vi garba, che alternative proporreste ?
Scorpio. 

 E se non vi garba, che alternative proporreste ?
E' praticamente la soluzione adottata nel progetto per l'esercito al 
quale ho lavorato.
E come applicazione e' *veramente* pesante ;) !

Logica applicativa remota esposta tramite un facade service e remotizzazione 
mediante web service.
Altre tecniche di remotizzazione (piů complesse):
RMI
EJB

 EJB
I WS sono una allettante prospettiva, ma non sono un po' troppo "a grana 
grossa" ? Inoltre per il momento non si parla di interoperabilità con altri 
linguaggi...
Quanto ad EJB /RMI, usiamo gli EJB solo server side per realizzare la logica 
applicativa transazionale.... avendo a disposizione gli EJB, l'RMI "gestito 
a mano" ha ancora senso ?
Grazie per la risposta !!!
Scorpio. 

 ha scritto nel messaggio 
news:dd2c1$46f2b62a$4d385480$26...@news.hispeed.ch...

Mi conforta saperlo, davvero :-)))
E com'è andato, se è lecito chiedere ?
Scorpio. 

 Scorpio. 
pole
-- 
ammentos - a lightweight persistence framework for Java
http://ammentos.biobytes.it

 E com'è andato, se è lecito chiedere ?
Il progetto continua a andare avanti, e' in continua evoluzione :)
Comunque se sono piu' di tre anni che il sistema e' produttivo, la 
soluzione adottata non e' mai stata messa in discussione :)

 centralizzata (es. controllo accessi) ovviamente no.
L' applicazione è effettivamente un gestionale,  prima pensato con 
interfaccia web ma successivamente,
vista anche la "manovrabilità" richiesta all'interfaccia (drag 'n drop, 
personalizzazione delle videate con campi
nascosti o presenti e disposti in posizioni scelte dall'utente) si è 
abbandonata questa via.
Un two tier risolverebbe un sacco di problemi, ma l'idea è quella di 
lasciare la logica di accesso ai dati e di business
su un server per evidenti ragioni di sicurezza e di riutilizzabilità della 
stessa --> esporre via web solo quei servizi
gestionali che su web hanno un senso.
Il nodo è stato quello di far comunicare il client con il server... le 
scelte in effetti non erano molte: EJB o WebServices. I secondi ci sono 
sembrati molto più indicati x servizi " a grana grossa" , non in situazioni 
in cui l'interazione tra client e server è forte; l'uso "diretto" di EJB 
poteva essere una soluzione... ma non sapevamo come
potesse comportarsi a livello proprio di rete, dal momento che l'applicativo 
sarà accessibile da client esterni all'intranet aziendale (e che quindi 
usano hdsl). Con l'http connection, ci è parso di poter sfruttare la 
"robustezza" di http in presenza di microcadute di rete (letali ad esempio 
per applicazioni 5250). Il lavoro "duro" sarà comunque svolto da EJB.
Il dubbio era sul peso della comunicazione...in termini di pacchetti 
ricevuti.
Saluti,
    Scorpio.


 Scorpio.
La tua soluzione soffre che alla lunga diventera' poco gestibile, leggibile,
manutenibile. La servlet di smistamento si carichera' di far un lavoro di
fatto di application server e dovrete manutenerla e gestirci la sicurezza,
le ACL eccetera, lavoro che dovrebbe essere oggi fatto da SW gia' scritti da
altri cosi' che voi vi possiate concentrare sul vostro business e non
perdere tempo e risorse a scrivere midlleware.
La Hash crescera', dovrete cominciare a codificare le chiamate http con un
cvostro codice interno eccetera e ancora agggraverete la situazione.
diventera' la classica applicazione pesante, vecchia , illeggibile..
opterei per ejb o WS
ciauz Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 ha scritto nel messaggio 
news:85Z18Z201Z166Y...@usenet.libero.it...

Tristi prospettive... che dire ? Spero che ti sbagli...  questi rischi li 
capisco, ma non pensi che siano in un certo
senso "strutturali" ? A fronte di un webservice avrei comunque da gestire la 
politica di ACL, la pubblicazione
del servizio, la specifica del servizio (quali parametri passare e quali 
attendere in risposta).
Scorpio. 

 Scorpio.
 ciao



ahhhh
per le exception mi stanno gia' venendo delle idee, ma vabbe .........
comuqnue se usi una Map anche di ritorno puoi puttarci un "#error#",true
e anche qualche info sull'errore a quel punto ma vabbe e' infinito :-)
buon lavoro comunque


 return result;


 Ciao, spero sia gradito.
[CUT]
Lo č, come tutti i commenti, le critiche, gli spunti sensati :-)
Ho tagliato il resto; non mi sembra affatto che tu sia ammattito, 
tutt'altro. Anzi, credo tu abbia delineato
in pratica il funzionamento dell'architettura: a  differenza della tua 
proposta "volante", perň,  noi abbiamo
sviluppato delle servlet che dall'hashmap estraggono i parametri necessari 
da utilizzare poi nella logica
di back-end; le classi di business sono isolate e non dipendenti dal modo 
con cui ricevono i parametri.
In teoria - ovviamente; tra il dire ed il fare.... - un domani potremmo 
sostiture, volendo, le servlet che
fanno il routing delle chiamate con servlet che manipolano documenti XML (e 
quindi, grosso modo, webservices).
Grazie per l'interessamento !
Scorpio.