Newsgroup: it.comp.java
Titolo: Aggiornamento tool da server

Qualcuno ha mai creato un'applicazione che se installata sui vari client gli
aggiornamenti successivi possano essere fatti da un server.
Mi spiego meglio.
Vorrei che al momento dell'accesso all'applicativo, il tool riconosca che ci
sia un aggiornamento e chieda all'utente di aggiornare il progetto. Questo
per ovviare al problema di andare pc per pc a sovrascrivere il prodotto.
Vorrei fare questa cosa per un tool che sto sviluppando in delphi ma mi
interesserebbe fare la stessa cosa anche per altri linguaggi.
Qualcuno ha già realizzato qualcosa di simile?
Accetto consigli!
Grazia mille per la collaborazione.

 sia un aggiornamento e chieda all'utente di aggiornare il progetto.
? A che scopo tutto cio' ? Usa un client "stupido" ed aggiorna solo il
server. Costa meno ed e' piu' rapido.
Davide

 ha scritto nel messaggio
news:amp0kk$7tj7p$1...@ID-18487.news.dfncis.de...

Come progetteresti il tutto?

 Come progetteresti il tutto?
La parte cliente deve contenere il meno possibile e (possibilmente) essere
modulare, usando Java puoi utilizzare l'RMI per 'acquisire' le classi che
ti servono dal server ed usarle alla bisogna.
La parte server e' quella che conta.
Aggiorni il server - hai aggiornato i client senza problemi. 
Se utilizzi RMI puoi sviluppare la parte 'server' come un'insieme di servizi
che dialogano tra di loro, il che ti consentirebbe eventualmente di aggiornare
una parte senza toccare il tutto. Ovviamente devi progettare bene le
interfaccie tra le varie parti.
Davide


Non è difficile scrivere un tool che valga per qualsiasi tipo di programma.
Basta che all'avvio l'applicativo invii al server autoaggiornante la
versione e il codice identificativo del tuo programma.
Poi il server controlla la versione e se c'è un aggiornamento invia la lista
dei file da aggiornare all'applicativo che se li scarica da qualche parte.
Questa è una versione semplificata. Si potrebbero fare un sacco di cose più
fighe...
Ciao
/Ettore

 dei file da aggiornare all'applicativo che se li scarica da qualche parte.
...ma se non stai facendo funzionare la cosa come superuser non puoi
aggiornare i file, non puoi in ogni caso aggiornare i file che sono 
aperti...
Davide

 Davide
E se mi interesa un client stupido, ma non troppo? Anche io avrò la stessa
esigenza e vorrei che il client non fosse un "browser".
Premetto che non ne so molto, ma JavaWebStart non dovrebbe muoversi in
questo senso?
Al momento la soluzione che mi viene in mente (con gli strumenti che
conosco) è di utilizzare lato client una classe di startup che setta il
classpath dinamicamente.
ciao
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


per java si, si chiama sun ;-)
se cerchi questa cosa per java dai un occhiata a Java Web Start è la
soluzione precisa che stai cercando
ciao

 ha scritto nel messaggio
news:amp3e9$7omss$1...@ID-18487.news.dfncis.de...



si fatto
da anni la società per cui lavoro utilizza un meccanismo di 
autoaggiurnamento delle applicazioni sviluppato da me nel lontano 1998
(nel tempo la cosa si è fatta un po' più sofisticata ma il meccanismo di 
base è sempre lo stesso)
all'avvio un loader controlla se la versione è cambiata e/o controlla 
l'integrità dell'applicazione (per cui puoi anche cancellare alcune 
librerie che quelle per magilla riappaiono) e poi avvia l'applicazione 
vera e propria
1. hai bisogno di un archivio dei pacchetti che possa fornire le 
informazioni sul'ultima versione (un serverino http con autenticazione 
con un file che contenga l'elenco dei jar e i jar stessi)
2. all'avvio leggi il file "di versione" da remoto, lo confronti con 
quello locale (se c'è), scarichi quello che devi scaricare e sovrascrivi 
se necessario il file in locale
3. devi utilizzare un classloader custom per poter leggere dai 
zip/jar/directory/file vari che ti scarichi da remoto
4. nel file di configurazione del loader oltre a inserire le coordinate 
dell'archivio metti anche il nome della classe da lanciare dopo il 
versioning e via...
In alternativa puoi utilizzare la tecnologia Java Web Start oppure 
PowerUpdate della Zero G (ma non è divertente come scriversi il tool da 
soli :-) )
Buon divertimento
-- 
Fabio Ambrosanio
/quousque tandem/

Una domanda da ignorante in materia :
Ma questo sistema non appesantisce in maniera esponeziale il carico della
rete rallentando paurosamente le già lente applicazioni java? In più sarebbe
un carico aggiuntivo per il server, carico che rischierebbe di appesantire
ancora di più il tutto nel caso ci fossero molti client!
Come ti ho detto su RMI sono totalmente digiuno.

 della rete rallentando paurosamente le già lente applicazioni java? 
Server side, appunto java non ha problemi di velocita'. Inoltre 
l'applicazione (se propriamente fatta) e' scalabile - cosa che non si puo' 
dire (e fare facilmente) di un client.
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 dire (e fare facilmente) di un client.
Puoi spiegarmi meglio?
Cmq. mi sono incuriosito, credo che uno studio approfondito, mi toglierà i
dubbi.
Grazie mille!!!!!

 Puoi spiegarmi meglio?
E' semplice. "scalabile" significa che c'e' un rapporto non troppo peggio 
che lineare tra l'aumento di risorse fisiche e un aumento delle performance 
e/o del carico sostenibile. Applicazioni *non* scalabili, per chiarire, 
sono quelle in cui aggiungere CPU o disco lascia immutate (o peggiora!) le 
performance. 
Un server - essendo tale - e' un punto d'accesso e di offerta di servizi: 
il suo dimensionamento puo' essere periodicamente rivisto, in caso di 
aumento del carico medio, senza creare incubi logistici. Provati invece a 
dire "ahem, *tutti* i client devono fare l'upgrade da 512Mb a 1024Mb di 
memoria per supportare le nuove funzionalita'..." :-)
Questo e' quanto ha riportato in auge in anni recenti un modello server-
centrico, molto simile a quello di vent'anni fa se non per il fatto che i 
client sono grafici.
Chiaro che la scalabilita' e' "potenziale": l'applicazione deve essere ben 
progettata. Che e' in genere il catch.


Grazie mille, sei stato chiarissimo.


infatti te lo fai prima che si apra..
mi spiego meglio..
Hai una classe che è la classe principale della tua applicazione.
Te il main lo metti in un'altra classe, designata solo a controllare la
versione e lanciare poi la classe principale.
Ovviamente nella classe col main te non puoi istanziare normalmente la
classe principale del programma, ma lo fai con Class.forName
Se l'aggiornamento lo fai prima di istanziare la classe principale, non
avrai problemi.
è ovvio che devi poter scrivere sulle tue classi o perlomeno in una
directory del classpath che viene prima di quella dove stanno le classi
principali del prog (es. la dir patch di JBuilder).
Lo stesso vale per altri linguaggi se organizzi il programma con dll e share
object
Si presuppone che la parte di codice che ha il main sia talmente elementare
che non sarà mai cambiata... oppure dici all'utente di riavviare il
programma.

 differenza rispetto ad un approccio Corba standard.
Ma corba funziona anche con processi remoti ? Non e' un sistema di
comunicazione tra processi locali, scritti anche in linguaggi
diversi ? Lo chiedo perche' tra qualche giorno comincio a studiarlo,
per sapere cosa mi aspetta...
-- 
Il segreto di una vita sana e' lo sport.
Mai farne.

 per sapere cosa mi aspetta...
Corba e' nato principalmente per sistemi remoti. "Funziona".. e' un altro 
discorso ;-). Tecnicamente si', ovviamente, ma quando e' nato la banda non 
era nemmeno lontanamente sufficiente per permettere le applicazioni che i 
creatori di corba avevano in mente. E oggidi ci sono tecnologie piu' 
semplici per far le stesse cose, che van bene nell'80/90% dei casi.
Ma le idee di base (registro di oggetti esposti, oggetti come "server", 
naming, indipendenza dalla locazione, interfacce separate dalle 
implementazioni, eccetera eccetera) sono ancora fondamentali e 
riscontrabili, spesso semplificate, in ogni architettura distribuita.
