Parliamo di web services

[Barbalbero]

Ciao a tutti... Vorrei parlare di web services nella teoria ma soprattutto nella pratica. Un po' di cose le so, ma ci sono diversi punti che mi sono ancora oscuri. Per chiarire meglio le idee iniziare proponendovi questo semplice caso(inventato) e vedere cosa ne vien fuori.

PARTE 1:
In Lombardia ci sono 3 aziende che producono tappi di sughero. Le aziende non collaborano tra di loro e utilizzano 3 DBMS differenti con database con strutture differenti (nomi di tabelle differenti, topologie differenti ecc). Alice è una programmatrice e propone alle 3 aziende di vendere online. Per far ciò ritiene che una buona soluzione possa essere quella di rendere i database delle aziende consultabili e modificabili via inernet secondo query prestabilite (cerca tappi di tot mm, forma x ecc , oppure rimuovi tappo dal db perché l'ho comprato). Per far ciò decide di sviluppare un web service.
Domande:
- E' una buona idea quella che ha avuto Alice? C'era una soluzione migliore?
- Supponendo che la soluzione web service sia la migliore. Quali sono, brevemente, i passi che Alice deve seguire per la realizzazione di questo sistema? (se possibile usare le parole pagine gialle, verdi, bianche, SOAP, UDDI, WSDL)

PARTE 2:
In Sicilia Bob intraprende lo stesso business indipendentemente e realizza un web service analogo tra le aziende di tappi di sughero siciliane.
Domande:
- Come si può fare in modo che i due sistemi, generalmente incompatibili, possano interoperare permettendo a Carmelo, un cliente, di eseguire query su tutti quanti i database?

[khelidan1980]

quindi?

[Barbalbero]

Quindi cosa?

[khelidan1980]

Quindi cosa?

Cosa chiedi?di rispodere all'esercizio?

[Barbalbero]

non è un esercizio. E' un caso pratico per capire concretamente cos'è un web service, quali sono i vantaggi, i limiti e gli svantaggi

[PGI-Bis]

Alice l'ha pensata male, anzi, se riteniamo che il pensiero richieda un po' di logica, non l'ha pensata affatto.

Il suo problema infatti è la disomogeneità strutturale delle sorgenti dei dati: poichè i web service sono dei vettori di calcolo - cioè degli strati intermedi tra richieste e computazione dei risultati - è chiaro che dire che siano la soluzione è come affermare "porto le vitamine per non bagnarmi quando piove".

Bob invece ci va più vicino perchè comprende che il nodo della questione sta nel fatto che la rappresentazione dipende dal fine e le diverse aziende possono avere ciascuna una definizione di tappo diversa.

La cosa interessante è che ne Alice nè Bob hanno un problema di web-service (d'altronde li conosciamo come esperti di crittografia, non di crud): devono invece affrontare una questione di insiemistica, ovvero determinare l'insieme minimo di caratteristiche necessarie e sufficienti alla rappresentazione di un bene ai fini della sua vendita che sia anche un sottoinsieme degli insiemi di caratteristiche che ciascun produttore ha associato al proprio prodotto.

Solo se esiste un tale insieme il progetto è fattibile senza mettere le mani sui tappi altrui.

Quindi la prima domanda è: quali sono le caratterisiche minime necessarie affinchè un "tappo" possa essere venduto?
La seconda è: tutti i tappi dei diversi produttori le possiedono?

Se 2 x sì, il passo successivo è una questione di hashing, risolta la quale (a meno che non mi sfugga qualcosa) si potrà pensare a come rendere disponibili i dati, eventualmente con un web-service.

[bobbytre]

a me dispiace per Charlie ...

sostituito in questa occasione da tale carmelo :(

[tomminno]

PARTE 1:
In Lombardia ci sono 3 aziende che producono tappi di sughero. Le aziende non collaborano tra di loro e utilizzano 3 DBMS differenti con database con strutture differenti (nomi di tabelle differenti, topologie differenti ecc). Alice è una programmatrice e propone alle 3 aziende di vendere online. Per far ciò ritiene che una buona soluzione possa essere quella di rendere i database delle aziende consultabili e modificabili via inernet secondo query prestabilite (cerca tappi di tot mm, forma x ecc , oppure rimuovi tappo dal db perché l'ho comprato). Per far ciò decide di sviluppare un web service.
Domande:
- E' una buona idea quella che ha avuto Alice? C'era una soluzione migliore?


Pessima idea. Non si espone un database su internet. Si espongono funzionalità ovvero nel tuo esempio: Ricerca tappi e Compra tappo. Poi cosa queste funzionalità comportino non è interesse del chiamante.
Inoltre essendo il webservice pubblico ci vuole una qualche misura di sicurezza, altrimenti chiunque potrebbe dirti che ha comprato un tappo, svuotandoti il magazzino, magari senza pagarti...


- Supponendo che la soluzione web service sia la migliore. Quali sono, brevemente, i passi che Alice deve seguire per la realizzazione di questo sistema? (se possibile usare le parole pagine gialle, verdi, bianche, SOAP, UDDI, WSDL)


Sicuramente oggi un webservice SOAP è la soluzione più indicata, è uno standard ampiamente utilizzato che consente una elevata interoperabilità tra sistemi non omogenei, nonchè è supportato da tutti i principali linguaggi di programmazione.
Creare un webservice è questione di pochi minuti e non presenta difficoltà pratiche.
[Edit] Dimenticavo che c'è anche REST, ma il supporto è un pò meno universale rispetto a SOAP


PARTE 2:
In Sicilia Bob intraprende lo stesso business indipendentemente e realizza un web service analogo tra le aziende di tappi di sughero siciliane.
Domande:
- Come si può fare in modo che i due sistemi, generalmente incompatibili, possano interoperare permettendo a Carmelo, un cliente, di eseguire query su tutti quanti i database?

Il cliente non effettuerà mai queste operazioni come le intendi te, ma utilizzerà uno strumento che si interpone tra lui e i webservice, generalmente un website che eseguirà le ricerche su entrambi i sistemi. Ovviamente non essendoci uno sviluppo coordinato, ognuno avrà la propria interfaccia e il website dovrà fare da adattatore tra l'interfaccia esposta al cliente finale e quella invece pubblicata dai webservice.

[tomminno]

Quindi la prima domanda è: quali sono le caratterisiche minime necessarie affinchè un "tappo" possa essere venduto?
La seconda è: tutti i tappi dei diversi produttori le possiedono?


Secondo me questo non è necessario, anche se ovviamente auspicabile, soltanto che agendo da intermediario non c'è modo di intervenire sul sistema complessivo. Pertanto si fanno funzionare le cose anche senza che tutto sia come in un mondo ideale dovrebbe essere, perchè così va il mondo.

A lavoro abbiamo 3 grossi fornitori internazionali che vendono esattamente gli stessi medesimi oggetti, ma ognuno richiede che per acquistare un bene tu fornisca informazioni differenti e, nonostante adottino tutti lo stesso protocollo, non solo i dati ma anche le modalità con cui questi dati devono essere scambiati sono differenti.
Uno vuole 10 dati di cui 7 obbligatori, un altro ne vuole 15 di cui 10 obbligatori, quello che è obbligatorio per il primo non lo è per il secondo e viceversa. Uno ti vende il bene semplicemente dicendogli "lo compro" e hai immediatamente il risultato dell'operazione, l'altro ti chiede di accodare la richiesta e ricontrollare periodicamente lo stato di avanzamento per avere notifica dell'esito dell'operazione.

[Barbalbero]

oh hai centrato la questione :D

Pessima idea. Non si espone un database su internet. Si espongono funzionalità ovvero nel tuo esempio: Ricerca tappi e Compra tappo. Poi cosa queste funzionalità comportino non è interesse del chiamante.
Inoltre essendo il webservice pubblico ci vuole una qualche misura di sicurezza, altrimenti chiunque potrebbe dirti che ha comprato un tappo, svuotandoti il magazzino, magari senza pagarti...

Beh se Alice utilizza un WS per accedere al DB da internet quello che fa è appunto esporre delle funzionalità appunto tipo "compra tappo" che saranno transazioni progettate in modo atomico e sicuro.



Sicuramente oggi un webservice SOAP è la soluzione più indicata, è uno standard ampiamente utilizzato che consente una elevata interoperabilità tra sistemi non omogenei, nonchè è supportato da tutti i principali linguaggi di programmazione.
Creare un webservice è questione di pochi minuti e non presenta difficoltà pratiche.


Sicuro che è questione di pochi minuti? Io credo che Alice debba recarsi nelle varie aziende e, tramite qualche barbatrucco che non conosco ancora, dovrà scrivere delle funzioni ad hoc per ogni DBMS. In pratica fornirà un'interfaccia standard verso internet, ma sotto dovrà intervenire personalmente su ogni sistema. O sbaglio?

Il cliente non effettuerà mai queste operazioni come le intendi te, ma utilizzerà uno strumento che si interpone tra lui e i webservice, generalmente un website che eseguirà le ricerche su entrambi i sistemi. Ovviamente non essendoci uno sviluppo coordinato, ognuno avrà la propria interfaccia e il website dovrà fare da adattatore tra l'interfaccia esposta al cliente finale e quella invece pubblicata dai webservice.

Sì ma io davo per scontato che Carmelo accedendo a www.tappidisughero.com avrebbe potuto cercare su tutti i DB poiché il sito era "connesso" ai due WS. Comunque era proprio questo il punto che mi sembrava più interessante: un eventuale cliente che intende utilizzare i WS, si trova di nuovo di fronte a due interfacce differenti. In questo caso sono due, ma su larga scala diventerebbero decine o centinaia, rendendo infattibile la cosa.

(oh cavolo ma quel sito esiste davvero, non prendetelo per pubblicità :D )