Casi d`uso - OSCAT

SuapFD
SuapFD
SUAP
20/01/2012
SuapFD
Sommario
Sommario ....................................................................... 1
Descrizione del sistema .................................................. 3
Attori............................................................................... 4
Profili applicativi ............................................................. 4
Macrofunzionalità .......................................................... 4
Funzionalità .................................................................... 4
Componenti utilizzate, stack tecnologico....................... 6
Architettura del sistema ................................................. 8
Architettura logica .......................................................... 8
Modello dati ................................................................... 9
Deployment diagram logico ......................................... 10
Casi d’uso...................................................................... 10
Diagramma UC.............................................................. 11
Caso d’uso 1 – richiedi attributi.................................... 12
Descrizione del caso d’uso ............................................ 12
Sequence Diagram........................................................ 13
Esempio di richiesta ...................................................... 13
Esempio di risposta ....................................................... 13
Caso d’uso 2 – richiedi valore attributi per CF ............. 14
Descrizione del caso d’uso ............................................ 14
Sequence Diagram........................................................ 15
Esempio di richiesta ...................................................... 16
Esempio di risposta ....................................................... 16
Caso d’uso 3 – notifica variazione attributi .................. 17
20/01/2012
1
SuapFD
Descrizione del caso d’uso ............................................ 17
Sequence Diagram........................................................ 18
Esempio di richiesta ...................................................... 19
Esempio di risposta ....................................................... 20
20/01/2012
2
SuapFD
Descrizione del sistema
L’applicazione SuapFD è il sistema di
certificazione ruoli per quanto riguarda
gli operatori e gli esperti SUAP.
Il SuapFD coopera via CART per mezzo
delle RFC 146 e 156 con il Role Manager
dell’infrastruttura ARPA.
Di fatto il sistema realizza una componente di service integration che svolge una business unit
work specializzata e distribuita facente parte della funzionalità di business del Role Manager di
certificazione ruoli.
Il SuapFD implementa sia i servizi di richiesta attributi e richiesta valore attributi per codice
fiscale (RFC 146) che il client per l’interrupt da fonte dati (RFC 156) per entrambe le categorie
di utenti che devono essere certificati. Di fatto abbiamo: la fonte dati operatori SUAP (FDOS) e
la fonte dati esperti SUAP (FDES).
Poiché le fonti dati espongono lo stesso contratto, per quanto riguarda la RFC 146, e scambiano
la stessa tipologia di messaggi, il sistema è stato implementato come un sistema multi-service
con un dispatcher in grado di intercettare qual è il servizio richiesto.
In maniera analoga, il client che colloquia con il Role Manger e che implementa la RFC 156
risulta essere solamente uno; a seconda degli attributi che sono stati modificati che
appartengono a una fonte dati, la variazione viene veicolata utilizzando un account di fruizione
piuttosto che un altro.
Lo schema dati del SuapFD modella i dati relativi agli attributi del Ruolo che certifica e al valore
che essi assumono per lo specifico codice fiscale dell’utente. A loro volta gli attributi vengono
collegati alla corrispettiva fonte dati per mezzo di alias; per ogni fonte dati si ha un legame con
la spettante istanza di interrupt da fonte dati.
20/01/2012
3
SuapFD
Attori
Entrambi gli attori coinvolti sono sistemi informatici.
Role Manager
Il Role Manager di ARPA fruisce via CART mediante RFC 146 i servizi erogati dal SuapFD per le
fonti dati FDES e FDOS .
SuapFD
Il SuapFD fruisce via CART mediante RFC 156 il servizio di ricezione interrupt da fonte dati per le
fonti dati FDES e FDOS.
Profili applicativi
Il SuapFD non necessita di profilatura applicativa poiché eroga servizi applicativi e a sua volta
fruisce servizi. La modalità di fruizione è via CART in basic authentication .
Macrofunzionalità
1.
Richiesta attributi gestiti dalla fonte dati
2.
Richiesta valore attributi per specifico codice fiscale
3.
Notifica variazione valore attributo
Le funzionalità si attivano con profilo sincrono , l’invio della richiesta e della risposta non sono
citate nella tabella a seguire.
Funzionalità
nome
descrizione
Fonte dati
FDES
FDOS






Richiesta attibuti – checkRequest
validazione della request
Richiesta attibuti – getAttributes
recupero attributi dal db
Richiesta attibuti – buildResponse
costruzione della risposta da inviare al Role Manager
20/01/2012
4
SuapFD
Richiesta valore attibuti CF – checkRequest


















validazione della request
Richiesta valore attibuti CF – getAttributesValues
recupero valori attributi dal db per codice fiscale
Richiesta valore attibuti CF – buildResponse
costruzione della risposta da inviare al Role Manager
Richiesta valore attibuti CF – checkResponse
validazione della response
Notifica variazione valore attributo – getToSend
recupero degli attributi che devono essere trasmessi dal db
Notifica variazione valore attributo – buildResponse
costruzione della risposta da inviare al Role Manager
Notifica variazione valore attributo – checkResponse
validazione della response
Notifica variazione valore attributo – putVarizione
invio della notifica al Role Manager
Notifica variazione valore attributo – updateTrasmesso
I'aggiornamento delle notifiche in stato trasmesso
20/01/2012
5
SuapFD
Componenti utilizzate, stack tecnologico
Hibernate è una piattaforma middleware open source per lo sviluppo di applicazioni Java che
fornisce un servizio di Object-relational mapping (ORM), ovvero che gestisce la rappresentazione
e il mantenimento su database relazionale di un sistema di oggetti Java.
Lo scopo principale di Hibernate è quello di fornire un mapping delle classi Java in tabelle di un
database relazionale; sulla base di questo mapping Hibernate gestisce il salvataggio degli oggetti
di tali classi su database. Si occupa inoltre del reperimento degli oggetti da database,
producendo ed eseguendo automaticamente le query SQL necessarie al recupero delle
informazioni e la successiva reistanziazione dell'oggetto precedentemente "ibernato" (mappato
su database).
L'obiettivo di Hibernate è quello di esonerare lo sviluppatore dall'intero lavoro relativo alla
persistenza dei dati. Hibernate si adatta al processo di sviluppo del programmatore, sia se si
parte da zero sia se da un database già esistente. Hibernate genera le chiamate SQL e toglie lo
sviluppatore dal lavoro di recupero manuale dei dati e dalla loro conversione, mantenendo
l'applicazione portabile in tutti i database SQL.
Hibernate è tipicamente usato in applicazioni Java EE facenti uso di servlet o EJB session beans.
Axis2 è una piattaforma middleware open source per lo sviluppo di web services che supporta
tutti gli standard dei web-services come :










WS - ReliableMessaging - Via Apache Sandesha2
WS - Coordination - Via Apache Kandula2
WS - AtomicTransaction - Via Apache Kandula2
WS - SecurityPolicy - Via Apache Rampart
WS - Security - Via Apache Rampart
WS - Trust - Via Apache Rampart
WS - SecureConversation - Via Apache Rampart
SAML 1.1 - Via Apache Rampart
SAML 2.0 - Via Apache Rampart
WS - Addressing - Module included as part of Axis2 core
Inoltre implementa /supporta una serie di features come :








Speed – Via StAX (Streaming API for XML)
Low memory foot print
AXIOM
Hot Deployment
Asynchronous Web services
MEP Support
Stability
Component-oriented Deployment
20/01/2012
6
SuapFD



Transport Framework
WSDL support – version 1.1 e 2.0
Composition and Extensibility
Quartz è una libreria Open Source che permette di schedulare Job (processi) scritti in Java, e
può essere utilizzata in qualsiasi applicazione Java sia di tipo Enterprise (J2EE) che stand alone
(J2SE). L’esecuzione di un Job avviene quando il Trigger ad esso associato scatta. E’ possibile
creare dei Trigger che scattino all’accadere delle più disparate combinazioni di eventi.
Il deliverable del SuapFD viene assemblato come un Web archive (WAR) e dispiegato su un
tomcat6 presso RT. Come db viene utilizzato DB2.
20/01/2012
7
SuapFD
Architettura del sistema
In questa sezione vengono presentati alcune figure logiche relative all’architettura del sistema
SuapEngine.
Architettura logica
Figura 1 Architettura logica sistema
20/01/2012
8
SuapFD
Modello dati
Figura 2 Modello dati db fdsuap
20/01/2012
9
SuapFD
Deployment diagram logico
Figura 3 Deployment logico del sistema
Casi d’uso
Di seguito verranno descritti i casi d’uso delle funzionalità implementate dal sistema.
Entrambi i casi d’uso sono equivalenti sia per la fonte dati FDES che la fonte dati FDOS.
20/01/2012
10
SuapFD
Diagramma UC
Figura 4 Diagramma dei casi d’uso semplice
Figura 5 Diagramma dei casi d’uso dettaglio attori
20/01/2012
11
SuapFD
Caso d’uso 1 – richiedi attributi
Descrizione del caso d’uso
Titolo
Richiesta attributi gestiti dalla fonte dati
Descrizione
L’attore invoca la fonte dati per chiedere gli
attributi che gestisce
Precondizioni
I parametri in ingresso richiesti devono essere
forniti e devono essere corretti
Postcondizioni
Attori
SuapFD, Cart Porta delegata, Role Manager
Note
--
Scenario principale
A1. Il RoleManager chiama il CART il quale a sua volta veicola la richiesta verso l’endpoint dove
risponde il servizio SuapFD per FDES e FDOS.
A2. Il SuapFD intercetta quale fonte dati è stata invocata e veicola la richiesta al dispatcher.
A3. Il SuapFD (FDES/FDOS) verifica che i dati passati in ingresso siano corretti e conformi alle
specifiche.
A4. Il SuapFD (FDES/FDOS) recupera i dati sul db.
A5. Il SuapFD (FDES/FDOS) costruisce il messaggio di risposta.
A6. Il SuapFD (FDES/FDOS) ritorna al CART il messaggio contenente la risposta generata.
A7. Il CART inoltra il messaggio al RoleManager
Scenario alternativo 1
A1. Viene sollevato un messaggio di errore gestito.
A2. Il SuapFD (FDES/FDOS) ritorna al CART il messaggio vuoto conforme alla RFC 146.
A3. Il CART inoltra il messaggio al RoleManager.
Scenario alternativo 2
A1. La ricerca sul db produce un risultato vuoto.
A2. Il SuapFD (FDES/FDOS) ritorna al CART il messaggio vuoto conforme alla RFC 146.
20/01/2012
12
SuapFD
A3. Il CART inoltra il messaggio al RoleManager.
Sequence Diagram
Nel diagramma vengono riportati i passaggi per la richiesta degli attributi gestiti dalla fonte dati.
L’esempio riporta lo scenario principale per la fonte dati FDES. Per la fonte dati FDOS il
diagramma è analogo.
Figura 6 Richiesta attributi gestiti dalla fonte dati
Esempio di richiesta
<ser:getUserAttributes />
Esempio di risposta
<ns1:getUserAttributesResponse xmlns:ns1="http://service.fontedati.arpa.eng.it">
<getUserAttributesReturn soapenc:arrayType="soapenc:string[4]" xsi:type="soapenc:Array"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
<getUserAttributesReturn
xsi:type="soapenc:string">AMBITO_SUAP</getUserAttributesReturn>
<getUserAttributesReturn
xsi:type="soapenc:string">ENTE_SUAP</getUserAttributesReturn>
20/01/2012
13
SuapFD
<getUserAttributesReturn xsi:type="soapenc:string">Funzioni</getUserAttributesReturn>
<getUserAttributesReturn
xsi:type="soapenc:string">Mail_Istituzionale</getUserAttributesReturn>
</getUserAttributesReturn>
</ns1:getUserAttributesResponse>
Caso d’uso 2 – richiedi valore attributi per CF
Descrizione del caso d’uso
Titolo
Richiesta valore attributi gestiti dalla fonte
dati per specifico codice fiscale
Descrizione
L’attore invoca la fonte dati per chiedere la
lista dei valori degli attributi e la loro validità
per lo specifico codice fiscale
Precondizioni
I parametri in ingresso richiesti devono essere
forniti e devono essere corretti
Postcondizioni
Attori
SuapFD, Cart Porta delegata, Role Manager
Note
--
Scenario principale
A1. Il RoleManager chiama il CART il quale a sua volta veicola la richiesta verso l’endpoint dove
risponde il servizio SuapFD per FDES e FDOS.
A2. Il SuapFD intercetta quale fonte dati è stata invocata e veicola la richiesta al dispatcher.
A3. Il SuapFD (FDES/FDOS) verifica che i dati passati in ingresso siano corretti e conformi alle
specifiche.
A4. Il SuapFD (FDES/FDOS) recupera i dati sul db.
A5. Il SuapFD (FDES/FDOS) costruisce il messaggio di risposta.
A6. Il SuapFD (FDES/FDOS) valida il messaggio di risposta.
A7. Il SuapFD (FDES/FDOS) ritorna al CART il messaggio contenente la risposta generata.
A8. Il CART inoltra il messaggio al RoleManager
20/01/2012
14
SuapFD
Scenario alternativo 1
A1. Viene sollevato un messaggio di errore gestito.
A2. Il SuapFD (FDES/FDOS) ritorna al CART il messaggio vuoto conforme alla RFC 146.
A3. Il CART inoltra il messaggio al RoleManager.
Scenario alternativo 2
A1. La ricerca sul db produce un risultato vuoto.
A2. Il SuapFD (FDES/FDOS) ritorna al CART il messaggio vuoto conforme alla RFC 146.
A3. Il CART inoltra il messaggio al RoleManager.
Sequence Diagram
Nel diagramma vengono riportati i passaggi relativi alla richiesta dei valori degli attributi per lo
specifico codice fiscale. L’esempio riporta solo lo scenario principale per la fonte dati FDES. Per
la fonte dati FDOS il diagramma è analogo.
Figura 7 Richiesta valore attributi per codice fiscale
20/01/2012
15
SuapFD
Esempio di richiesta
<ser:getAttributesValues >
<cf xsi:type="xsd:string">XXXXBA82E28G793B</cf>
<attributesName xsi:type="ser:ArrayOfString" soapenc:arrayType="xsd:string[]">
<attribute>AMBITO_SUAP</attribute>
<attribute>Mail_Istituzionale</attribute>
<attribute>Funzioni</attribute>
<attribute>ENTE_SUAP</attribute>
</attributesName>
</ser:getAttributesValues>
Esempio di risposta
<ns1:getAttributesValuesResponse xmlns:ns1="http://service.fontedati.arpa.eng.it">
<getAttributesValuesReturn xsi:type="xsd:string"><![CDATA[<?xml version="1.0"
encoding="UTF-8"?>
<lista_attributi>
<CodiceFiscale>XXXXBA82E28G793B</CodiceFiscale>
<attributo nome="ENTE_SUAP">
<valore>13.13.1.M.999.999999</valore>
<fine_validita>2012-01-20T15:54:31</fine_validita>
</attributo>
<attributo nome="AMBITO_SUAP">
<valore>13.13.1.M.999.999999</valore>
<valore>13.13.1.M.000.053004</valore>
<valore>13.13.1.M.000.048004</valore>
<valore>13.13.1.M.001.049005</valore>
<valore>13.13.1.M.000.045003</valore>
<fine_validita>2012-01-20T15:54:31</fine_validita>
20/01/2012
16
SuapFD
</attributo>
<attributo nome="Funzioni">
<valore>RespSUAP</valore>
<valore>OpSUAP</valore>
<fine_validita>2012-01-20T15:54:31</fine_validita>
</attributo>
<attributo nome="Mail_Istituzionale">
<valore>[email protected]</valore>
<fine_validita>2012-01-20T15:54:31</fine_validita>
</attributo>
<data_generazione>2012-01-19T15:54:31</data_generazione>
<id_fonte_dati>Fonte dati operatore SUAP</id_fonte_dati>
</lista_attributi>
</getAttributesValuesReturn>
</ns1:getAttributesValuesResponse>
Caso d’uso 3 – notifica variazione attributi
Descrizione del caso d’uso
Titolo
Notifica variazione valore attributi gestiti dalla
fonte dati al Role Manager
Descrizione
Il sistema SuapFD intercetta un evento di
modifica del valore di uno o più attributi della
fonte dati. Viene notificata la variazione al
Role Manager.
Precondizioni
I parametri in ingresso richiesti devono essere
forniti e devono essere corretti
Postcondizioni
Attori
SuapFD, Cart Porta delegata, Role Manager
20/01/2012
17
SuapFD
Note
--
Scenario principale
A1. Viene intercettata la modifica di un attributo.
A2. Viene scritto
trasmettere.
il nuovo valore dell’attributo sulla tabella TRASMISSIONE in stato da
A3. Si attiva il trigger relativo al job di controllo.
A4. Il job di controllo recupera la trasmissione.
A5. Il job di controllo costruisce il messaggio da inviare.
A6. Il job di controllo valida il messaggio da inviare.
A7. Il job di controllo decodifica quale credenziali utilizzare per fruire la RFC 156.
A8. Il job di controllo invoca il client che effettua la trasmissione delle variazione sul CART.
A9. Il job di controllo aggiorna lo stato della trasmissione a trasmessa.
A10. Il CART inoltra il messaggio al Role Manager.
Punto di estensione 1 (A4)
A4.1 Nel caso in cui per lo stesso attributo sono presenti più variazioni si prende quella più
recente ponendo a trasmessa lo stato di quelle meno recenti.
Scenario alternativo 1
A1. Viene sollevato un messaggio di errore gestito.
A2. Si ripete lo scenario principale.
Scenario alternativo 2
A1. Viene sollevato un messaggio di errore non gestito.
A2. Si ripete lo scenario principale.
Sequence Diagram
Il diagramma non mostra la fase di modifica dei valore degli attributi poiché il caso d’uso
principale si attiva solo quando tale valore è già presente nella tabella TRASMISSIONE.
20/01/2012
18
SuapFD
Volutamente non è stato modellato nei diagrammi dei casi d’uso lo scenario di modifica dei dati
da parte di un ulteriore attore poiché non prettamente inerente alla tematica del SuapFD.
L’attributo modificato tramite un trigger viene inserito nella tabella TRASMISSIONE.
Nel diagramma vengono riportati i passaggi relativi alla notifica della variazione del valore degli
attributi al Role Manager. L’esempio riporta solo lo scenario principale per entrambe le fonti
dati FDES e FDOS. Il diagramma evidenzia il dettaglio relativo al flusso opzionale nel caso in cui il
messaggio costruito sia valido e al flusso opzionale nel caso in cui il messaggio di risposta dal
Role Manager sia corretto. Inoltre viene evidenziato che l’interazione è di tipo loop e viene
iterato fin tanto che ci sono variazioni da notificare.
Figura 8 Invio della variazione al Role Manager
Esempio di richiesta
<ws:putVariazione>
<xml xsi:type="soapenc:string">
20/01/2012
19
SuapFD
<lista_variazioni>
<data_generazione>2012-01-20T16:38:00</data_generazione>
<id_fonte_dati> Fonte dati operatore SUAP </id_fonte_dati>
<lista_attributi>
<CodiceFiscale> XXXXBA82E28G793B </CodiceFiscale>
<attributo nome="Funzioni">
<valore> RespSUAP </valore>
<valore> OpSUAP </valore>
<fine_validita>2012-01-21T16:38:00</fine_validita>
</attributo>
</lista_attributi>
</lista_variazioni>
</xml>
</ws:putVariazione>
Esempio di risposta
<ns1:putVariazioneResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="http://ws.arpa.datapos.it">
<putVariazioneReturn xsi:type="soapenc:string"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">ACK</putVariazioneReturn>
</ns1:putVariazioneResponse>
20/01/2012
20