Installazione e configurazione

Transcript

1 Globo srl Soluzioni avanzate per il territorio Viale Europa, 17/B Treviolo (BG) Reg.Impr. di BG - Cod.Fisc. - P.IVA Capitale sociale interamente versato Installazione e configurazione Per conto di: Secoval srl Davide Cremonesi Marco Deligios 28/02/ Redatto Verificato e autorizzato Data d emissione Revisione 10/ /01624 Pagina 1 di 30 Commessa Protocollo

2 Le informazioni contenute in questo documento sono di esclusiva proprietà di Globo srl. Nessuna parte di questo documento può essere riprodotta o trasmessa in qualsiasi forma o con qualsiasi mezzo comprese fotocopia e registrazione, ad eccezione di quanto espressamente consentito da Globo. Prodotti o aziende indicate nel documento possono essere marchi o marchi registrati dei rispettivi proprietari. I dati sono trattati in conformità alla normativa sulla Privacy (D. Lgs. 196 del 2003). Per maggiori informazioni si consulti l informativa sulla Privacy all indirizzo internet Accogliendo la raccomandazione dell Unione Europea nell ambito della certificazione ambientale, che suggerisce di migliorare l'efficienza ambientale di un'impresa consentendole di avere una conoscenza reale degli aspetti ambientali più rilevanti nella propria attività, questo documento è impaginato per essere stampato in modalità fronte e retro. pag. 2 di 30

3 SOMMARIO 0 STORIA DELLE REVISIONI 4 1 SCOPO E CAMPO D APPLICAZIONE Scopo Campo d applicazione 4 2 RIFERIMENTI NORMATIVI 4 3 TERMINI E DEFINIZIONI 4 4 DBT E CTMANAGER 4 5 WEBSERVICES DBT Installazione Configurazione Verifica 6 6 PORTA DI DOMINIO Java Runtime Environment (JRE) JBoss Installazione Configurazione Verifica Postgres Openspcoop Installazione e configurazione Verifica Configurazione della porta di dominio DBT Valle Sabbia Accesso alla console Verifica anagrafica PdD e soggetto erogatore Creazione del soggetto fruitore Impostazione del connettore Creazione del Servizio Applicativo SA_Comune Creazione dell Accordo di Servizio Parte Comune Aggiunta del Servizio Generico all Accordo Azioni del servizio Aggiunta dell Accordo di Servizio Parte Specifica Aggiunta del soggetto fruitore Politiche di sicurezza Aggiunta della Porta Applicativa Aggiunta del Servizio Applicativo Erogatore Impostare i parametri di invocazione del Servizio Applicativo Associare alla Porta Applicativa il Servizio Applicativo Erogatore 26 7 PUBBLICAZIONE DEI SERVIZI Installazione Configurazione Verifica ATTENZIONE 30 8 CLIENT 30 pag. 3 di 30

4 0 STORIA DELLE REVISIONI Rev. Data Redatto Descrizione 1 28/02/2011 Davide Cremonesi Primo rilascio 1 SCOPO E CAMPO D APPLICAZIONE 1.1 Scopo Il presente documento illustra le modalità di installazione e configurazione dei componenti software necessari per la realizzazione della porta di dominio del Database Topografico della Valle Sabbia. Per ciascuna componente applicativa vengono illustrate (ove applicabile) le modalità di installazione, configurazione e verifica del singolo componente (unit test). Il test dell intero progetto (integration test e system test) è invece descritto nel documento di test e collaudo. 1.2 Campo d applicazione Tale documento si applica al contesto del progetto progettazione e prototipizzazione della Porta di Dominio della Comunità Montana della Valle Sabbia. Secondo l offerta di tale progetto, il presente documento è oggetto di consegna. 2 RIFERIMENTI NORMATIVI Non applicabile. 3 TERMINI E DEFINIZIONI PDD SPC WS WSDL XML Porta di Dominio Sistema Pubblico di Connettività Web Service WebService Definition Language extensible Markup Language 4 DBT E CTMANAGER Per gli scopi del presente progetto il prodotto GLOBO CTManager non viene utilizzato direttamente, ma semplicemente si accede (in sola lettura) alla banca dati cartografica (GeoDatabase) contentente il DBT della Valle Sabbia. Nella configurazione prototipale è stato utilizzato un DBT di tipo ESRI File Geodatabase, per cui la banca dati CTManager è stata esportata in tale formato e copiata nell area c:/progetti/secoval/banchedati/pdd_valsabbia/ctmanager.gdb del server SIT-AGS. pag. 4 di 30

5 Tale banca dati è accessibile da qualunque client che supporti il formato ESRI GeoDatabase, ed ovviamente dai prodotti ESRI ArcMap, ArcCatalog, etc.. 5 WEBSERVICES DBT Questa componente espone le funzionalità di esportazione del DBT tramite WebServices realizzati in architettura Microsoft.NET. 5.1 Installazione Poiché le classi che implementano queste funzionalità si appoggiano alle componenti cartografiche di ESRI, l applicazione è stata installata sul server cartografico (SIT-AGS) sul quale era già presente il prodotto ESRI ArcGIS Server Advanced Enterprise. L applicazione.net è stata installata nella cartella del server SIT-AGS: C:\Progetti\Secoval\SW\DBTValsabbia_WS e pubblicata come applicazione dall interfaccia di amministrazione di IIS: 5.2 Configurazione L applicazione legge i suoi parametri dal file di configurazione web.config, in particolare dalla sezione appsettings : <appsettings> <add key="mock" value="false"/> <add key="dbtworkspace" value="c:/progetti/secoval/banchedati/pdd_valsabbia/ctmanager.gdb"/> <add key="shapescratchdir" value="c:/temp"/> </appsettings> La chiave mock, se messa a true, lancia una finta implementazione dei servizi, utili per testare l interfaccia e l integrazione con le componenti della PdD. La chiave dbtworkspace specifica dove si trova il file geodatabase contenente l intera struttura dati del DBT. La chiave shapescratchdir specifica un area temporanea dove vengono creati i files di esportazione prima di essere compressi ed inclusi nella risposta al client. pag. 5 di 30

6 Tale area deve esistere ed essere scrivibile dall utente di sistema con il quale vengono eseguiti i web services. Vi sono poi altre sezioni dove è possibile configurare, ad esempio, il comportamento del log dell applicazione, che seguono logiche standard e spiegate nella documentazione dei componenti specifici (ad esempio log4net). 5.3 Verifica Per verificare l avvenuta installazione e configurazione è possibile aprire un browser internet internamente alla LAN e visualizzare il seguente URL: Se l installazione è avvenuta correttamente allora viene visualizzata la pagina di presentazione dei webservices. Ed in modo analogo è possibile richiamare la specifica formale degli stessi (WSDL): L invocazione dei metodi con strutture dati più semplici può avvenire anche da browser, purchè la connessione avvenga sulla macchina stessa 1, e permette di verificare la correttezza della configurazione: 1 Se si richiamo lo stesso URL da un altra macchina che non sia il server stesso, nella pagina di invocazione di test non sarà possibile invocare un metodo specifico ma apparirà il messaggio The test form is only available for requests from the local machine. pag. 6 di 30

7 In fase di produzione l invocazione diretta dei WebServices non deve essere esposta pubblicamente, ma solamente come Servizio Applicativo Erogatore (privato) della Porta Applicativa del domino dell ente erogatore: è proprio questo il principio fondamentale della Porta di Dominio ( Ogni porta di dominio a livello concettuale funge da proxy per l'accesso alle risorse applicative che si trovano all'interno dello stesso dominio ). 6 PORTA DI DOMINIO Data l importanza della componente e la sua centralità per il progetto, le componenti della porta di dominio sono state installate su di un server virtuale dedicato (SIT-PDD). Come illustrato nel documento di architettura e specifiche funzionali, la porta di dominio è stata implementata utilizzando il prodotto OpenSPCoop, disponibile (insieme ad una ricca ed accurata documentazione a cui si rimanda per i dettagli) all indirizzo Questo capitolo documenta le procedure necessarie per la realizzazione di alcuni scenari tipici di Cooperazione Applicativa in ambiente OpenSPCoop, illustrando sia la configurazione della Porta di Dominio OpenSPCoop, sia lo sviluppo di servizi applicativi compatibili con i diversi profili di egovernment analizzati. La figura seguente mostra le entità che collaborano nell interazione tra due servizi applicativi in accordo allo standard SPCoop. Nel caso specifico l ente erogatore è il CST Secoval, mentre l ente fruitore è stato configurato genericamente come COMUNE. pag. 7 di 30

8 Nella figura proposta sono identificabili i due domini che intendono scambiare messaggi tra i rispettivi Servizi Applicativi. Le Porte di Dominio fanno da interfaccia pubblica a tali servizi, comunicando tra loro tramite messaggi in accordo alle specifiche e-gov. Per la messa in opera del prototipo applicativo si è dapprima proceduto all installazione standard (binary release) di OpenSPCoop. Una volta completata correttamente si è verificato che i servizi della porta di dominio, PD, PA e IntegrationManager, fossero raggiungibili ed è stato configurato l accesso all interfaccia di gestione web pddconsole per la configurazione della Porta di Dominio. Si noti che per semplificare la realizzazione del prototipo ed evitare di dover installare una seconda porta di dominio o creare numerosi soggetti cooperanti, si è scelto di utilizzare due soggetti, uno erogatore e l altro fruitore, gestiti entrambi dalla medesima porta di dominio (modalità loopback). Il fatto di realizzare gli esempi utilizzando la medesima porta di dominio in fruizione ed erogazione è un dettaglio trascurabile che non modifica sostanzialmente il modus operandi nel caso in cui fruitore ed erogatore fossero appartenenti a domini distinti con Porte di Dominio distinte. Per quanto riguarda i soggetti cooperanti si utilizzeranno come esempio: SPC/SECOVAL, che rappresenta il CST Secoval, gestore centrale dei servizi di esportazione (soggetto erogatore) SPC_Comune, che rappresenta un generico Ente che richiede dei servizi di esportazione (soggetto fruitore) Assumendo che JBoss sia stato installato e configurato per ascoltare le richieste sulla porta http di default (80), l indirizzo di ricezione delle buste egov della porta di dominio risulta uguale a: Essendo i due soggetti entrambi interni al dominio, possiamo assumere che questa url corrisponda al loro connettore. 6.1 Java Runtime Environment (JRE) 5.0 Installata la versione 1.5.0_22 da installer windows in: C:\Java\jdk1.5.0_22 pag. 8 di 30

9 in modalità completa. 6.2 JBoss Installazione L applicativo è stato installato nella cartella C:\jboss GA del server SIT-PDD Configurazione JBoss viene utilizzato con la configurazione di default, salvo la porta di ascolto http che per comodità è stata configurata direttamente sul valore 80, visto che la funzione di web server (e proxy) non viene svolta dallo stesso server. La porta del connettore ajp13 è stata lasciata invariata (8009). Il valore viene impostato nel file C:\jboss GA\server\default\deploy\jboss-web.deployer\server.xml ed in particolare nella sezione: <Connector port="80" address="${jboss.bind.address}" maxthreads="250" maxhttpheadersize="8192" emptysessionpath="true" protocol="http/1.1" enablelookups="false" redirectport="8443" acceptcount="100" connectiontimeout="20000" disableuploadtimeout="true" /> Verifica Una volta installato e configurato JBoss la sua console di amministrazione e monitoraggio è accessibile alla URL root del server ( : pag. 9 di 30

10 6.3 Postgres E stata installata la versione binaria 8.4 per Windows, esattamente: postgresql windows sotto il percorso: pag. 10 di 30

11 C:\PostgreSQL\8.4 L installazione crea anche un utente di sistema postgres con il quale viene lanciato il servizio di windows. Parametro Utente root Password Valore postgres postgres Insieme al motore DB è stato installato anche il programma di amministrazione del database PGAdminIII (versione ), utile per accedere direttamente alle tabelle del database ed effettualre query personalizzate. Si noti che, comunque, per la configurazione della porta di dominio tutte le operazioni sono eseguite direttamente dall interfaccia di amministrazione web (pddconsole) di openspcoop. 6.4 Openspcoop Installazione e configurazione Prima di procedere con l installazione di OpenSPCoop 1.3 è stato necessario installare e configurare il software di base sul server SIT-PDD. Tutti i dettagli sono disponibili nella guida di installazione fornita con il prodotto, i particolari riferiti alla presente installazione sono stati riportati nei paragrafi precedenti. Dalla cartella in cui è stata scompattata la binary release OpenSPCoop 1.3 (C:/openspcoop-pdd-1.3.4) è stato lanciato il comando install.cmd che ha avviato la procedura di installazione. Come cartella di lavoro è stata impostata la cartella c:\openspcoop pag. 11 di 30

12 Il database è stato configurato per utilizzare il db server postgres locale con nome, username e password di default. Procedendo con l installazione, i dialoghi hanno confermato che le operazioni sono andate a buon fine: Una volta eseguito l installer sono stati eseguiti i seguenti passi: 1) E stato creato un utente sul db postgres con i medesimi valori indicati sopra 2) E stato creato un database con il medesimo nome indicato sopra e con privilegi tali che l utente creato al punto precedente abbia diritti di scrittura e lettura. 3) E stato eseguito lo script C:\openspcoop-pdd-1.3.4\dist\sql\OpenSPCoop.sql per la creazione dello schema del database. 4) E stato copiato il file C:\openspcoop-pdd-1.3.4\dist\datasource\openspcoop-ds.xml contenente la definizione del datasource, nella directory di deploy di JBoss <JBOSS_HOME>/server/default/deploy 5) E stato copiato il file archivio dell applicazione C:\openspcoop-pdd-1.3.4\dist\OpenSPCoop.ear nella directory di deploy di JBoss (<JBOSS_HOME>/server/default/deploy). pag. 12 di 30

13 6.4.2 Verifica Una volta avviato JBoss, i servizi della porta di dominio sono raggiungibili via browser, digitando gli URL seguenti: che visualizzano la pagina di presentazione dei servizi: Anche l applicazione Web per la gestione della porta di dominio è accessibile tramite browser all indirizzo che presenta la form di login: L utente di default amministratore ha accesso a tutte le funzionalità, tranne la gestione utenti riservata all utente super. La password di questi due utenti è stata modificata dal valore di default(secret) ad un valore personalizzato (secret$secoval). A questo punto è stato possibile configurare tramite questa interfaccia di amministrazione tutti gli aspetti specifici della porta di dominio per l esposizione del DBT della Valle Sabbia. 6.5 Configurazione della porta di dominio DBT Valle Sabbia Le operazioni descritte in questo paragrafo forniscono entità (soggetti, servizi...) utili per tutti i profili di collaborazione che verranno configurati successivamente Accesso alla console La configurazione del registro dei servizi avviene attraverso l interfaccia web di gestione pddconsole. Per prima cosa è necessario autenticarsi con diritti di amministratore: Nome Login Password Valore Amministratore secret$secoval pag. 13 di 30

14 6.5.2 Verifica anagrafica PdD e soggetto erogatore In fase di installazione viene generata l anagrafica della Porta di Dominio interna e gestita tramite la console, visibile selezionando la voce Elenco nella sezione Porte di Dominio : I soggetti associati al proprio dominio saranno associati a questa PdD. Sempre durante l installazione è stato creato un soggetto SPCoop di default, SPC/SECOVAL associato alla PdDSECOVAL (di cui si è detto al punto precedente): Creazione del soggetto fruitore Il soggetto fruitore deve essere invece creato; non essendo noto in questo momento alcun vero fruitore del sistema, utilizzeremo un nome generico COMUNE. a) Selezionare aggiungi nel menù Soggetti SPCoop b) Inserire i parametri del soggetto fruitore nella form e premere invia pag. 14 di 30

15 ed ora i soggetti nell elenco sono due: Impostazione del connettore Ora bisogna impostare il connettore, cioè l indirizzo della porta di dominio per la ricezione delle richieste indirizzate ad un determinato soggetto. Poiché negli scenari implementati le richieste sono sincrone e oneway, l unico soggetto che riceve richieste è il soggetto SPCoop SECOVAL. Dalla lista dei soggetti selezionare visualizza relativamente alla riga del soggetto SECOVAL in corrispondenza della colonna connettore. Selezionare la checkbox Abilitato ed inserire il valore dell URL [ pag. 15 di 30

16 Salvare con il bottone Invia Creazione del Servizio Applicativo SA_Comune Il Servizio Applicativo SA_COMUNE sarà utilizzato per l integrazione del client fruitore. Selezionare aggiungi nel menu Servizi Applicativi ed inserire i valori nella form: e premere Invia. pag. 16 di 30

17 6.5.6 Creazione dell Accordo di Servizio Parte Comune La creazione dell Accordo di Servizio Parte Comune avviene utilizzando i descrittori (WSDL) rilasciati insieme all applicazione Servizio Applicativo Erogatore (par. 5). Dal server SIT-PDD i files sono accessibili sul path \\sit-ags\c$\progetti\secoval\sw\dbtvalsabbia_ws\configurazionepdd Selezionare aggiungi nel menu Accordi Servizio Parte Comune ed inserire i vari parametri dell Accordo: Ottenendo così: pag. 17 di 30

18 6.5.7 Aggiunta del Servizio Generico all Accordo Ora bisogna aggiungere il Servizio Generico all Accordo: il nome del servizio dovrà avere lo stesso nome del PortType indicato nel WSDL Concettuale, ovvero DBTValsabbiaSoap. Dalla lista degli Accordi di Servizio Parte Comune, selezionare visualizza nella colonna servizi in corrispondenza dell Accordo appena creato. Selezionare aggiungi e completare la form per l aggiunta di un nuovo servizio. Premere Invia per salvare. pag. 18 di 30

19 Verrà visualizzato l elenco dei servizi dell accordo; Azioni del servizio Ora dobbiamo specificare le Azioni del Servizio: le azioni del Servizio corrispondono alle Operation specificate nel WSDL, ovvero: getlistaclassidbt getlistaporzioneterritoriorestituito getlistaareetrasformate getdaticompleti getdatiaggiornamentoptr getdatiaggiornamentoat getdiztipologiaarea getdizqualitaarea getdizstatoarea helloworld getversione La configurazione è identica per ciascuna Azione, poiché tutte sono state implementate con il paradigma sincrono. Nel seguito viene illustrata la configurazione dell azione getlistaclassidbt. Dalla riga corrispondente al servizio appena creato selezionare visualizza nella colonna Azioni, poi selezionare Aggiungi e completare la form per l aggiunta di una nuova azione. pag. 19 di 30

20 E premere Invia. Nota bene. Secondo le specifiche di interscambio, bisognerebbe creare un azione distinta in corrispondenza di ciascuna port-type nel wsdl logico erogatore e di ciascun profilo di collaborazione, con esattamente lo stesso nome. Poiché in questo prototipo tutte le azioni sono erogate in modalità sincrona, tutte le chiamate posso essere instradate attraverso la stessa azione: in questo caso quindi la action sarà sempre getlistaclassidbt, mentre nel protocollo SOAP verrà specificata la port corretta Aggiunta dell Accordo di Servizio Parte Specifica. Nella sezione Accordi Servizio Parte Specifica selezionare Aggiungi. Inserire i parametri della parte specifica nella form: pag. 20 di 30

21 E premere Invia Aggiunta del soggetto fruitore Ora bisogna aggiungere il soggetto fruitore (il comune) alla lista dei soggetti che possono fruire del servizio: l installazione standard di OpenSPCoop attiva di default l autorizzazione SPCoop che attiva il controllo da parte della porta applicativa che il soggetto che invoca il servizio sia un fruitore autorizzato. Per superare questo controllo dobbiamo aggiungere il soggetto COMUNE ai fruitori del servizio DBTValsabbiaSoap. Nell elenco degli Accordi di Servizio Parte Specifica individuare DBTValsabbiaSoap e selezionare visualizza nella colonna Adesioni; selezionare Aggiungi ed utilizzare la form per inserire i parametri del soggetto fruitore del servizio: E premere invia. pag. 21 di 30

22 L operazione appena effettuata comporta la creazione automatica di una porta delegata associata al soggetto fruitore appena aggiunto. La porta delegata viene inizializzata con dei valori di default che vanno bene in molti casi. Se si vogliono modificare tali impostazioni si deve procedere con la modifica della porta delegata individuabile nella lista per ciascun soggetto SPCoop. La URL completa per l invocazione della porta delegata sarà: Politiche di sicurezza Aggiungere nelle politiche di sicurezza il servizio applicativo che si vuole autorizzare all invocazione del servizio. Questo passaggio riguarda l autorizzazione del servizio pag. 22 di 30

23 applicativo fruitore all invocazione della porta delegata generata al passo precedente. Dall elenco fruitori del del servizio, in corrispondenza del soggetto COMUNE, nella colonna politiche sicurezza selezionare visualizza e quindi il pulsante Aggiungi. Compilare il form selezionando il servizio applicativo SA_COMUNE dalla lista a discesa e confermando con il pulsante Invia. L operazione descritta in questo passaggio creerà automaticamente un associazione tra il servizio applicativo e la porta delegata creata automaticamente al passo precedente. pag. 23 di 30

24 Aggiunta della Porta Applicativa L ultima operazione necessaria è l aggiunta al soggetto erogatore (SPC/SECOVAL) della Porta Applicativa che si occuperà della consegna delle richieste applicative verso il servizio applicativo erogatore. Dalla lista soggetti SPCoop, in corrispondenza al soggetto SECOVAL, nella colonna Porte Applicative, selezionare visualizza e cliccare sul pulsante aggiungi. Inserire nella form i parametri della Porta Applicativa per il soggetto SECOVAL e premere Invia Aggiunta del Servizio Applicativo Erogatore Dal menu servizi applicativi selezionare Aggiungi pag. 24 di 30

25 Compilare la form con i parametri per la creazione del Servizio Applicativo e premere Invia Impostare i parametri di invocazione del Servizio Applicativo Abilitare l invocazione del servizio SA_DBTValsabbia dall elenco dei Servizi Applicativi (selezionare disabilitato nella colonna Invocazione Servizio). Inserire nella form i parametri del servizio applicativo; l URL è quella del servizio applicativo installato come descritto al capitolo 5, ovvero pag. 25 di 30

26 e premere Invia Associare alla Porta Applicativa il Servizio Applicativo Erogatore Dall elenco dei Soggetti SPCoop visualizzare la Porta Applicativa associata al soggetto SPC/SECOVAL. Selezionare PA_DBTValsabbia e quindi selezionare visualizza in corrispondenza alla colonna Servizi Applicativi e premere il bottone Aggiungi. Selezionare il servizio applicativo creato in precedenza pag. 26 di 30

27 e premere il pulsante Invia. A questo punto la configurazione è completata ed è possibile invocare i servizi della Porta di Dominio SPCSECOVAL dalla Porta di Dominio SPCCOMUNE. Il diagramma dell intero flusso di messaggistica è illustrato dalla figura seguente. 1) Il Servizio Applicativo del fruitore invoca via SOAP un servizio della Porta Delegata del proprio dominio 2) La PdD del fruitore imbusta la richiesta e la invia alla PdD dell erogatore, tramite il protocollo di buste egov. 3) La PdD dell erogatore, tramite la propria PA, invoca via SOAP il servizio applicativo che implementa l azione richeista 4) e riceve la risposta 5) La risposta viene spedita, sempre tramite buste di egov, alla PdD del fruitore 6) ed infine arriva al Servizio Applicativo da cui era partita la richiesta. Ovviamente il passaggio sulla rete pubblica è simulato, poiché il prototipo è stato realizzato in modalità loopback. pag. 27 di 30

28 7 PUBBLICAZIONE DEI SERVIZI Data la natura prototipale del progetto i servizi non sono stati pubblicati sulla rete del sistema pubblico di connettività (SPC, ex RUPA) ma semplicemente su internet (le modalità di connessione sono identiche, tranne che per la configurazione della rete sottostante). 7.1 Installazione Non è stato installato alcun componente aggiuntivo, essendo già presente il Web Server Apache 2.2 con il modulo mod_proxy. 7.2 Configurazione Per esporre i servizi su internet è stato creato un dominio di terzo livello (pdd.secoval.it) sul DNS ed indirizzato al server Web pubblico (SIT-WEB) di Secoval. Sul server SIT-WEB ascolta un Web Server Apache 2.2 configurato con una direttiva virtual host basata sul nome che trasferisce le chiamate (tramite il protocollo AJP13 del modulo mod_proxy) al server SIT_PDD (sull indirizzo interno e sulla porta 8009 di JBoss). Si riporta il contenuto del file C:/Program Files/ApacheGroup/conf/extra/httpd-vhostspdd.conf evidenziando le parti necessarie: <VirtualHost *:80> ServerName pdd.secoval.it DocumentRoot "C:/temp" <Directory "C:/temp"> Options Indexes MultiViews AllowOverride All Order allow,deny Allow from all </Directory> ProxyPass /pddconsole ajp:// :8009/pddconsole ProxyPass /openspcoop ajp:// :8009/openspcoop </VirtualHost> ProxyPass / Verifica Aprendo il browser all indirizzo si accede in modo trasparente all application server JBoss della macchina SIT_PDD. pag. 28 di 30

29 Aprendo invece il seguente URL si accede alla console di amministrazione: Ed infine, i servizi della porta di domino sono disponibili a partire dal base URL ad esempio la porta delegata di loopback 2 : 2 Il messaggio d errore è normale perché il metodo di invocazione del servizio passa attraverso altri meccanismi e non da una semplice richiesta http di tipo GET. La schermata conferma comunque la corretta configurazione dei filtri proxy. pag. 29 di 30

30 7.3.1 ATTENZIONE In fase di produzione l accesso diretto dall esterno all application server ed alla console non dovrebbe essere possibile; in tal caso basta rimuovere o modificare in modo opportuno le regole di inoltro (ProxyPass) per impedirne l accesso (per cui saranno visibili solo con i riferimenti diretti alle macchine della LAN). 8 CLIENT Dal punto di vista applicativo, una volta configurato all interno del dominio dell ente fruitore la Porta Delegata per comunicare con la Porta Applicativa di Secoval, l invocazione dei servizi esposti avviene in modo trasparente, semplicemente invocando i webservices della PD tramite il protocollo SOAP. Il client può essere perciò implementato in modo standard con gli strumenti disponibili nel linguaggio di programmazione preferito, ad esempio: Java: Apache Axis, Apache CXF, Xfire.NET: funzioni native di Visual Studio (add Web reference) PHP5: SoapClient, nusoap Javascript: jquery SOAP Client plugin pag. 30 di 30