Newsgroup: it.lavoro.informatica
Titolo: interoperabilità: la chiusura del cerchio

http://www.theserverside.com/news/thread.tss?thread_id=46225
in questo video su theserverside, Ted Neward parla di come sia più 
vantaggioso utilizzare web services "message oriented" anziché orientati 
agli oggetti.
In pratica, dopo anni e anni di aggiunte di livelli di astrazione 
(Corba, RMI, EJB/COM, WSDL ecc.) si chiude il cerchio e si torna a 
scambiarci stringhe via SMTP o HTTP.
Che ne pensate?
ciao, U.

 Che ne pensate?
Sebbene io non possa certo definirimi un grande esperto di
J2EE/WebServices, ecc. (nonostante che il cliente finale paghi per me come
tale) penso che:
1) fino a quando non viene riconosciuto universalmente un metodo per
misurare il "livello di bonta'" di una soluzione rispetto all'altra e
misurarlo in modo quantitativo e ripetibile, le affermazioni del tipo
"questa tecnologia e' meglio di quest'altra" hanno la stessa validita'
delle previsioni zodiacali del mago Otelma
2) Per quanto al punto 1), io sono liberissimo di affermare senza tema di
smentita che Corba e i suoi derivati sono "merda pura"
(tanto per usare un francesismo), il cui uso non aggiunge niente di niente
a quello che potrebbe farsi senza l'utilizzo di tali tecnologie;
analogamente
per la tecnologia COM 
3) Sempre per quanto al punto 1) chiunque asserisse il contrario di quello
che asserisco io (ovvero che CORBA e i suoi derivati, e anche COM, sono il
meglio del meglio esistente) avrebbe ragione esattamente quanto me, ne'
una virgola di piu' ne' una virgola di meno.
4) Il punto 1) e' cio' che purtroppo  (io dico "purtroppo", ma qualcuno 
potrebbe dire "per fortuna") caratterizza l'informatica e gli informatici:
l'informatica (o meglio l'ingegneria del software) non si basa
praticamente su alcun fondamento scientifico ma solo su quello che dicono
oggi questo oggi l'altro a seconda che "questo" e "l'altro"  siano
considerati "buoni informatici" o meno. Io stesso ho le mie preferenze (ad
esempio io sono assolutamente certo della validita' della tesi di Dijkstra
["Program testing can be used to show the presence of bugs, but never to
show their absence!"], cosi' come sono certo della validità del principio
di conservazione dell'energia; oppure, per fare un altro esempio, a me
piace molto quello che dice Stallman sul "free software"; pero' e'
evidente che ne' la tesi di Dijkstra ne' quello che dice Stallman sono
cose dimostrate)
5) Sempre il punto 1) e' cio' che porta tutti gli informatici a sentirsi in
diritto di dire quello che e' giusto e quello che e' sbagliato e
soprattutto di sentire il diritto di affermare che gli altri debbano
scegleire 
la soluzione che piace a lui, perche' quello che piace a lui e'
semplicemente "migliore" di tutto il resto. E visto che non esiste alcun
metodo scientifico per smentirlo (in quanto non esiste un modo quantitativo
per definire quanto una soluzione sia migliore dell'altra), 
lui avra' sempre ragione sia quando dice  (A) che quando dice (not A).
6) Per tornare ai web services piu' in particolare, io qualche mese fa ho
scritto il mio primo WS client (anche un WS server, ma il server era
proprio a livello di "Hello World", mentre il client in questione
richiamava un server un po' piu' complesso [che mi dava la possibilita' di
mandare degli SMS verso un numero destinatario da passargli come
parametro]). Quindi
non ho grande esperienza. Ne approfitto per chiedere ai piu' esperti (
tra l'altro  io ho usato axis per cui il 90% del lavoro l'ha fatto lui e
quindi mi sono rimaste "nascoste" alcune parti del lavoro). 
Quello che non capisco bene e' che: se leggo un libro di qualche anno fa
(2002-2003), pareva che i web services fossero destinati a diventare una
cosa pervasiva del mondo (del tipo, io creo un WS server, metto qualcosa
in un registro UDDI che permettera' a chiunque in quattro e quattr'otto di
individuare il WS server suddetto e poi , una volta fatta l'interrogazione
UDDI, possono chiamarlo tranquillamente). A me pare che in realta' molte
aziende che sviluppano cose "WS based" se le tengano ben strette in
azienda senza esporre niente di niente; non viene praticamente  inserito
mai niente in nessun registro UDDI e anzi, se vuoi usare un WS server
creato da una azienda, devi chiedere autorizzazioni, aperture di firewall,
ecc. Spesso anche se vuoi accedere all'UDDI devi essere interno
all'azienda. E comunque il WS in genere non te lo fanno usare a meno che
tu non sia un altro "ente" interno della stessa azienda. Questa mia
impressione di cui
al punto 6) e' corretta ? E se non e' corretta, potete fare esempio di
qualche WS  che si possa utilizzare "pubblicamente" ? Oppure, piu'
probabilmente, non ho capito quale era l'intento iniziale dei WS. Qualcuno
puo' spiegare ?
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 delle previsioni zodiacali del mago Otelma
In questo caso non mi riferivo alla performance, ma a come ci siamo 
smazzati per anni nell'affrontare l'annoso problema 
dell'interoperabilità e dell'invocazione remota di "servizi", passando 
per eleganti mostri (corba), teorie, patterns, standard, application 
severs, service bus e via dicendo per arrivare a uno (mega esperto 
dell'argomento) che ti dice:
"ragazzi oh, alla fine sai che vi dico? Ma scambiamoci un po' di 
stringhe via mail e festa finita".
E il bello è che non è per nulla stupida, l'idea.
2)3)4)5) cut.  sorry :)

No, non è corretta.
I WS sono usati anche in scenari cross-enterprise, ad esempio nel 
settore di cui mi occupo, per recuperare documentazione e informazioni 
mediche da archivi remoti. Anzi, direi che una delle chiavi di successo 
dei WS è stata proprio quella di appoggiarsi su HTTP e quindi di trovare 
aperte sui firewall le tipiche porte usate per tale protocollo (80).
I problemi dei Web Services sono però i seguenti (dalla mia esperienza):
- Molti, sulle ali dell'entusiasmo, pensano che siano la soluzione di 
TUTTI i problemi di interoperabilitá, e in generale di TUTTI i problemi 
IT. Una specie di panacea dei mali dell'informatico moderno. E non è 
ovviamente così.
- Sono stati prodotti e approvati zilioni di standard sui WS. "You name 
it, you have it" dicono gli americani. E zilioni di standard messi 
insieme costituiscono qualcosa che NON è standard.
- Oltre agli zilioni di standard ci sono pure aziende (tipo una dalle 
parti di Seattle) che, come da tradizione, non li rispettano al 100%, 
rendendo non interoperabile ciò che era nato proprio per favorire 
l'interoperabilità
- I web services sono semplici da usare e implementare. Ma 
un'applicazione enterprise (e cross-enterprise) non DEVE essere troppo 
semplice, altrimenti IBM, Oracle, Bea ecc. come giustificano la vendita 
di application server che costano migliaia di euro?
ciao, U.

 qualche WS  che si possa utilizzare "pubblicamente" ?
Tutto il motore di ricerca di gugol...
-- 
I.M.D. faq-you and menimanimor: 
http://indec.altervista.org
 
Magnt Quisht!
Io Voto Cina!
L.F.N.E.
http://img300.imageshack.us/img300/3158/untitledip8.png

 scambiarci stringhe via SMTP o HTTP.
Che lo stanno dicendo un milione di persone da mesi e mesi :-)
REST anyone?
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 REST anyone?
qualcuno addirittura dal 2000 e quel qualcuno e' uno di quelli dientro ad
HTTP... (check wikipedia for more)



-- 
d.
http://blog.deelan.com/

 di application server che costano migliaia di euro?
Mah.. ? Io questa cosa la capisco, ma probabilmente anche se non e' "troppo
semplice" la vendita dei sopracitati "mostri" si giustifica poco comunque
se non con il convincimento che si riesce ad inculcare nella testa dei
manager delle multinazionali.
Ciao,
Marco.


 Saluti


 metodi scientifici noti.
Dimenticavo... io tali metodi, ovviamente, non li conosco, ma se esistono
saro' ben lieto di andarmeli a studiare (sempre che non siano richieste
cifre folli per studiarseli). In ogni caso, se tali metodi esistono,
l'opinione del tizio di cui al link riportato da UC immagino che sara'
stata validata da uno di questi metodi (oppure, come minimo, immagino che
il tizio stia chiedendone la validazione con uno di questi metodi) e
quindi la risposta
all'iniziatore del thread e' semplice: "io penso che se tali metodi
esistono, visto che hanno valore scientifico => quando uno di questi
metodi validera' la
teoria del tizio (scambiarsi stringhe e' meglio che passare le ore a
pensare
a oggetti complicatissimo), allora avra' ragione". Mi sembra che non
ci sia quindi molto di cui discutere se non andarsi a vedere questi metodi.
Ciao,
Marco.


 
Interessante, non ne sapevo nulla (mia ignoranza). Quantomeno fa 
riflettere. È un po' come CRUD per i DB, con quelle quattro funzioni ci 
puoi fare tutto, ma davvero vogliamo che i nostri client sappiano come 
poter fare tutto? :)
ciao, U.

 Puoi postare qualche riferimento ?
Ne ho cercati io alcuni autonomamente. Se le best practice a cui ti
riferisci
sono quelle riportate ad esempio 
qui:
http://en.wikipedia.org/wiki/Best_practice
o in alcuni link li' contenuti (tipo questo
http://en.wikipedia.org/wiki/Performance_engineering
)
allora sono cose che piu' o meno conoscevo e, ovviamente, confermo
in pieno quello che ho scritto nell'altro post, visto che e'
ovvio che le best practice valgono per certi obiettivi dichiarati
(e magari la best practice per construire un'automobile che sia la meno
inquinante del mondo e/o quella che ha rendimenti maggiori e consumi piu'
bassi, sara' diversa dalla best practice per costruire un'automobile che
debba vincere il mondiale piloti e/o il mondiale costruttori di formula 1).
In assenza di obiettivi dichiarati vale tutto quello che ho scritto in
precedenza, come e' ovvio che sia.
Ciao,
Marco.


 ciao, U.
finchè non scoppiava la bolla speculativa delle niu economi continuavano a
creare tecnologie pesantissime e poco pratiche per fare in maniera
complicata ciò che è semplice. Utilizzare i film xml in tutti contesti in
cui bastava un file di testo con ritorno a capo a fine riga è il capolavoro
delle vaccate tecnologiche.

UC ha scritto:

fidarsi di un guru di integrazione java/.net che parla di 
semplificazione è come fidarsi di un pedofilo che parla di pedagogia.
parlare di un approccio message-oriented e protocolli "antichi" come 
smtp o http (oltre a jms) vuol dire poco.
quali delle decine di protocolli incapsulati su http negli ultimi anni 
ti fa pensare che questa sia la volta buona? :-)

 poter fare tutto? :)
Parlo in generale: non è strano fare web applications e non conoscere
gli standard del web?
REST dopotutto è per buona parte "HTTP usano con i crismi"


 REST dopotutto è per buona parte "HTTP usano con i crismi"
conosco da anni post,get,delete e put, e HTTP in generale. Non conoscevo 
la "scuola di pensiero" REST o chiamala come vuoi.
E menomale, che non conosco tutto :)
ciao, U.


Non credo sia la volta buona, riflettevo sull'evoluzione del pensiero.
Non siamo ancora pronti per abbandonare ereditarietà, polimorfismo, 
incapsulamento. :)
ciao, U.

 incapsulamento. :)
???
;-)
Scherzi a parte, credi che il pardigma OOP sia "finito"? O è solo per un 
certo tipo di ambito (tipo l'interconnessione di sistemi enterprise)?
Ciao,
Giulio

 REST dopotutto è per buona parte "HTTP usano con i crismi"
Si, nessuna definizione poteva essere migliore!
Ciao,
Giulio
--
OnAir: Symphony X - "The serpent's kiss"

 E menomale, che non conosco tutto :)
Non mi riferivo a te ovviamente. Parlavo di chi implementa sti beneamati
WS :D
Prima o poi la pianteranno di sputare fuori standard XML ogni 3 per 2 :D



No, no, figurati. Sono un fermo sostenitore del paradigma OOP. Non metto 
  però in dubbio il fatto che in futuro potrebbero esserci evoluzioni 
che spingeranno a metterlo da parte.
Già il mondo di oggi è molto meno orientato agli oggetti (e più ai 
servizi) che quello di qualche anno fa.
Inoltre mi piacerebbe anche sapere quanti prodotti software là fuori 
sono *veramente* orientati agli oggetti.
ciao, U.


Magari questo stesso "guru" qualche anno fa decantava
gli EJB come soluzione definitiva. In qualche modo devono pure
guadagnarsi da vivere, i guru.....

 guadagnarsi da vivere, i guru.....
In India si parla di alcuni guru che hanno poteri straordinari. Uno di
questi č materializzare cose dal nulla.
Da noi ci sono certi guru che fanno trasmutazione della materia: dalla
merda materializzano soldi. E la cosa piů sorprendente č che quando
producono soldi in questo modo la materia prima non viene nemmeno
consumata...

 tema: "CORBA questo oggetto gia' morto e defunto da un pezzo".
In quella stessa intervista Neward dice "Corba è morto perchè...., anzi 
no, scusa, che Corba è morto non si può dire" :)
ciao, U.

 Che ne pensate?
Penso che tutto dovrebbe essere il più semplice possibile, ma non di
più (cit.).
Ecco perchè si usano ancora i flat file per scambiarsi dati, l'analisi
si fa su word invece che su Rational Rose ecc.. ecc..

 sono *veramente* orientati agli oggetti.
Questo sarebbe interessante.
E IMHVO sono molte più di quanto ci si aspetta.
Ciao,
Giulio
-- 

> Tutto il motore di ricerca di gugol...
http://code.google.com/apis/soapsearch/

 
Cerco di immaginare lo stupore degli antichi alchimisti se avessero 
scoperto che la pietra filosofale che andavano cercando era in realta' 
un stronzo!
:-))
-- 
Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñejoAlcoolInside
Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'