Newsgroup: it.comp.java
Titolo: Architettura distribuita... quale?

Salve,
dovendo realizzare un'applicazione distribuita non web based con forti
requisiti prestazionali, avevo pensato alle tre opzioni:
application server con EJB e client standalone in JAVA;
application server con EJB e client standalone con Visual C# .NET
framework .NET
Vorrei fare tutto in JAVA, ma mi preoccupa la parte client. Di
applicativi  Java standalone ne sento parlare poco. Mi preoccupa il
comportamento su macchine windows. 
Ecco perchè la seconda opzione. Lato client userei tutte le risorse
della macchina con linguaggi più performanti (Visual C# .NET) e lato
server tutti i vantaggi del mondo JAVA. Ma in mezzo inevitabilmente
avrei corba e non RMI e quindi, sicuramente compatibilità non al 100% e
maggiore complessità.
Al che, perchè (provocazione) non usare direttamente il framework .NET
Insomma, nella guerra tra Java e dotNet chi sta vincendo?
Quali sono i motivi per usare JAVA, sia lato server che lato client?
E' accettabile usare una soluzione ibrida?
In ambiente web non avrei avuto dubbi, ma siccome il client fa molta
elaborazione (anche grafica)......
Vorrei fare tutto in java ma, per esempio, non ho mai visto un videogame
fatto in JAVA
Grazie per l'aiuto
Grazie per l'aiuto....

 elaborazione (anche grafica)......
Qualcosina si può fare con Java... vedi tu se può valerne la pena
http://www.youtube.com/watch?v=p9ytsfaGWts
pole
-- 
ammentos - a lightweight persistence framework for Java
http://ammentos.biobytes.it

Ci sono alcuni fattori in gioco, il più influente è sicuramente il
*controllo* che puoi avere sulle *macchine client*.
Se è un'applicazione pubblica devi assicurarti piena compatibilità con
il maggior numero di utenti, quindi Windows e .Net.
Se invece è un'applicazione intranet molto specialistica allora deve
semplicemente *funzionare bene* e allora utilizzi la tecnologia
secondo te migliore (che può essere anche .Net non c'è dubbio).
Per la comunicazione ci sono tante scelte possibili: alcune ti offrono
grande flessibilità ma poca compatibilità, altre sono rigide ma molto
supportate, più tutte le vie di mezzo.
--
www.megadix.it


Mah , io credo che se le macchine client non sono proprio dei catorci
senza memoria RAM non dovrebbero avere grosse difficolta' a gestire
dei client in Swing. Ho visto applicazioni client server che
funzionavano benissimo anche dal punto di vista delle prestazioni. In
piu' avresti il vantaggio della portabilita'. Quanto alla grafica con
Java2D non dovresi avere problemi. Una soluzione mista la escluderei,
mi sembra un modo per farsi del male e complicarsi la vita. Se te ne
strafreghi della portabilita' puoi anche pensare a una soluzione C#
WCF.  Molto dipende anche da che competenze hai..

 E' accettabile usare una soluzione ibrida?
mi verrebbe da dire: se funziona, si... :-)
scherzi a parte, volendo affrontare il problema di integrazione non
escluderei di pensarla in visione soa, quindi web services. non so
dirti a livello di prestazioni come si colloca, ma dal punto di vista
dell'integrazione vai alla grande.

 fatto in JAVA
In C# sì? Meno che in Java, direi.
Ciao,
Paolo

 Grazie per l'aiuto
ciao Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 fatto in JAVA
Non capisco che c'entrino i videogame con applicativi che usano EJB (quindi 
immagino
transazioni e compagnia cantante)....
E comunque dubito che per scrivere un engine di un moderno videogioco si usi 
.NET
o Java, credo che si utilizzi C++ e assembly...
Scorpio.