Newsgroup: it.comp.java
Titolo: Descrivere una connessione socket con WSDL

Ciao a tutti,
sono nuovo di questo gruppo e mi sto affacciando da poco al mondo dei
web services.
Ho il seguente problema:
Il mio web service mette a disposizione un servizio per l'elaborazione
di file binari. Un utente può inviare il file al web service e poi
invocare il servizio offerto tramite uno dei metodi descritti in una
interfaccia java.
Ho quindi la mia interfaccia java e il file WSDL associato.
Ora, come faccio a specificare nel WSDL che il file deve essere
inviato aprendo una connessione socket SSL col web service?
Cioè, per inviare il file l'utente non utilizza i metodi messi a
disposizione dall'interfaccia ma lo deve fare via socket. Nel WSDL
vengono descritti i metodi dell'interfaccia, i parametri e il binding.
Come faccio a specificare che l'invio del file deve avvenire aprendo
una connessione socket con un determinato indirizzo (address:port)?
Posso specificare ciò nello stesso WSDL che utilizzo per descrivere
l'interfaccia?
Ciao a tutti e grazie per eventuali consigli
SgNaPpO

 l'interfaccia?
finora ho fatto solo qche esperimento con i web services e non ho
mai provato a utilizzarli via SSL, btw il WSDL permette di utilizzare 
diversi protocolli per il binding (HTTP, SMTP etc..) anche se io
ho sempre e solo visto esempi con HTTP. Non ti basta modificare
la sezione del binding del WSDL mettendo HTTPS invece di HTTP ?
o forse tu invendi una connessione SSL non di tipo HTTP ?
in tal caso ho la vaga impressione che le implementazioni "client-side"
di SOAP/WSDL non supportino protocolli diverse da quelle piu'
comuni e che quindi sia necessario scriversi il codice per gestire
la comunicazione...
Btw non sono molto sicuro xche' non ho mai guardato i vari
WS-Security e simili per connex sicure con i WS

 ha scritto nel messaggio
news:c4c1p1$299$1...@lacerta.tiscalinet.it...


 L'idea è quella di avere il WS in attesa di connessioni su una data porta.
Ho capito, ma leggendo qui:
http://www.w3.org/TR/wsdl12-bindings/
si parla solo di SOAP e HTTP-GET/POST (e MIME), quindi non penso sia
possibile specificare una connessione diretta tcp/ip e sia invece
necessario utilizzare uno dei protocolli previsti
forse e' possibile aggiungere nuovi protocolli sfruttando 
l'estensibilita' di WSDL, ma in ogni caso il client che riceva
il WSDL deve essere in grado di sapere come gestire tale protocollo,
quindi se dall'altra parte qualcuno usa un classico wsdl2java
(presente in Axis, nei toolkit IBM e SUN etc..) non riuscira' mai
a generare del codice "buono" lato-client visto che quel che stai
facendo e' un utilizzo "non comune" dei protocolli
In sostanza, probabilmente la cosa si puo' fare estendendo il WSDL
(d'altra parte dovrebbe poter supportare anche SMTP e simili ma
su quella pagina del w3c non se ne fa menzione) ma poi non pensare
che un client generico sia in grado di gestirlo senza scrivere codice
ad-hoc

Ciao, NC!
Il giorno 31/03/2004 alle ore 10:42 hai scritto:
 N> si parla solo di SOAP e HTTP-GET/POST (e MIME), quindi non penso sia
 N> possibile specificare una connessione diretta tcp/ip e sia invece
 N> necessario utilizzare uno dei protocolli previsti
La connessione ad un web service non e' altro che una comune connessione
TCP/IP su una certa porta, il protocollo SOAP invece definisce che i dati
che passano attraverso questa connessione utilizzano il protocollo standard
HTTP. Nulla vieta di installare un web service su una porta arbitraria ma lo
si deve fare modificando la configurazione del server che sta dietro al web
service. Il service di suo non "ascolta" nulla, e' quello che sta dietro che
ascolta su un certa porta e si accorge se si sta invocando un web service o
altro e quindi passa la palla al codice che gestisce tutto.
Gestire una connessione ad un web service su una porta qualsiasi utilizzando
un protocollo non standard implica il dover scrivere anche tutta la logica
del server e dello scambio dati (il che francamente visto il numero di
server gratuiti esistenti mi sembra del tutto inutile). Senza contare che
avrebbe anche implicazioni lato client che non saprebbero come gestire le
connessioni.
Bye
-- 
Marco Maccaferri
MaccaSoft - 
http://www.maccasoft.com

 connessioni.
appunto, quello che ho detto io :)
se vuoi creare WS sicuri, conviene guardarsi cio' che compete i WS
come sicurezza e crittografia (ci sono un po' di articoli su 
developerworks di ibm mi pare)

 ha scritto nel messaggio
news:4b2283d4.04033...@posting.google.com...


Ciao, SgNaPpO!
Il giorno 31/03/2004 alle ore 15:00 hai scritto:
 S> Potrei utilizzare SOAP, allegarci il file e inviare il tutto tramite
 S> https, ma purtroppo la logica del WS è già implementata e la ricezione
 S> del file avviene tramite connessione socket (TCP/IP).
Non puoi aggiungere un metodo al web service che riceve il file e si
preoccupa lui di comunicarlo a quell'altra "entita'" utilizzando la
connessione TCP/IP opportuna ? I tuoi client invierebbero i file utilizzando
esclusivamente il web service standard nascendendo loro tutta la logica che
ci sta dietro.


 esclusivamente il web service standard nascendendo loro tutta la logica
che ci sta dietro.
Forse non sono stato chiaro :((...allora:
ho un client che tramite un content provider(CP) (colui che ha i file) può
decidere di fare una trasformazione su un file. Questa trasformazione però
non la fà il CP ma viene delegata ad un WS che accetta il file solo ed
esclusivamente tramite socket TCP/IP.
Il WS è già implementato, posso solo cambiare la logica interna ma non la
modalità di ricezione del file. E' in ascolto su una data porta in attesa di
ricevere un file.
Quindi il client sceglie un file dal catalogo del CP e decide ad esempio di
comprimerlo. Quindi il CP invia il file al WS tramite socket e invoca il
metodo per la compressione. Il WS ricevuto il file si aspetta l'invocazione
di un metodo per operare sul file. Fatta l'elaborazione (es.compressione) lo
riinvia al CP che poi lo invia al client.
L'invocazione del metodo per la compressione (executeZip()) avviene
normalmente tramite SOAP e la sua descrizione è fatta tramite WSDL.
Ora il problema è nell'interazione CP-WS per lo scambio del file che
purtroppo avviene tramite socket TCP/IP :((
Devo far capire al CP che per utilizzare quel WS ha bisogno di implementare
della logica per l'invio del file tramite socket.
Quindi quando il CP fa una ricerca nel registro UDDI e scarica il WSDL del
mio WS deve poter avere anche quest'altra informazione.
Forse per questo problema il WSDL non è d'aiuto o forse servirebbe
qualcos'altro...ma cosa?
Spero di aver aggiunto altre informazioni utili :-)
Ciao e grazie!
SgNaPpO

Ciao, SgNaPpO!
Il giorno 31/03/2004 alle ore 16:46 hai scritto:
 S> Il WS è già implementato, posso solo cambiare la logica interna ma non
 S> la modalità di ricezione del file. E' in ascolto su una data porta in
 S> attesa di ricevere un file.
Allora non e' un web service. Come ho gia' detto un web service non ascolta
nulla. Se questa "entita'" e' in ascolto su una porta si tratta di un
servizio server come ad esempio un server ftp. Se fosse un web service
avresti un metodo 'sendfile' da utilizzare per inviare il file e avresti
risolto il problema.
Se anche e' implementato come web service e all'inizializzazione fa partire
un thread con un server che accetta i file si tratta di una bella
castroneria di programmazione.
 S> Il WS ricevuto il file si aspetta l'invocazione di un metodo per operare
 S> sul file. Fatta l'elaborazione (es.compressione) lo riinvia al CP che
 S> poi lo invia al client. L'invocazione del metodo per la compressione
 S> (executeZip()) avviene normalmente tramite SOAP e la sua descrizione è
 S> fatta tramite WSDL.
Mi piacerebbe vedere il sorgente per capire come hanno risolto il problema
delle sessioni e dell'assegnazione certa di un file ad un client.
Sinceramente non capisco perche' la gente ama complicarsi la vita in questo
modo.
 S> Ora il problema è nell'interazione CP-WS per lo scambio del file che
 S> purtroppo avviene tramite socket TCP/IP :((
Errore di progettazione, c'e' ben poco da fare.
 S> Devo far capire al CP che per utilizzare quel WS ha bisogno di
 S> implementare della logica per l'invio del file tramite socket.
 S> Quindi quando il CP fa una ricerca nel registro UDDI e scarica il WSDL
 S> del mio WS deve poter avere anche quest'altra informazione.
Anche ammesso che si possa fare, il SOAP non trasmette un file in modo
binario puro e semplice, ma lo incapsula in un messaggio XML e se dall'altra
parte non c'e' un qualcosa in grado di comprendere cosa arriva non andrai
mai da nessuna parte.
 S> Forse per questo problema il WSDL non è d'aiuto o forse servirebbe
 S> qualcos'altro...ma cosa?
Da quello che ho capito il presunto web service e' stato progettato
malissimo e c'e' ben poco da fare. Usi un metodo di trasferimento non
standard, non puoi descriverlo in un protocollo che prevede uno standard ben
preciso.
L'unica alternativa e' aggiungere un secondo web service che si occupi
esclusivamente di fare i trasferimenti di file ricevendoli da un client SOAP
standard, ma se non puoi intervenire sul server non puoi fare nulla.


 ha scritto nel messaggio
news:lCBac.100334$Kc3.3...@twister2.libero.it...


Ciao, SgNaPpO!
Il giorno 31/03/2004 alle ore 17:51 hai scritto:
 S> Pur volendo aggiungere un altro web service "fittizio" che accetti i
 S> file dal CP e poi li invia al WS "vero" (via socket) e quindi aggiungere
 S> un metodo sendFile(), dovrei per forza inviare il file come allegato
 S> SOAP? O ci sono altre possibilità?
Se vuoi essere standard si, poi come ho detto puoi fare come vuoi a patto
che ti scrivi anche tutta la logica che sta dietro ad un protocollo.
Ma qual'e' il problema ad utilizzare un protocollo standard ?


 Bye
Ciao
SgNaPpO

 Hai dei consigli su altri metodi?
ho letto velocemente il proseguo della discussione xche' non ho potuto
seguirla in questi giorni ma mi sa che una possibile alternativa e' 
questa (che e' alla fine uno degli obiettivi di utilizzo dei WS):
costruire un "wrapper" che esponga la funzionalita' del tuo WS
di compressione come web services standard e che
lavori via socket col servizio progettato "male"
In sostanza (che l'ascii art mi venga in aiuto ;))
client
||
|| <comunicazione non so come la vuoi fare, forse WS anche questa?>
||
content provider
||
|| <comunicazione usando UDDI/WSDL/SOAP>
||
ws_wrapper_del_servizio_di_compressione
||
|| <comunicazione tcp/ip su socket ssl>
||
servizio di compressione "old"
ergo ti devi scrivere un wrapper che da una parte usa gli standard
dei web services per parlare col CP (SOAP con attachment + evtl altre
funzioni) e dall'altra usa connex socket ssl per parlare col servizio
di compressione in ascolto sulla porta.
my 2 cent :)