interoperabilità e cooperazione applicativa: elementi di

DINFODipartimento diIngegneria dell'informazione

Interoperabilità e cooperazione applicativa:elementi di progettazione

Samuele InnocentiDipartimento di Ingegneria dell'Informazione

Firenze, 2 ottobre 2015

2

Cooperazione applicativa e interoperabilità: elementi di progettazione



Contenuti

● Introduzione al contesto● Definizioni di cooperazione applicativa e

interoperabilità● Architettura e scelta dei pattern● Principi, linee guida e buone pratiche ● Alcuni esempi

3




C'era una volta...

4




Lo scenario

INFRASTRUTTURADI CONNETTIVITA'

Alcune definizioni di infrastruttura

Il complesso degli impianti che consentonoe condizionano un'attività [wikipedia]

l'insieme delle parti necessarie ad articolare un ambienteper adeguarlo a particolari esigenze [treccani]

Insieme di strutture secondarie e complementari di una strutturadi base, necessarie affinché quest'ultima possa funzionare [corriere.it]

Insieme di strutture date per scontate per rendere operativa una una attività

APP APPflusso informativo

5




Lo scenario

APP APPflusso informativo

INFRASTRUTTURADI CONNETTIVITA'

Alcune definizioni di infrastruttura

Il complesso degli impianti che consentonoe condizionano un'attività [wikipedia]

l'insieme delle parti necessarie ad articolare un ambienteper adeguarlo a particolari esigenze [treccani]

Insieme di strutture secondarie e complementari di una strutturadi base, necessarie affinché quest'ultima possa funzionare [corriere.it]

Insieme di strutture date per scontate per rendere operativa una una attività

6

Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione


● Interoperabilità e cooperazione applicativa: specifica capacità di due o più sistemi informativi connessi in rete.– capacità che essi devono avere, affinché l’applicazione, operante in ciascun sistema, sia in

grado di disporre automaticamente, per le proprie finalità applicative, dei dati che sono producibili e/o acquisibili solo attraverso il processo elaborativo delle applicazioni operanti negli altri sistemi informativi.

● Interoperabilità: capacità di due o più sistemi informativi di scambiarsi informazioni e di attivare, a suddetto scopo, processi elaborativi nelle rispettive applicazioni.– adozione di uno stesso formato di interscambio dei dati e di un protocollo di comunicazione

condiviso.

● Cooperazione applicativa: capacità di uno o più sistemi informativi di avvalersi, ciascuno nella propria logica applicativa, dell’interscambio automatico di informazioni con gli altri sistemi, per le proprie finalità applicative.– Un’applicazione nel corso del suo processo elaborativo può far uso di informazioni elaborate da

un’altra applicazione.

● L’interoperabilità è un prerequisito essenziale per la cooperazione applicativa.● La cooperazione applicativa in rete ha luogo quando ciò avviene in modo

automatico.

Definizioni di cooperazione applicativa e interoperabilità

[www.progettoicar.it]

7



● La cooperazione applicativa e l'interoperabilità NON sono semplice somma di sistemi, tecnologia e tecnica

● Alla base della cooperazione applicativa e dell'interoperabilità esiste una esigenza di condividere… animata da interessi

● La cooperazione applicativa e l'interoperabilità sono parte di “un processo”

● La cooperazione applicativa e l'interoperabilità devono essere garantite nel tempo

Osservazioni

8




● Sistema– un insieme di elementi distinti (incluse le persone)

– che sono connessi o correlati

– e lavorano assieme

– per realizzare una combinazione significativa di funzionalità e qualità

– la combinazione di funzionalità e qualità non può essere realizzata individualmente dai singoli elementi

● Complesso– composto di parti interconnesse o intrecciate

Sistema complesso

9



● Portare servizi di base, consolidati o da consolidare nell'infrastruttura

● Per abilitare lo sviluppo e la crescita di applicazioni e servizi a valore aggiunto(1)

● Per “le persone, le imprese, la società”

L'idea

(1) attività che aggiungono il valore, attività per le quali il cliente è disposto a pagare.[...] In particolare l’attività deve essere analizzata lungo gli aspetti: valore che il cliente associa alla determinata attività e valore che è disposto a pagare per quella attività. [http://www.lean.polimi.it/glossario.html]

10




Sistema complesso... costituito e usato da persone

APPLICATION LAYER

Sistema per sostenere le interazioni tra persone

11



Stima delle possibili interconnessioni

App 1 App 2

App 3 App 4

All'aumentare delle applicazionii link “crescono” come

n∗(n−1)

2

12



Complessità delle relazioni

App 1 App 2

App 3 App 4

Complessità:● Tecnologiche● Geografiche● Organizzative● Economiche● Sociali● Politiche● Culturali● Ambientali● ...

13




● Person to Person (P2P)● Person to Business (P2B)● Person to Government (P2G)● Business to Business (B2B)● Business to Government (B2G)● Business to Person (B2P)● Government to Government (G2G)● Government to Business (G2B)● Government to Person (G2P)

Classificazione delle interazioni

INT

ER

AZ

ION

IM

ED

IAT

E D

AL

LA R

ET

E

14




● Personale e Home (a livello individuale o familiare)● Locale o Aziendale (a livello cittadino, PMI, enti

locali)● Area Vasta (a livello provinciale o regionale)● Nazionale● Continentale o Enterprise (istituzioni pubbliche o

private, multinazionali)● Globale

Livelli geografici di cooperazione applicativa

15




● SaaS (Software as a Service)– modello di distribuzione del software applicativo dove un produttore di

software sviluppa e gestisce un'applicazione web che mette a disposizione dei propri utenti via internet.

● PaaS (Platform ad a Service)– distribuzione di piattaforme di elaborazione (Computing platform) e di

solution stack come servizio. Gli elementi del PaaS permettono di sviluppare, testare, implementare e gestire le applicazioni aziendali senza i costi e la complessità associati all'acquisto, la configurazione, l'ottimizzazione e la gestione dell'hardware e del software di base

● IaaS (Infrastructure as a Service) || HaaS (Hardware as a Service)– Insieme di tecnologie che permettono, tipicamente sotto forma di un

servizio offerto da un provider all'utente, di memorizzare/archiviare e/o elaborare dati (tramite CPU o software) grazie all'utilizzo di risorse hardware/software distribuite e virtualizzate in rete in un'architettura

Il mercato offre una pseudo “cooperazione” applicativa

[wikipedia]

16




Qualità della cooperazione applicativa

● Condivisa● Di compromesso● Standardizzata● Documentata● Normata● Regolamentata● Inclusiva

● Aperta● Trasparente● Imparziale● Efficace● Efficiente● Etica● Sostenibile

17




● Ci vuole una architettura per l'infrastruttura di cooperazione– Like any other complex structure, software [ndr architecture] must

be built on a solid foundation. Failing to consider key scenarios, failing to design for common problems, or failing to appreciate the long term consequences of key decisions can put your application at risk. Modern tools and platforms help to simplify the task of building applications, but they do not replace the need to design your application carefully, based on your specific scenarios and requirements. The risks exposed by poor architecture include software that is unstable, is unable to support existing or future business requirements, or is difficult to deploy or manage in a production environment [http://msdn.microsoft.com/en-us/library/ee658098.aspx]

Architettare la cooperazione applicativa

18




1) Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance,

security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application. [http://msdn.microsoft.com]

2) “Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and

behavioral elements into larger subsystems; and an architectural style that guides this organization.

Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns.” [Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman]

3) “The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are

multiple architectures in a system; what is architecturally significant can change over a system's lifetime; and, in the end, architecture boils down to whatever the important stuff is.” [Patterns of Enterprise Application Architecture, Martin Fowler]

4) “The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the

relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural.” [Software Architecture in Practice (2nd edition), Bass, Clements, and Kazman]

Alcune definizioni di architettura

19




Ingredienti

Funzionalità

Complessità

Organizzazione e cultura

Costi

Abilità

Qualità

Processi

Tecnologie

L'architettura è la ricetta, l'architetto è il cuoco

20



● Guida la scelta e la negoziazione dei requisiti● Rispetta i vincoli ed integra i requisiti● Riconosce l’importanza di tutte le parti interessate

e delle loro relazioni● Orchestra il sistema di elementi e le interrelazioni,

per fornire globalmente le qualità desiderate● Disciplina la comprensione delle relazioni tra la

struttura interna del sistema e le sue qualità esterne

● Sostiene il sistema nel suo complesso

Il ruolo della architettura

21




● Vincoli (ciò che esiste e non può essere violato)– fisici

● es. geografici, spaziali

– sociali● es. digital division, asset aziendali

– artificiali● es. normative, leggi, organizzazione del lavoro

– economici● es. budget

● Requisiti (ciò che dobbiamo o vogliamo rispettare)– funzionali

● Specificano una funzione che il sistema o un componente deve essere in gradi di realizzare

– non funzionali● Dichiarano come il sistema o un componente deve comportarsi (comportamento del sistema)

Vincoli e requisiti

22




● Tom Kelliher, CS 319, 1998

Analisi dei requisiti

23



● Accoppiamento● Eterogeneità● Autonomia● Maneggiabilità● Adattabilità● Sicurezza● Scalabilità

Requisiti non funzionali

Medjahed, Benatallah, Bouguettaya, Ngu and Elmagarmid. “Business-to-business interactions: issues and enabling technologies”, VLDB Journal, 2003

24



Classificazione dei requisiti non funzionali

[http://cnx.org/content/m14621/latest/]cfr IEEE 830-1993 (SRS)

http://cnx.org/content/m14621/latest/

25




Qualità interne ed esterne (ISO/IEC 9126-1:2001)

● Funzionalità (idoneità, accuratezza, interoperabilità, sicurezza)– La capacità del prodotto software i fornie funzioni che incontrino le necessità dichiarate e

implicite● Reliability (maturità, tolleranza ai guasti, recuperabilità)

– La capacità del prodotto software di mantenere un livello specifico di prestazioni● Usabilità (comprensibilità, apprendibilità, operabilità, attrattività)

– La capacità del prodotto software di essere compreso, appreso, utilizzato e attattattivo per l'utente

● Efficienza (comportamento nel tempo, utilizzo delle risorse)– La capacità del prodotto software di fornire adeguate prestazioni, relativa alle risorse utilizzate,

sotto prestabilite condizioni● Manutenibilità (analizzabilità, modificabilità, stabilità, verificabilità)

– La capacità del prodotto software di essere modificato. Le modifiche possono includere correzioni, miglioramenti o adattamenti a cambiamenti nell'ambiente, nei requisiti e specifiche funzionali

● Portabilità (adattabilità, installabilità, coesistenza, sostituibilità)– La capacità del prodotto software di essere conforme a standard o convenzioni relative alla

portabilità

26




● normativo (“scienza”)– basato su soluzioni preesistenti → “deve essere così”

● razionale (“scienza”)– basato su principi per affrontare cambiamenti nelle

necessità, nelle preferenze o nelle circostanze

● partecipativo (“arte”)– riconosce la complessità dovuta alla presenza di una

molteplicità di parti interessate → il consenso

● pragmatico (“arte”)– basato su euristiche che codificano il “buon senso

comune” motivato dalla esperienza collettiva

Progettare con metodo, esperienza e intuizione

27



Le fasi un progetto

realizza output e determina outcomes/effetti

bisogni/esigenze

supporto alle decisioni piano di sviluppo

decisione “politica”

progetto tecnico

copertura finanziaria per le fasi di produzione e manutenzione

28



Note sui fattori di insuccesso dei progetti

● I principali fattori di insuccesso dei progetti non riguardano gli aspetti tecnici

● Problemi manageriali– mancanza di supporto da parte della direzione

– mancanza di risorse (umane, materiali, knowhow)

– mancanza di pianificazione

– clima interno

● Problemi sui requisiti– requisiti incompleti

– mancato coinvolgimento degli utenti

– attese irrealistiche

– cambiamento dei requisiti in corso d'opera

– progetti cancellati perché non più utili

29




● In che modo è possibile affrontare/progettare problemi/sistemi ad alto livello di complessità?– partizionare (decomporre) il sistema/problema

progressivamente in unità più piccole e più semplici (divide et impera)

● È sufficiente che le varie parti siano “semplici”?– è necessario che anche le interconnessioni siano “semplici”

– utilizzare criteri di partizionamento/decomposizione in grado di ridurre la complessità delle interconnessioni tra le parti

Affrontare la complessità

La scelta delle parti e delle interconnessioni tra di esse definisce la “struttura” di un sistema (topologia)

30



● Decomporre il sistema in sottosistemi, gestibili separatamente, per dominarne la complessità– Siano P=problema, C=complessità di P, E=sforzo

per la risoluzione di P

● Dati 2 problemi P1 e P2, con C(P1)>C(P2), assumendo che E(P1)>E(P2) allora C(P1+P2)>C(P1)+C(P2) e conseguentemente E(P1+P2)>E(P1)+E(P2)

Osservazione

La scomposizione introduce il problema della comunicazione tra le varie parti, il che aggiunge anche

la complessità per l'interfacciamento

31




● Separation of concerns.– Divide your application into distinct features with as little overlap in functionality as possible. The

important factor is minimization of interaction points to achieve high cohesion and low coupling. However, separating functionality at the wrong boundaries can result in high coupling and complexity between features even though the contained functionality within a feature does not significantly overlap.

● Single Responsibility principle.– Each component or module should be responsible for only a specific feature or functionality, or

aggregation of cohesive functionality.

● Principle of Least Knowledge (also known as the Law of Demeter or LoD).– [ndr Information Hiding]

– A component or object should not know about internal details of other components or objects.

● Don’t repeat yourself (DRY). You should only need to specify intent in one place.– For example, in terms of application design, specific functionality should be implemented in only one

component; the functionality should not be duplicated in any other component.

● Minimize upfront design.– Only design what is necessary. In some cases, you may require upfront comprehensive design and

testing if the cost of development or a failure in the design is very high. In other cases, especially for agile development, you can avoid big design upfront. If your application requirements are unclear, or if there is a possibility of the design evolving over time, avoid making a large design effort prematurely. This principle is sometimes known as YAGNI ("You ain’t gonna need it").

Principi guida

[msdn.microsoft.com/library]

32




● Ciascun sistema è utile nella misura in cui consente di perseguire l'obiettivo e ottenere dei risultati– quali sono i risultati desiderati?

– quale è il motivo per cui un sistema viene costruito?

– quali sono i bisogni delle parti interessate al sistema?

● La definizione del problema da affrontare spesso non è nota o è mal definita, quindi è necessario:– identificare coppie problema-soluzione

– lavorare a stretto contatto con le parti interessate

Non perdere di vista l'obiettivo...

33




● parti interessate e interessi– chi ha interessi nel sistema? (stakeholders)

● punti di vista e viste– principio della separazione degli interessi, con

riferimento agli interessi principali del sistema

● stili architetturali– esperienze significative pregresse

● tattiche (locali) e strategie (globali) architetturali– come evolverà; dove condurre; obiettivi da raggiungere

… e focalizzare l'attenzione

34




● Un sistema viene realizzato per perseguire gli obiettivi di diverse parti interessate al sistema– utenti → chi userà il sistema

– amministratori → chi gestisce, verifica e manutiene il sistema

– clienti/acquirenti → chi paga per il sistema

– sviluppatori → chi crea e implementa

– ma anche decisori, comunità, associazioni, influenti, lobby ...

● Ciascun attore ha interessi sul sistema (funzionali e non funzionali)– l’architettura deve tenere in considerazione e sostenere gli

interessi sottesi, smussando i contrastanti, tra le parti interessate

Compromessi

35




● un singolo criterio di partizionamento/decomposizione non è di solito sufficiente per dominare la complessità di un sistema– utile decomporre e descrivere il sistema secondo un insieme di viste

architetturali, indipendenti ma correlate

● ciascuna vista architetturale definisce un modello (una descrizione parziale) del sistema – che si occupa di un insieme coeso di interessi

● le viste sono utili per comprendere, progettare, validare ed attuare l’architettura; per descrivere e comunicare l’architettura alle varie parti interessate

● la selezione e realizzazione delle viste può essere guidata da opportuni punti di vista (es. funzionale, delle informazioni, della concorrenza, di deployment)

Viste e punti di vista

36




● Le viste architetturali consentono di descrivere in modo efficace la struttura di un sistema, ma l’architettura non è interessata solo alla struttura dei sistemi– Analysis Model

– Design Model

– Implementation Model

– Software Architecture Document

– Architecture Notes

– Design Guidelines

– Programming Guidelines

– Architectural Prototype

– Architecure Presentation

Documentare, descrive, giustificare

37




● I pattern sono un metodo per condividere esperienze progettuali– in generale, un pattern ha lo scopo di condividere una soluzione provata

ed ampiamente applicabile ad un particolare problema di progettazione, descritta in una forma standard che possa essere riusata

– un pattern (o stile) architetturale codifica una esperienza significativa nella realizzazione di un’architettura

● Uno stile architetturale– mette a sistema una certa combinazione di requisiti (soprattutto di

qualità) da raggiungere

– propone una soluzione in termini di elementi, relazioni tra elementi e criteri di decomposizione (spesso nell’ambito di una singola vista)

– discute la soluzione e i termini delle diverse qualità su cui la soluzione impatta

Pattern e stili architetturali

38



Categoria Stile architetturale

Communication Service-Oriented Architecture (SOA),Message Bus

Deployment Client/Server,N-Tier, 3-Tier

Domain Domain Driven Design

Structure Component-Based,Object-Oriented,Layered Architecture

Esempi di stili architetturali

[http://msdn.microsoft.com/en-us/library/ee658117.aspx]

39



Principali stili architetturali

[http://msdn.microsoft.com/en-us/library/ee658117.aspx]

40



Pattern architetturali

[http://en.wikipedia.org/wiki/Architectural_pattern]

41




Tattiche e le strategie architetturali devono essere pianificate per progettare coerentemente

– una tattica architetturale è una decisione/scelta di progetto che influenza il controllo di un attributo di qualità (breve e medio periodo)

– una strategia architetturale è una collezione di attività, tattiche e linee guida per far sì che un sistema esibisca un insieme di proprietà di qualità correlate al fine ultimo (lungo periodo)

Tattiche e strategie

42




● Le applicazioni si scambiano dati con un “protocollo” → Data formats for data exchange

● Nel caso della interoperabilità si potrebbe parafrasare “Information formats for information exchange”

● Le informazioni (nella forma di dati) interoperabili devono essere ricevute, interpretate, elaborate e trasmesse automaticamente in maniera integra, coerente e semanticamente corretta

Non dimentichiamo l'interoperabilità

43



Le qualità del dato interoperabile ideale

● Completo → per esportare/integrare/diffondere● Primario → sufficientemente “granulare”● Tempestivo → accesso rapido e immediato● Accessibile → senza contratto o sottoscrizione o pagamento● Leggibile → machine-readable in processi automatici● Non proprietario → usabile da altre applicazioni● Libero da licenze con limiti d'uso → ©/brevetti non sostenibili● Riutilizzabile → per creare nuove risorse informative● Ricercabile → trovabile con facilità● Permanente → ciclo di vita “infinito”

Open Government Directive, USA, 2009

44



● Quale è lo schema strutturale?– È strutturato o flat? Di quali parti si compone? Come sono tra loro

relazionate?

● Quale è la codifica?– Formato binario o testo? Testo che codifica in formato binario?

Quale repertorio di caratteri?

● Quali convenzioni e interpretazioni assumere?– La forma del dato è predefinita? Quali convenzioni si adottano?

Quali prassi si sottendono?

● Quali elaborazioni posso eseguire senza perdere il senso e gli intenti dell'autore?– È possibile rileggerlo e riprodurlo nello stesso identico modo di chi lo

ha generato?

Riconoscere l'interoperabilità

45



Alcuni esempi di dati NON interoperabili

● Standard proprietari– non documentati pubblicamente

– documentati parzialmente

– legacy

● Soluzioni commerciali personalizzate

Osservazione: non basta lo standard!

46




Il mercato sviluppa offerte di interoperabilità

● OpenData

47



Per una reale interoperabilità

● Digitalizzare+dematerializzare+descrivere, ogni risorsa (rendendola elaborabile)

● Automatizzare l'elaborazione delle informazioni in tutto il loro ciclo di vita:– Da quando l'informazione viene creata, inviata,

ricevuta a quando viene archiviata, inoltrata, duplicata, cancellata

48



ESEMPI

49



Sistema Pubblico di Connettività (SPCoop)

50



Comunicazione in SPCoop

51



Flash sulla cooperazione applicativa in RT

Dominio dell’EnteNAL

Porta diDominio

CRIC

Gestore Eventi

Registro SICAsecondario (UDDI)

VPN CART

Porta di DominioCART

Gestione eMonitoraggio

Porta di DominioNAL

NAL

SIL

Agente digestione e

monitoraggio

Dominio dell’Ente

Componente diIntegrazione

PortaleCART

Internet

SPC

NICAGateway ICAR

by

ecosistemadi applicazioni

Publish&Subscribe

52



● Termini di utilizzo documenti SPCoop● Glossario generale e termini significativi d'uso comune● Inquadramento generale delle specifiche SPCoop● Specifiche della Busta di e-gov● Specifiche della Porta di dominio● Specifiche dell'Accordo di servizio● Specifiche del Registro SICA● Nomenclatura e semantica● LInee guida busta di e-gov● Qualificazione della Porta di dominio● Qualificazione Porta di dominio concorso regioni● Raccomandazioni stesura Accordi di servizio● Gestione federata delle Identità digitali

[http://www.agid.gov.it/agenda-digitale/infrastrutture-architetture/sistema-pubblico-connettivita/architettura-generale]

Documentazione e non solo

53




● Per l'iscrizione alla laurea in medicina e chirurgia e professioni sanitarie è previsto un limite massimo con programmazione nazionale, mediante assegnamento ministeriale dei posti alle singole sedi

● Concorso ministeriale che avviene lo stesso giorno in tutta Italia

● Localmente emerge l'esigenza di automatizzare il processo amministrativo e la logistica per adempiere all'obbligo istituzionale

Un esempio di cooperazione applicativa locale

54




● Il ministero bandisce il concorso e ne definisce alcuni aspetti normativi ed organizzativi– chi può partecipare, come inviare la domanda, data di

svolgimento, regole di svolgimento dei test, valutazione dei punteggi, graduatoria nazionale, ecc

● I candidati sottomettono la domanda di partecipazione ad un ateneo (prima scelta)

● I candidati partecipano ai test in quell'ateneo● Il ministero pubblica la graduatoria nazionale● I candidati vincitori possono iscriversi all'ateneo per il

quale hanno acquisito diritto

Il caso in estrema sintesi

55




● Dal 2007 UniFi (Polo Biomedico e Tecnologico) ha iniziato ad informatizzare e automattizzare il processo delle selezioni in area medica– Miglioramenti continui

– Cadenze annuali

● Alcune tappe significative– 2008 – adozioni di apparati industriali

– 2009 – sistema in alta disponibilità ed alta affidabilità per servire una area vasta, eliminazione completa della carta, gestione logistica e rendicontazione automatica

– 2010 – reingegnerizzazione del sistema e sperimentazione della virtualizzazione sottosistemi non critici

– 2011 – pagamenti elettronici e automazione delle immatricolazioni

– 2012 – eliminazione completa di tecnologie non-free

– 2013 – completa virtualizzazione dell'architettura hw

Informatizzazione del processo

56




Startup

app

web server

db

Selezionedel pattern3-tier

● MACRO FASE 1 – (2007) budget inesistente, tempi ristretti → una scommessa

php

apache

mysql

SelezionepiattaformeHW/SW

mysql v4

SceltaimplementativaHW/SW

apache v2

php v5

banalmenteLAMP su 1 vecchio server

57




Pianificare e realizzare

● MACRO FASE 2 – (2008) la fase 1 è un successo e le risorse arrivano: iniziamo a decomporre i sevizi

app

web server

db

Server dedicatoalle iscrizioni

Server dedicato Alla base dati

web server

appServer peraltre web appnon “critiche”

Sistema UPS

Redundat Power

58




Verificare e migliorare

Cluster bilanciamento di carico

Cluster web server

Cluster database

● MACRO FASE 3 – (2009-2010) l'utenza si espande, evitiamo i rischi → two-nines verificati (downtime<4gg/anno)

Storage distribuito condiviso

Data centerin alta affidabilitàe alta disponibilità

man

agem

ent

Sistema UPS

netw

orki

ng

Redundat Power

MACRO FASE 4 – (2013) virtualizziamo per abbattere gestione, manutenzione ed esercizio (anche a livello applicativo) → Obiettivo three-nines (downtime<9h/anno)

59




● 2011 – il Codice dell'Amministrazione Digitale impone i pagamenti elettronici da parte delle PA– Il sistema deve necessariamente adeguarsi

– E deve integrarsi con la rendicontazione elettronica dei pagamenti allo sportello bancario

● 2012 – Oracle acquista Sun Microsystem ed eredita MySQL– La nostra architettura stratificata consente di migrare a PostgreSQL:

una scelta ponderata, ma anche etica

– Impatto sul sw applicativo: non era stato sempre usato sql standard e neanche db abstraction layer

– Senza formazione/consulenze esterne non ci sono strumenti per validare/valutare il sistema

Interferenze esterne

60




La cooperazione applicativa

SistemaInformativo

Iscrizioni (polo)

Sistema gestione studenti

Graduatorie nazionali

Pagamenti ee rendicontazione

SegreteriestudentiLogistica

Resp.procedimento

Altri attori che partecipano direttamente o indirettamente al processo

Uff. tecnici

È la tesoreria di UniFi

Non è pubblicità

61




COD_FISCALE NOT NULL VARCHAR2(16) IDENTIFICATIVO VARCHAR2(20) COGNOME NOT NULL VARCHAR2(50) NOME NOT NULL VARCHAR2(40) SESSO VARCHAR2(1) DT_NASCITA VARCHAR2(8) COD_NAZIONE VARCHAR2(3) COD_ISTAT VARCHAR2(6) COD_CITTA VARCHAR2(6) COD_ISTAT_RES VARCHAR2(6) CAP_RES VARCHAR2(5) COD_CITTA_RES VARCHAR2(6) FRAZ_RES VARCHAR2(40) COD_ISTAT_DOM VARCHAR2(6) CAP_DOM VARCHAR2(5) COD_CITTA_DOM VARCHAR2(6) FRAZ_DOM VARCHAR2(40) RESIDENZA VARCHAR2(50) NUM_CIVICO_RES VARCHAR2(15) DOMICILIO VARCHAR2(50) NUM_CIVICO_DOM VARCHAR2(15) PRESSO VARCHAR2(30) TEL_PREF VARCHAR2(4) TEL_NUM VARCHAR2(10) DOTTORE VARCHAR2(1) DIVULGA_DATI VARCHAR2(1) POSTA VARCHAR2(1) EMAIL VARCHAR2(40)

● Pattern RTL: Extract → Transform → Load● Schema dati concordato● Codifiche dati coerenti● Trasmissione/Ricezione tracciato

– invio schedulato

● Compromesso tra le parti– Il più debole si deve adattare

– Il più debole deve sostenere i costi

Sottosistema “graduatorie” || “immatricolazione”

5001 TASSA IMMATRICOLAZIONE FASCIA 15001 TASSA IMMATRICOLAZIONE FASCIA 15002 TASSA IMMATRICOLAZIONE FASCIA 25002 TASSA IMMATRICOLAZIONE FASCIA 25003 TASSA IMMATRICOLAZIONE FASCIA 35003 TASSA IMMATRICOLAZIONE FASCIA 35004 TASSA IMMATRICOLAZIONE FASCIA 45004 TASSA IMMATRICOLAZIONE FASCIA 45005 TASSA IMMATRICOLAZIONE FASCIA 55005 TASSA IMMATRICOLAZIONE FASCIA 55006 TASSA IMMATRICOLAZIONE FASCIA 65006 TASSA IMMATRICOLAZIONE FASCIA 65007 TASSA IMMATRICOLAZIONE FASCIA 7

62




Sottosistema pagamento elettronico (SOA+RTL)

“The Broker”

Iscrizioneconcorsi

unifi

PagamentoEventi

unifi o aouc

Iscrizioneconcorsi OSS

aouc

WS

WSGestisce il carrello ordini, la rendicontazionee e lo stato dei pagamenti allo sportello e con carta di credito

Querciasincro RX

win vm

SPID&R

Protocollo proprietario

samba

Sistema Processi Integrati Didattica e Ricerca

63




Sottosistema pagamento elettronico (RTL)

“The Broker”

Iscrizioneconcorsi

unifi

PagamentoEventi

unifi o aouc


aouc


Querciasincro RX

win vm

SPID&R

samba

WSProtocollo proprietario


64




Sottosistema pagamento elettronico (SOA)

“The Broker”

Iscrizioneconcorsi

unifi

PagamentoEventi

unifi o aouc


aouc


Querciasincro RX

win vm

SPID&R

samba

WSProtocollo proprietario


65




La App SmartUnifi: cooperazione e interoperabilità

Infrastrutturadi integrazione

OpendataComune di Firenze

Sito web DSUToscana

APITwitter/YouTube...

OpenStreet Map

Gestionali e siti webdi Ateno

Archivi bibliotecheOPAC

66




Dipartimento di Architettura

DipartimentoIngegneria dell'Informazione

Comune di Firenze

Area Comunicazione eRelazioni Esterne

Direzione Generale

Servizi Informatici di Ateneo

Sistema Bibliotecario

Amministrazione di Ateneo

STUDENTI

APP

Gli attori istituzionali

67



Condizioni necessarie la cooperazione applicativa

● Accordi tra le parti (dal basso o calati dall'alto): protocolli di intesa, disposizioni di legge, piano di intenti, normativa, politiche

● Progetto, organizzazione e pianificazione● Finanziamento e/o copertura finanziaria● Architettura e infrastruttura (HW/SW) condivise,

inclusive, capillari, standardizzate e scalabili● Implementazione, manutenzione, disponibilità

del servizio e monitoraggio garantiti (qualità del servizio)

68




● Esistono infrastrutture di cooperazione applicativa?– Si, tante, pubbliche e private, globali, locali, ...

– In generale verticalizzate su particolari domini● eGovernment → federazione di PA● Banking → sistema interbancario (EDI e Financial EDI)● Peer-to-peer → singoli individui (eMule, torrent, ...)● Commercial → enterprise platform● Cloud → cloud computing, cloud sharing, virtualization

● Un “ISO/OSI” per la cooperazione applicativa ed interoperabilità” è un miraggio, ma forse non è necessario

Conclusioni


Interoperabilità e cooperazione applicativa:elementi di progettazione

Samuele InnocentiDipartimento di Ingegneria dell'[email protected]

“Il successo dipende dalla preparazione precedente,e senza una tale preparazione c'è sicuramente il fallimento.”(Confucio)


mailto:[email protected]

interoperabilità e cooperazione applicativa: elementi di

Documents