On Thu, 2007-02-08 at 12:54 +0100, Domenico Loiacono wrote:
> Nel documento "Guida Utente Porta di Dominio OpenSPCoop, vers. 0.8" al
> paragrafo "5.1 – Modalità d'integrazione trasparente" è descritta la
> modalità proxy di utilizzo della porta in linea con quanto riportato
> anche nei documenti CNIPA di specifica delle Porte di Dominio
> (capitolo 4 - "SPCoop-PortaDominio_v1.0_20051014.doc").
> Nella modalità proxy, la Porta di Dominio dovrebbe fungere da
> intermediario tra due attori di domini differenti, un erogatore e un
> fruitore, fornendo tutte le funzionalità richieste dal Sistema
> Pubblico di Cooperazione.
Questo e' comunque il compito della porta di dominio, indipendentemente
da come si realizzi il componente di integrazione. In realta' la
specifica SPCoop non entra nel merito del componente di integrazione
(cioe' di come le applicazioni debbano interagire con porte delegate e
applicative). L'unico esempio riguarda una potenziale libreria da usare
per scrivere componenti di integrazione. Lo trovi nella sezione 4.1.1
del Documento sulla Porta di Dominio SPC, riferita come "Interfaccia
SA"
(http://www.openspcoop.org/openspcoop/rep/SPCoop-PortaDominio_v1.0_20051014.pdf).
Si tratta di qualcosa di piu' simile al servizio di IntegrationManager
di OpenSPCoop che non alla modalita' trasparente. La modalita'
trasparente e' invece una peculiarita' di OpenSPCoop, progettata
appositamente per ridurre drasticamente i costi di sviluppo dei
componenti di integrazione, che tipicamente venivano programmati come
applicazioni ad-hoc. Trovi maggiori dettagli su questo sull'articolo di
Esperta pubblicato sul sito.
> ...
> I test condotti sull'utilizzo della porta di dominio OpenSPCoop in
> modalità proxy, hanno sollevato però alcuni dubbi sulla modalità di
> integrazione rispetto a quanto ipotizzato.
>
> In particolare in contesti applicativi in cui è definita una politica
> di sicurezza per cui è richiesto lo scambio di token di
> autenticazione/autorizzazione all'interno di messaggi soap attraverso
> header WS-Security, i test hanno evidenziato un blocco dei messaggi
> sulla porta delegata in quanto la stessa ne ha tentato
> l'interpretazione.
L'uso di WS-Security da parte della PdD OpenSPCoop non va in conflitto
con quello delle applicazioni, perche' usano Actor diversi per l'header
WS-Security di SOAP. Dovresti riportare il problema specifico che hai
incontrato, per poterne analizzare le cause.
> In altri test l'integrazione della Porta di Dominio OpenSPCoop in
> contesti applicativi in cui si ipotizza l'uso di standard di
> messaggistica quali SOAP 1.2 ha portato al blocco dei messaggi
> scambiati poiché il protocollo utilizzato dall'implementazione della
> porta di dominio è SOAP 1.1.
La specifica SPCoop prevede esplicitamente l'aderenza della Porta di
Dominio a SOAP 1.1 (Requisito PD_UR-17, vedi specifica della Porta di
Dominio). Quindi, questo e' effettivamente un vincolo che anche le
applicazioni interne dovrebbero rispettare. Nel caso si sia sicuri che
le PdD coinvolte nell'interazione supportino 1.2, si potrebbe
configurare le porte per usare SOAP 1.2, in modo da poter gestire
correttamente situazioni come quelle che riferisci. Metteremo un'opzione
apposita nella prossima versione della Porta, anche se il default deve
necessariamente restare 1.1 fino all'eventuale aggiornamento della
specifica SPCoop.
> Sembrerebbe quindi che pur utilizzando le Porte di Dominio in modalità
> proxy, debbano essere rispettati dei vincoli che impattano sulle
> specifiche e il disegno dei servizi applicativi.
> E' questa una visione condivisibile ? Quanto e sotto quali condizioni
> OpenSPCoop sarà realmente trasparente all'integrazione dei servizi
> applicativi?
Siamo fiduciosi che possa essere completamente trasparente. Tra l'altro
questo e' un comportamento naturale per il protocollo SOAP e in generale
per le architetture SOA, in cui router applicativi che fungano da
intermediari (esattamente quello che fanno le Porte di Dominio) sono
esplicitamente previsti sui percorsi tra mittente e destinatario.
> Se ad esempio la porta di dominio operasse come provider a livello di
> trasporto (HTTP) piuttosto che come servizio web a livello di
> messaggio (SOAP) alcuni dei vincoli sopra esposti potrebbero cadere?
> (riferimento ad esempio ai Provider JAX-WS).
Un tunnel di SOAP 1.2 su SOAP 1.1 dovrebbe sempre essere possibile,
magari tramite una nuova opzione sulle porte delegate e applicative per
trasformare la busta SOAP originale in un attachment della busta eGov
1.1 e viceversa.
Qualche commento sulla possibilita' di tunnelling SOAP 1.2 su 1.1 dagli
esperti SOAP in lista?
tito.
|