Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Sul mapping tra record in un recordset e oggetti in una collection...

 differente da VB?
Purtroppo non ho altre esperienze ma posseggo una decente base teorica sulla
OOP e quello di cui sento la mancanza tutti i giorni sono le caratteristiche
OO che il linguaggio non offre. Molti problemi potrebbero essere risolti con
molto meno codice e più elegantemente sfruttando a pieno le carattiriste che
il modello prevede anche se l'utilizzo delle interfaccie a volte consente di
avvicinarcisi. Per questo attendiamo VB7.
Spero di non averti asciugato troppo, ciao. Rick.

 > generiche o specializzate? Perche'?
[SNIP]
Mi ero dimenticato un preblema che non ho ancora risolto: quando si lavora
su database multiutente, come fare per mantenere gli oggetti in memoria
coerenti con lo stato del db? Questa mi sa che è una questione veramente
spinosa e se qualcuno a qualche idea si faccia avanti.
Per il momento ho sviluppato un solo progetto con le tecniche descritte ed
era mono-utente. Ma nel caso di una futura espansione temo che avrei
notevoli grattacapi da risolvere.
Ancora ciao, Rick.

 spinosa e se qualcuno a qualche idea si faccia avanti.
Non ho mai effettivamente utilizzato questa tecnica se non in progettini di
test: nessuno di voi ha provato a riconnettere i recordset disconnessi e
gestire le eccezioni riportate da ado?
-vibino

 prima il tempo e la possibilita' di riscrivere la libreria in C++.
E' parecchio che mi ripeto la stessa cosa. Quello che mi manca, sempre, è il
tempo.
-vibino

 "re-idratarmi" :-)
Anche questa и stata un'altra bella asciugatura. La birra te la offro
volentieri, magari allo SMAU?
Stavo pensando che da questo thread si potrebbe forse tirare fuori un
articolo da mettere sul SC. Quando ho iniziato ho cercato a lungo e invano
esempi pratici di implementazione, questo potrebbe essere uno di quelli.
Ciao, Rick.

 prelevi, anche per una semplice prova, fammi sapere come è andata.
Sicuramente bisogna stare attenti.
Ciao, Rick.


Ciao, Rick.

 --
Sono al terzo anno (in corso), proprio al Poli, proprio ingenieria, proprio
informatica. Di quello che so per il momento solo una minima parte però
viene da li (e tra queste sicuramente il formalismo...) il resto è frutto di
una decina di anni di programmazione di cui ormai tre a livello
professionale (è dura ma mi piace).
Per caso vieni anche tu dall'Inferno (il Poli per l'appunto ;-)?
Ciao, Rick.

 prossimo futuro non potremo permetterci di non conoscerlo.
Sei a conoscenza di qualche buon libro sull'argomento? Oggi ho buttato un
occhio in libreria e ho trovato un sacco di testi su COM, COM+, DCOM e XML
ma nulla a proposito di SOAP. Anche la bibliografia dell'articolo che citavo
non conteneva riferimenti a testi ma solo ad altri articoli.
A proposito di questo argomento, qualcuno potrebbe farmi degli esempi di uso
concreto di XML magari spiegandone le potenzialità e le motivazioni che
hanno portato alla scelta di questa tecnologia rispetto ad altre (se
esistenti)?
Magari la domanda la trasferisco poi su un altro msg così le do un po' più
di visibilità.
Ciao, Rick.

 non conteneva riferimenti a testi ma solo ad altri articoli.
hai provato una ricerca su 
www.devx.com
 ? mi sembra che in genere diano
parecchi riferimenti.
e c'e' un'area dedicato a xml (volendo, con bollettino email).
escluderei cercare "soap" su amazon. forse forse se clausoli "technology" :)


Diciamo che, come Dante prima di me, dall'Inferno ne sono uscito (ma senza
passare dal traguardo).
E, se hai letto con attenzione il msg di "vibino", in questo stesso thread,
(quello dove si fa riferimento ad un certo server KOMODO), avrai capito
anche che:
- non siamo gli unici 2 ad arrivare da quegli ambienti (ma anche l'altro ha
lasciato)
- che non ero al Poli di Milano, ma... (
komodo.ing.unico.it
)


 un formato dati diverso.
Mi permetto di fare un po' di chiarezza:
1) SOAP (Simple Object Access Protocol) è una tecnologia basata su XML che
consente ad oggetti di qualsiasi tipo di parlarsi in un linguaggio
comprensibile. Le specifiche sono ancora oggetto di revisione, ma questo non
è eccessivamente preoccupante (più in basso dico il perché).
L'idea degli oggetti che comunicano tra di loro non è certo nuova, ma le
implementazioni di questa idea sono svariate e naturalmente tutte
incompatibili tra di loro.
Basti pensare agli standard più diffusi - DCOM per il mondo Microsoft, CORBA
per il mondo Unix: entrambi realizzano la stessa idea, ma in modo diverso.
Senza stare ad argomentare su quale sia migliore, limitiamoci a dire che un
oggetto DCOM non puo' comunicare con un oggetto CORBA e viceversa.
L'idea di SOAP è questa: su ogni piattaforma, in ogni struttura ad oggetti
distribuiti, fate quello che vi pare. Tuttavia, se sarete in grado di
effettuare - oltre a RPC proprietarie - chiamate SOAP in ascii puro con un
formato chiaro e non di proprietà privata (XML), potrete dialogare con altri
oggetti che fanno la stessa cosa.
Cosi', oltre ad essere ininfluente il linguaggio nel quale l'oggetto è stato
scritto (C, Object Pascal, Visual Basic, VbScript, Roal++), cosa che già
avviene con DCOM e CORBA (ma solo all'interno dei due mondi), sarà anche
ininfluente il tipo di tecnologia che userà o la piattaforma sul quale
girerà: tanto, alla fine della fiera, dovrà sempre generare in output un
ascii puro (xml), e comprendere una risposta altrettanto chiara (sempre in
xml).
Il protocollo privilegiato di SOAP e' l'HTTP standard, su porta 80. Ma per
quanto riguarda SOAP, la chiamata ascii potrebbe anche essere stampata su
carta, spedita via fax, letta da una signorina dall'altra parte ed inserita
a mano via telnet.
2) A questo punto, entro nel nostro mondo. Uno sviluppatore tipico Microsoft
ha due strade da percorrere:
     - Usare il tcp/ip direttamente, gestire winsock, generare 'manualmente'
l'xml da spedire, gestirne la risposta
     - Usare il Soap Packager di microsoft, che consente di usare SOAP come
se fosse un normalissimo oggetto COM.
In sostanza, usando ROPE (il soap packager di microsoft) viene mascherato
tutto il processo necessario per utilizzare soap, e si continuano ad usare i
tool di sempre. La cosa, poi, risulta particolarmente utile (ma non e',
quindi, l'intento principale) nel caso di comunicazioni DCOM attraverso
internet.
Il soap packager di Microsoft è quindi un wrapper per DCOM; SOAP è il
protocollo che sta alla base di esso.
Microsoft garantisce che utilizzando il Soap Packager già disponibile per il
download, le prossime variazioni di SOAP non costringeranno lo sviluppatore
a variare le proprie applicazioni: sarà il Soap Packager ad essere
aggiornato di conseguenza.
ROPE quindi garantisce la trasparenza di SOAP perché costituisce un
ulteriore layer di astrazione, ovvero un wrapper per SOAP nei confronti di
DCOM.
Supponiamo a questo punto che io debba richiamare una funzione di un oggetto
CORBA su una piattaforma Linux dietro ad un webserver Apache in internet. La
cosa, prima di SOAP, avrebbe presentato qualche problema. Ora, invece,
richiamerò i metodi e le funzioni di quell'oggetto come se fosse un oggetto
COM microsoft locale.
Esempio:
 dteDate = oggettoLontanoSuLinux.oraDelServer
Cosa avviene dietro le quinte:
1) La mia chiamata COM viene trasferita all'oggetto ROPE.
2) ROPE traduce la mia chiamata in XML
3) ROPE si connette al sito che io ho indicato
4) ROPE legge l'interfaccia XML dell'oggetto remoto dal webserver per
verificare che sia coerente
5) ROPE chiama la funzione relativa (HTTP POST) e gli passa i parametri e la
chiamata in formato XML
6) APACHE passa quanto riceve ad un cgi-bin che presumibilmente sarà simile
al ROPE di Microsoft (chiamiamolo ROPIX)
7) ROPIX traduce l'XML in una chiamata CORBA
8) ROPIX istanzia l'oggetto CORBA e chiama la funzione, passandogli i
parametri
9) L'oggetto CORBA fa quello che deve fare (nel nostro caso, prende la data
e ora di sistema)
10) L'oggetto CORBA restituisce il risultato al chiamante (ROPIX)
11) ROPIX prende la risposta e la traduce in XML
12) APACHE prende la risposta e la spara indietro al client connesso (che
noi sappiamo essere ROPE)
13) ROPE chiude la connessione HTTP e verifica che la risposta XML sia
valida
14) ROPE traduce la risposta XML in una risposta COM
15) Il nostro oggetto COM riceve la risposta
In sostanza, il processo è "simile" a quello di DCOM, ma non è
effettivamente un "sostituto" di DCOM. Il marshalling avviene tramite XML
invece che tramite protocolli proprietari, diventando cosi' non solo
cross-process o cross-server ma anche cross-platform.
Le possibilità aperte da questa nuova idea sono tali e tante che
l'organizzazione SOAP e le varie aziende compartecipanti stanno impiegando
quantità di risorse notevoli per arrivare al più presto ad una stesura
definitiva delle specifiche. Il soap-packager di MS però consente già da ora
di mettere in atto soluzioni funzionanti.
Concordo con Rick quando dice che è necessario stare attenti, ma solo
limitatamente. Sono fiducioso ed entusiasta.
-vibino

 ha scritto nel messaggio
news:8s428i$94f$1...@nslave2.tin.it...
[very snip]
Tutto quello che hai precedentemente espresso (in maniera esemplare oserei
dire) mi era già abbastanza chiaro. Nella mia domanda (alla quale aveva
risposto Roal) mi chiedevo come avveniva il trasferimento di interi oggetti
anziché di tipi puri.
Per intenderci meglio, nel tuo esempio il dato che deve essere trasferito
tra l'oggetti linux e l'oggetto winz è una data.
Supponiamo che invece io intenda fare una cosa di questo tipo: chiamo una
funzione di un oggetto server che inizializza un suo oggetto e me lo
restituisce (chiedo al server di crearmi un recordset e di restituirmelo).
Trami xml cosa mi viene restituito?
Tutti i record? Una cosa del tipo "l'oggetto ce l'ho qui pronto ora puoi
richiamarne i metodi"?
Nel caso la risposta sia del secondo tipo, ogni volta che richiamo un metodo
devo fare tutto il giro precedentemente descritto e mi sembra che la cosa
possa essere notevolmente lenta. E' vero che ogni volta che si guadagna in
generalità si deve necessariamente pagare qualcosa (e non voglio entrare in
discorsi filosofici) ma in questo caso il gioco varrà la candela (no ho mai
capito cosa significhi ;-)?
Anche a me l'idea sembra potente e mi rende entusiasta, quello che mi
preoccupa sono le implementazioni.
Ciao, Rick.

 capito cosa significhi ;-)?
vado molto a naso: che prima di edison giocare (a carte: cfr barry lindon)
costasse in cera, sego ecc. ?

[re-post richiesto da Rick Hunter]
