Newsgroup: it.comp.java
Titolo: [ANN] Rilasciato GMI su HTTP(S): potete darmi feedback?

Ciao,
    vi disturbo per annunciare pomposamente che GMI su HTTP(S) e' stato da me rilasciato,
uff, finalmente! In gran parte e' merito vostro che mi avete chiesto di vederlo, e io
allora appena ho fatto una release semi-stabile l'ho postata sul mio sito.
   Ma che cos'e' GMI? Come recita la pagina sul mio sito GMI e' un middleware (vabbe',
neanche io ci credo, ma non sapevo come chiamarlo!) che vi permette di richiamare oggetti
remoti su un server utilizzando (per ora) il protocollo HTTP(S) coadiuvato da un servlet
engine. Ad esempio vi permette, da un applet, di invocare un metodo di un oggetto che
risiede sul server passando qualsiasi firewall, costruendo con facilita' sistemi composti
da oggetti che dialogano fra di loro, in modo trasparente, su internet. Il tutto
ovviamente in modo trasparente, usando dei veri oggetti java generati automaticamente da
un compilatore (tipo RMIC, per intenderci).
    Quello che vi chiedo e' se potete darci un'occhiata e dirmi se vale la pena di
continuare, se secondo voi vi sembra interessante, e dove vedete possibili enhancements.
Io attualmente sto rifattorizzando il codice, con l'intenzione di creare
un'implementazione che vada su UDP (che dire, mi strippa l'idea!) ma se voi avete altre
idee sono disponibile.
   Inoltre il sistema funziona, io lo uso in produzione su almeno 4 progetti (anche se il
codice e' molto cambiato ultimamente!) e vi invito ad usarlo se vi servisse! E' ovviamente
free, o gnu, o biribu, insomma, quello che vi pare, il licensing non l'ho ancora deciso:
per ora e' li, chi lo vuole lo usi. 
Allora aspetto il vostro feedback.
Grazie in anticipo,
    Bruno.
|
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://members.xoom.it/bbruno
| 
http://digilander.iol.it/bbossola
|


E' esattamente quanto feci in un progetto di 3 anni fa: scrissi anche un
articolo su Computer Programming qualche tempo dopo. A parte il nome,
esattamente la stessa cosa. Il compilatore per gli stub e skeleton però
doveva far parte di un progetto successivo e non lo rilasciai mai per
colpa del mio ex-capo: non voleva "regalare" know how con l'open source.
Che dire? per funzionare funziona... ma all'epoca (1998/1999) il sogno
di invocare metodi remoti da applet era molto più in voga di oggi, tanto
che Netscape include ancora le classi di Visibroker per fare applet
Corba. Oggi mi sembra i tempi siano un po' cambiati, secondo me è meglio
usare "standard" come XML-RPC.
ciao
UL

 usare "standard" come XML-RPC.
Allo stato attuale di implementazioni non riesce a fare completamente la 
cosa piu' interessante: interfacciare EJB. Banale per Sessionless, 
impossibile per tutto il resto!
Quindi si ripiega su Corba eccetera e eccetera.


Uhm... Non ho capito se l'hai provato o no. Comunque si, funziona :-D Ed e' ancora in
voga, un mio amico ha recentemente messo in produzione un progetto basato su
applet-servlet, e' per questo che e' nato.
E nonostante i fulmini di Castagna! :-D (Ciao!)
Adesso pero' colgo l'occasione e mi lancio in qualche mia considerazione! Cosi' almeno
movimentiamo un po' sto' thread :-D
Io ho idea che i cosiddetti *standard* servano poco per certi tipi di applicazioni o di
progetti. Mi ricordo in particolare una chiaccherata con Jim Waldo, era il 1997 e
parlavamo di RMI, e noi gli contestavamo, giusto per punzecchiarlo, il fatto che RMI non
fosse open verso altri sistemi distribuiti. Lui ci disse delle parole che ricordo ancora
oggi: "you must see Java as a platform". Che dire, io ancora ci credo :-) Ancora di piu'
ora, quando mi rendo conto che scrivere un sistema cosiddetto "open" costerebbe molto di
piu' e darebbe le stesse funzionalita'. 
Come forse alcuni di voi sapranno (e tu Ugo di sicuro :-D) io sto utilizzando un nuovo 
metodo per lo sviluppo del software, chiamato XP (vedete sul mio sito per i link). Uno dei
principi interessanti esposti e' che noi dobbiamo lavorare per il cliente, e cercare di
consegnargli funzionalita' il piu' velocemente possibile. Io trovo che scrivere verso
standard aperti quando questo non sia necessario e' solo anticipazione, che fa spendere
soldi al cliente mentre a lui non viene consegnata alcuna funzionalita' in piu'. Perche'
fare cosi? Un conto e' se dobbiamo parlare con un sistema che espone solo un'interfaccia
CORBA, e' ovvio che dobbiamo usare quel particolare middleware. Ma se non e' cosi? Se
dobbiamo scegliere la cosa + semplice che funzioni, perche' gettarci in un complesso
sistema ad oggetti distribuiti? Magari anche con transazioni distribuite? Perche' invece
non facciamo la cosa piu' semplice che funzioni, anche brutale, solo socket, se ci
mettiamo meno? Se con un minore sforzo, consegnamo le stesse funzionalita?
Vi faccio un esempio che mi e' capitato in questi giorni. Recentemente su un progetto un
analista (mah... non so come definirlo, non so che ruolo ha) e' venuto da me con un
insieme di fogli che descrivevano gli attributi (complessi) di un oggetto di un sistema,
chiamato "controparte", dicendomi "ovviamente dobbiamo realizzare un DB". Ovviamente un
corno! Sapete quante controparti ci sono nell'intero sistema? Due! Pensate che io
decidero' di spendere i soldi del cliente per fare un database? Lo faro' se me lo chiede
il cliente: io gli diro quanto costa il DB e quanto costa invece (per esempio) far
persistere i dati su un file XML, e lui scegliera' in modo cosciente, dopo che io gli
avro' descritto i pro e i contro. Incoscienza? Coraggio? No. Semplicemente, i soldi sono
del cliente, lui decide, debitamente informato, come e' meglio spenderli. Perche' e' anche
un questione di priorita': perche' se sceglie il database, a mettere su tutto ci metto un
mese, e in produzione non c'e' ancora nulla. Se invece sceglie qualcos'altro, magari dopo
un mese e' in produzione, e dopo tre o quattro mesi magari decide di realizzarlo sto'
database, quando ormai il sistema e' alla sua quarta o quinta iterazione, e molti problemi
o dubbi si sono chiariti.
Prendiamo ora un esempio piu' alla moda, J2EE. Pensate che il valore di J2EE stia
nell'essere tanto OO? Che fare implementare ad un oggetto 5 interfacce ed assegnargli cosi
altre 5 responsabilita (oltre alla sua) sia OO? O nel fatto che vi fornisca delle librerie
di basso livello per fare cosette come il pooling di connessioni o di thread?. J2EE, come
dice Francesco, e' un buon sistema per fare collaborare gli oggetti, stop.
Perche' usare J2EE? Usatelo quando vi serve, quando le collaborazioni sono complesse,
quando le interazioni fra le compomenti sono incasinate, ma _non_ usatelo come scelta
obbligata o come panacea universale! E lo stesso vale per qualsiasi altro sistema "open" o
"framework" o "sottosistema", puoi leggerci database, middleware, framework, protocollo...
la domanda che dovete sempre farvi e': mi serve?
GMI (che io spaccio per scopi pubblicitari personali :-) come un sistema generico) in
realta' e' nato (oltre che grazie ad una mia lunga esperienza nel colloquio
applet-servlet) soprattutto dalla richiesta di un mio amico (che mi ha fatto da "cliente")
che aveva bisogno da un applet di parlare con un oggetto sul server. That's all! Poi mi ha
richiesto di gestire una sessione, e uala', eccola inserita. Poi ho ricevuto una richiesta
da un altra persona che mi chiedeva di realizzare la stessa cosa in rete, gli ho proposto
UDP, gli piace, e uala, mi sono messo a farla. Sapete, c'e' anche stato uno che mi ha
chiesto di farne una versione che parlasse in SOAP :-D Quello pero' mi sa che non lo
faccio...  ;-D Qualcuno si fa avanti?
Ciao a tutti,
    Bruno.
P.S.
Hey, ogni tanto mi piace scrivere un messaggio luuuungo, scusate se ci avete messo tanto
tempo a scaricarlo e non vi interessava per niente :-D
