Scenario e vantaggi di utilizzo di OpenSPCoop PdD

Nell’esempio illustrato nel paragrafo 3.5.2, viene illustrato l’utilizzo della libreria e- Gov attraverso la definizione di un Proxy Delegato e di un Proxy Applicativo specifico per il contesto descritto. Ogni proxy deve essere costruito appositamente per gestire il proprio servizio, e deve utilizzare la libreria org.openspcoop.egov per costruire, validare e sbustare buste e-Gov. La complessità della specifica e-Gov è in mano all’implementatore dei proxy, e deve essere rivista ogni qualvolta si volesse definire un nuovo proxy delegato o un nuovo proxy applicativo. La Figura 3-14 illustra come sia necessario implementarsi completamente la logica di un nuovo proxy delegato, se il contesto necessita di un nuovo soggetto (SIL3) che possa richiedere un servizio erogato dal solito SIL2.

3. Implementazione del prodotto OpenSPCoop 192 Con la porta di dominio OpenSPCoop è possibile ‘ignorare’ le complesse e difficili

implementazioni dei proxy, dato che la implementazione di una porta delegata, o di una porta applicativa può essere effettuata semplicemente definendo qualche riga di codice XML. Non servirà quindi più la figura di un programmatore che con diverse centinaia di ore-uomo implementa un proxy applicativo specifico per il contesto. Lo scenario, illustrato dalla precedente Figura 3-14, attraverso la porta di dominio OpenSPCoop, evolve nella maniera descritta dalla Figura 3-15.

Figura 3-15, Scenario di utilizzo del prodotto OpenSPCoop PdD

Per evidenziare i vantaggi che comporta l’utilizzo di OpenSPCoop, esaminiamo lo stesso scenario d’uso, illustrato nel paragrafo 3.3.2, dove un client, vuole spedire un messaggio Soap (contenente dati applicativi) ad un Server. La spedizione non è più mediata da un proxyDelegato specifico ma dalla porta di dominio OpenSPCoop (in particolare da una porta delegata apposita), con cui il Client è forzato a dialogare. Anche il servizio offerto dal server è mediato da una porta applicativa configurata nella porta di dominio destinataria. Il server, ricevuti i dati dal cliente, genera una risposta applicativa che dovrà essere restituita al client sempre dietro la mediazione delle porte di dominio. La Figura 3-16 illustra il nuovo scenario.

3. Implementazione del prodotto OpenSPCoop 193

Figura 3-16, Scenario di utilizzo del paragrafo 3.3.2 evoluto con il prodotto OpenSPCoop

L’installazione dello scenario descritto non richiede più diverse centinaia di righe di codice specifico per il contesto, come specificato nel paragrafo 3.3.2, ma semplicemente la definizione di tre file XML, due per la configurazione di una porta delegata ed una porta applicativa, ed uno per la configurazione del registro dei servizi.

Il file di configurazione necessario alla configurazione della porta delegata e alla gestione dell’autorizzazione del SIL1 è il seguente (questo file di configurazione viene letto dalla porta di dominio A):

<openspcoop xmlns="http://www.openspcoop.org/pdd/config/xml"

xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xsi:schemaLocation=

"http://www.openspcoop.org/pdd/config/xml config.xsd"> <porta_delegata url="ServiceExample" tipo="static">

<service_provider tipo="SPC">Server</service_provider> <servizio tipo="SPC">Xmethods</servizio>

<azione>Get</azione>

<sil_mittente>SIL_1</sil_mittente>

</porta_delegata> <sil>

<principal>SIL_1</principal>

<authentication tipo="HTTP-BASED" password="123456" /> <provider tipo="SPC">MittenteDiProva</provider>

</sil>

3. Implementazione del prodotto OpenSPCoop 194 Il file di configurazione necessario, invece alla configurazione della porta

applicativa è il seguente (questo file di configurazione viene letto dalla porta di dominio B): <openspcoop xmlns="http://www.openspcoop.org/pdd/config/xml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://www.openspcoop.org/pdd/config/xml config.xsd"> <porta_applicativa>

<service_provider tipo="SPC">Server</service_provider> <servizio tipo="SPC">Xmethods</servizio>

<azione>Gec</azione>

<consegna> <http url="http://64.124.140.30/soap " sbustamento_soap="false" /> </consegna> </porta_applicativa> </openspcoop>

Inoltre dovrà essere creato un registro dei servizi di OpenSPCoop, dove è possibile specificare le funzionalità SPCoop da associare al servizio. Un semplice cambio di qualche opzione, modificherà facilmente il tipo di buste scambiate tra le porte di dominio. Il file di configurazione del registro dei servizi per questo scenario è il seguente: <registro_servizi xmlns="http://www.openspcoop.org/uddi/xmlregistry" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openspcoop.org/uddi/xmlregistry registroServizi.xsd"> <porta_applicativa>

<service_provider tipo="SPC">Server</service_provider>

<servizio valore="Xmethods">

<tipo_servizio valore="SPC" /> </servizio>

<default utilizzo_senza_azione="false">

<azioni_permesse valore="Get" />

<profilo_asincrono_asimmetrico utilizzo="false" /> <profilo_asincrono_simmetrico utilizzo="false" /> <profilo_sincrono utilizzo="true" />

<profilo_oneway utilizzo="false" /> <collaborazione utilizzo="false" /> <ordine_consegna utilizzo="false" />

<inoltro_senza_duplicati utilizzo="true" /> <conferma_ricezione utilizzo="true" />

</default> </porta_applicativa> <identificativo_parte> <service_provider tipo="SPC"> MittenteDiProva </service_provider>

<id_porta_di_dominio>PisaLinkSPCoopIT</id_porta_di_dominio>

3. Implementazione del prodotto OpenSPCoop 195 <identificativo_parte>

<service_provider tipo="SPC">Server</service_provider> <id_porta_di_dominio>PisaLinkSPCoopIT</id_porta_di_dominio>

</identificativo_parte> <porta_di_dominio>

<id>PisaLinkSPCoopIT</id> <end_point>http://localhost:8080/axis/services/OpenSPCoop_PA</ end_point> </porta_di_dominio> </registro_servizi>

Il tempo speso per la configurazione di questi file XML è pochissimo, ma sufficiente per implementare lo stesso scenario di utilizzo illustrato nel paragrafo 3.3.2.