Soa

Il termine SOA – Service Oriented Architecture indica un’architettura software atta a supportare l’uso di servizi per soddisfare le richieste degli utenti così da consentire l’utilizzo delle singole applicazioni come componenti del processo di business. Nell’ambito di un’architettura SOA è quindi possibile modificare, in maniera relativamente più semplice, le modalità di interazione e combinazione tra i servizi, così come risulta più agevole aggiungere nuovi servizi e modificare i processi per rispondere alle specifiche esigenze di business: il processo di business non è più vincolato da una specifica piattaforma o da un’applicazione ma può essere considerato come un componente di un processo più ampio e quindi riutilizzato o modificato.
L’architettura orientata ai servizi si presenta particolarmente adatta per le aziende che presentano una discreta complessità di processi e applicazioni, dal momento che agevola l’interazione tra le diverse realtà aziendali permettendo, al contempo, alle attività di business di sviluppare processi efficienti, sia internamente che esternamente ed aumentarne la flessibilità e l’adattabilità.
Da un punto di vista implementativo, SOA è un modello architetturale basato su un accoppiamento non stretto fra agenti software. In tale modello un servizio è dato dall’esistenza da due entità qualsiasi che interagiscono con i ruoli di service provider, che fornisce servizi, e di service consumer, che li utilizza. La realizzazione dei ruoli di provider e consumer è ottenuta tramite agenti software che operano per tali entità. L’architettura del sistema software non è legata ad una specifica tecnologia e l’interfaccia del servizio è indipendente dall’implementazione. Pertanto è possibile utilizzare diverse tecnologia quali REST, ROC, DCOM, CORBA, Web Services. Soprattutto i Web Services e le tecnologie ad essi collegati si rilevano estremamente efficaci nel realizzare architetture SOA oriented. Chi progetta applicazioni o integra sistemi non deve necessariamente conoscere i particolari implementativi. Per esempio un servizio potrebbe essere implementato con una applicazione basata su J2EE o .Net e l’applicazione che utilizza il servizio potrebbe essere implementata con altri tipi di piattaforme e linguaggi software. Un’architettura SOA deve rispettare alcune caratteristiche generali: le interfacce del servizio devono essere descritte in termini indipendenti tramite, ad esempio, il linguaggio XML. WSDL (Web Services Description Language) è lo standard di fatto per la descrizione dei servizi. XSD o XML Schema è lo standard di fatto per descrivere la messaggistica del servizio. UDDI (Universal Description, Definition, and Integration) è lo standard di fatto per la gestione dell’indice dei servizi con cui le varie applicazioni possono ricercare l’esistenza di un servizio per poi richiamarlo. Diverse organizzazioni lavorano per definire modelli di riferimento per le architetture SOA e alcune di esse hanno dato una definizione di Service Oriented Architecture. Sono di seguito riportate le definizioni di Service Oriented Architecture date dalle organizzazioni OMG, OASIS, Open Group, W3C.

Firma Digitale

La firma digitale è associata indissolubilmente al concetto di documento elettronico. La recente normativa italiana conferisce ad un documento elettronico firmato digitalmente, utilizzando tecniche di firma asimmetrica, la stessa valenza probatoria di un documento cartaceo munito di firma olografa.
La firma digitale, quindi, esprime un atto volontario di sottoscrizione e, sotto il profilo tecnico organizzativo, deve essere basata su un certificato qualificato (quindi rilasciato da una trusted part detta Certification Authority che, per quanto previsto dalla vigente legislazione nazionale deve essere iscritta nell’elenco pubblico dei certificatori) e creata mediante un dispositivo di firma sicuro (in genere una smart card).
La direttiva europea e la nascita del commercio elettronico, hanno introdotto altri tipi di firma applicabili in contesti diversi da quello di un documento, come per esempio quello dei messaggi di posta elettronica: in questo caso si parla di firma elettronica.
Sia la firma digitale che quella elettronica permettono realizzare un sistema con il quale il mittente possa mandare un messaggio firmato al destinatario in modo che valgano le seguenti condizioni:
1. il destinatario può verificare l’identità dichiarata dal mittente;
2. il mittente non può ripudiare in un secondo tempo il contenuto del messaggio;
3. il destinatario non può falsificare i messaggi del mittente.
Il primo requisito è necessario, per esempio, per i sistemi finanziari. Quando il computer di un cliente ordina al computer della banca di comprare una tonnellata di oro, il computer della banca deve poter essere sicuro che il computer che ha mandato l’ordine appartenga realmente all’azienda sul cui conto verrà addebitato. In altre parole, la banca deve poter autenticare il cliente (e il cliente deve poter autenticare la banca). Il secondo requisito è necessario per proteggere la banca dalle frodi. Supponiamo che la banca compri una tonnellata d’oro e, immediatamente dopo, il prezzo dell’oro cali bruscamente. Un cliente disonesto potrebbe far causa alla banca, dicendo che non ha mai mandato l’ordine di comprare dell’oro. Quando la banca porterà il messaggio in tribunale come prova, il cliente negherà di averlo spedito. Il terzo requisito è necessario per proteggere il cliente, se il prezzo dell’oro sale e la banca tentasse di costruire un messaggio firmato in cui il cliente chiedeva una barra d’oro al posto di una tonnellata. In questo scenario di frode, la banca si tiene per sé il resto dell’oro.
Nel seguito di questo capitolo si illustreranno vari schemi di firma digitale e le loro implementazioni; ove necessario, saranno utilizzati degli esempi di situazioni reali che descrivono i vari scenari in cui ci si può trovare quando si implementano architetture basate sulla firma digitale. Infine si tratteranno brevemente gli aspetti legali legati alla firma digitale.

Firma a chiave simmetrica
Un approccio alle firme digitali è la creazione di un’autorità centrale che le conosce tutte e di cui tutti hanno fiducia: chiamiamolo Big Brother (BB). Ogni utente sceglie una chiave segreta e la porta a mano nell’ufficio di BB. Per maggiore chiarezza chiameremo il primo utente Alice ed il secondo Bob. Quindi, solo Alice e BB conoscono la chiave segreta KA e così via.
Quando Alice vuole mandare un messaggio in chiaro firmato, P, al suo banchiere, Bob, genera KA(B, RA, t, P), dove B è l’identità di Bob, RA è un numero casuale scelto da Alice, t è il timestamp che assicura la freschezza del messaggio e KA(B, RA, t, P) è il messaggio cifrato con la chiave KA. A questo punto Alice manda il messaggio, come nella figura sottostante, BB vede il messaggio da Alice, lo decifra e lo manda a Bob, come mostrato.

Il messaggio per Bob contiene il testo in chiaro con il messaggio di Alice e anche il messaggio firmato KBB(A, t, P). Infine Bob compie le azioni richieste da Alice.
Cosa succede se, in un secondo tempo, Alice nega di aver spedito il messaggio? Il passo 1 è che ognuno denuncia tutti gli altri. Infine, quando il caso arriva in tribunale e Alice continua a negare risolutamente di aver mandato il messaggio in questione a Bob, il giudice chiederà a Bob come può essere sicuro che il messaggio proveniva da Alice e non da un intruso (che chiameremo Trudy). Bob, come primo argomento, fa notare che BB non accetta messaggi da Alice se non sono cifrati con KA, quindi non è possibile che Trudy abbia mandato a BB un messaggio falso spacciandosi per Alice, senza che BB se ne sia accorto subito. Bob a questo punto può presentare la prova A: KBB(A, t, P). Bob afferma che questo è un messaggio firmato da BB, che prova che Alice ha inviato P a Bob. Il giudice chiede quindi a BB (di cui tutti si fidano) di decifrare la prova A. Quando BB testimonia che Bob ha detto la verità, il giudice dà ragione a Bob. Il caso è chiuso.
Un potenziale problema con il protocollo di firma della figura precedente è dato dagli attacchi di tipo ripetizione, che Trudy può eseguire con entrambi i messaggi. Per ridurre l’impatto di questo problema, vengono usati i timestamp. Inoltre Bob può controllare tutti i messaggi recenti per vedere se RA era già stato usato. In caso affermativo, il messaggio viene scartato come possibile attacco di ripetizione. Notiamo che, basandosi sul timestamp, Bob rifiuterà i messaggi troppo vecchi. Per proteggersi contro attacchi di ripetizione istantanea, Bob deve solamente controllare che RA di ciascun messaggio non corrisponda a quello di un messaggio ricevuto nell’ultima ora da Alice. In questo caso Bob può assumere che il messaggio sia una nuova richiesta.

Firma a chiave pubblica
Il problema strutturale della crittografia a chiave simmetrica per la firma digitale è dato dal fatto che tutti devono fidarsi di una autorità centrale (Big Brother), la quale può anche leggere i messaggi di tutti. I candidati più logici per una Autority sono il governo, le banche, i contabili e gli avvocati. Sfortunatamente, nessuna di queste organizzazioni riesce a suscitare un senso di sicurezza totale in tutti i cittadini. Quindi è auspicabile avere un metodo per firmare i documenti che non richieda un’autorità fidata.
Fortunatamente, la crittografia a chiave pubblica può dare un contributo importante in quest’area. Assumiamo che gli algoritmi di cifratura e decifrazione abbiamo la proprietà che E(D(P)) = P (D sta per Decript, E sta per Encript), oltre alla proprietà solita D(E(P)) = P. RSA ha questa proprietà, quindi sappiamo già che la nostra richiesta è ragionevole. Sotto queste ipotesti. Alice può trasmettere un documento, P, a Bob inviando EB(DA(P)). È importante notare che Alice conosce sia la sua chiave privata, DA, sia la chiave pubblica di Bob, EB, e in questo modo riesce a costruire il documento da inviare.
Bob, dopo aver ricevuto il messaggio, lo trasforma come al solito usando la sua chiave privata, ottenendo quindi FA(P) come mostrato nella figura successiva. Bob memorizza il messaggio in un posto sicuro e poi applica EA per ottenere il messaggio in chiaro originale.

Per vedere come funziona la proprietà di firma, supponiamo che Alice in un secondo momento voglia negare di aver mandato il messaggio P a Bob. Quando il caso arriva in tribunale, Bob può presentare sia P sia DA(P). Il giudice può facilmente verificare che Bob ha in effetti un messaggio valido che è stato cifrato con Da, semplicemente applicandogli EA. Visto che Bob non conosce la chiave privata di Alice, l’unico modo in cui Bob può aver ricevuto un messaggio cifrato con quella chiave è una trasmissione da parte di Alice.
Alice avrà diverso tempo libero per pensare a nuovi schemi crittografici a chiave pubblica mentre sarà in prigione per frode e falsa testimonianza.
La crittografia a chiave pubblica per la firma digitale è uno schema elegante, che però presenta alcuni problemi legati principalmente al contesto in cui viene utilizzata, piuttosto che agli algoritmi utilizzati. Come primo punto, Bob può provare che un messaggio è stato realmente mandato da Alice solo se la chiave Da rimane segreta. Se Alice rende pubblica la sua chiave segreta, il discorso non vale più, in quanto chiunque. incluso Bob, potrebbe aver inviato il messaggio.
Per esempio il problema può verificarsi se Bob è l’agente di borsa di Alice. Alice dice a Bob di comprare alcune azioni e obbligazioni. Quasi immediatamente il prezzo cala bruscamente. Con lo scopo di ripudiare il messaggio inviato a Bob, Alice corre dalla polizia dicendo che la sua casa è stata svaligiata e che il PC con la chiave è stato rubato. A seconda delle leggi in vigore nel suo stato di residenza, Alice può essere considerata responsabile del messaggio inviato oppure no; ciò può dipendere anche dal fatto che Alice dichiari di non aver scoperto il furto fino al suo rientro a casa dal lavoro, diverse ore dopo.
Un altro problema con lo schema della firma elettronica si ha quando Alice decide di cambiare la sua chiave. Questa operazione è sicuramente legale, inoltre è una buona idea farla periodicamente. Se in seguito si dovesse andare in tribunale come descritto sopra, il giudice userebbe la chiave corrente EA per verificare DA(P) e scoprirebbe che non produce P.
A questo punto Bob sarebbe in una posizione indifendibile.
In teoria, qualunque algoritmo a chiave pubblica può essere usato per la firma digitale. Lo standard de facto, utilizzato da una grande quantità di prodotti per la sicurezza, è l’algoritmo RSA.

Scrum

Scrum è un approccio allo sviluppo del software che prevede la suddivisione del progetto in iterazioni del progetto dette Sprints. Ad inizio progetto vengono definite le funzionalità che si dovranno implementare chiamate Backlog con le relative priorità. Tali priorità vengono assegnate da un’unica persona, il Product Manager, responsabile del prodotto e della sua visione; senza la sua autorizzazione non è possibile modificare la priorità del Product Backlog. Prima dell’inizio di ogni sprint, il gruppo di lavoro si riunisce con il responsabile del prodotto e insieme concordano gli elementi prioritari del Backlog che si dovranno implementare durante lo sprint. Ogni sprint ha una durata predefinita di 30 giorni ed una volta decisi gli obiettivi, questi non possono essere cambiati (se non dagli sviluppatori stessi) sino alla fine dello Sprint stesso. Al termine di ogni Sprint deve esserci il rilascio del software prodotto che deve essere un qualcosa di tangibile e utilizzabile dal cliente.
Durante lo sprint ogni giorno il team tiene un breve incontro di una quindicina di minuti chiamato Daily Scrum (Scrum è un termine che deriva dal Rugby e indica il “pacchetto di mischia”) dove il capo progetto (Scrum Master) annota i backlog completati e quelli che rimangono ed ogni sviluppatore racconta cosa ha fatto quel giorno e cosa dovrà fare il successivo.
In generale gli Scrum Meeting si tengono generalmente sempre allo stesso posto e alla stessa ora per dare un ben preciso “ritmo” al progetto. Con lo Scrum si ha un ciclo di controllo molto fine che permette capire lo stato quotidiano di avanzamento dei lavori e di scoprire quanto prima eventuali problemi progetto. Da un punto di vista organizzativo Scrum prevede un Product Owner (analogo al Customer in XP) che come committente del lavoro definisce le cose da fare (Product Backlog) e le relative priorità con scadenza mensile. Lo Scrum Master (analogo al Coach di Xp) è invece responsabile di gestire gli allineamenti giornalieri e mensili tenendo quindi traccia dello stato di avanzamento dei lavori e della situazione dei Backlog. Ogni mese (Sprint Review) definisce il lavoro per il mese successivo (Sprint Planning) in base alla priorità evidenziate dal Product Owner e sulle stime di impegno da parte del gruppo di sviluppo. Il gruppo di sviluppo (Scrum Team) crea un elenco (Sprint Backlog) di task (sotto attività del Backlog) da effettuare per raggiungere gli obiettivi del mese, segnala eventuali criticità allo Scrum Master negli allineamenti giornalieri e mensilmente presenta i risultati ottenuti durante lo Sprint. E’ bene precisare, prima di concludere questa breve descrizione, che SCRUM è una metodologia che definisce pratiche per pianificare e gestire i progetti, cioè di Project Management, ma non indirizza la modalità di sviluppo del prodotto (raccolta requisiti, analisi, disegno, sviluppo, test, …) e che quindi occorre integrarlo con altri approcci (XP, FDD, …) per indirizzare il processo di sviluppo.

Extreme programming

Extreme programming (XP) è un processo di sviluppo del software di recente formulazione e in continua evoluzione, incentrato sulla fase di codifica e portato alla ribalta da Kent Beck. Per progetti in cui i cicli di consegna sono molto compressi e con fattori di rischio tecnologico molto elevati piuttosto che seguire un processo di sviluppo “canonico” si segue un processo più “leggero”, “intuitivo” e quindi molto operativo. Si può affermare che XP è “code-centric”: tutte le fasi del ciclo di vita del software vengono compresse a favore dell’attività di codifica. L’XP si basa su dodici pratiche fondamentali (più altre introdotte successivamente) nessuna delle quali è un’invenzione del metodo. XP infatti propone pratiche già usate e consolidate e consiglia di applicarle tutte al massimo delle loro potenzialità: da qui il termine “estrema”. Le principali pratiche indicate da XP sono pair programming, test driver developement, refactoring, Continuous integration, standard e proprietà collettiva.

Il ciclo di vita prevede un’iniziale fase di “esplorazione” (Exploration Phase) dove si iniziano a raccogliere le user story, una versione “leggera” (e informale) degli Use Case previste dai modelli tradizionale di sviluppo software. Successivamente segue la fase di pianificazione (Planning Phase) dove il cliente scrive le “storie” su delle schede assegnando la relativa priorità e definisce i relativi test di accettazione. Le user story devono essere capite dal programmatore che deve stimarle e classificarle in base alla difficoltà (rischio) di realizzazione. Questo evidenzia come XP si spinga nella direzione della responsabilizzazione dei programmatori e della loro capacità di fare tesoro dell’esperienza delle passate iterazioni ed esperienza. Una volta prodotte le user story il cliente sceglie le storie da implementare compatibilmente con tempo e stime per la specifica iterazione. Il metodo suggerito dall’XP per passare dalle storie (descrizione funzionale) alla struttura ad oggetti del sistema è l’analisi con le schede CRC (Classe, Responsabilità, Collaborazione: una tecnica di OOA introdotta da Beck e Cunningham nel 1989). Le schede CRC hanno lo scopo di individuare in modo informale le caratteristiche fondamentali delle classi candidate esplicitandone il nome, la gerarchia e la relativa responsabilità [CRC]. Per user story particolarmente complesse o potenzialmente rischiose è consigliato lo sviluppo di un Architectural Spike. Un’ Architectural Spike è un programma scritto per sperimentare una soluzione, una sorta di prototipo, quasi sempre “usa e getta” per permettere una stima più accurata di una particolare user story.

Definite le User Story d’interesse si passa alla pianificazione dello sviluppo ossia alla assegnazione delle user story da implementare alle varie coppie di sviluppatori (Iterations to Release Phase). Mentre le iterazioni sono della durata fissa di una settimana, la durata di un rilascio varia a secondo che sia deciso per data (generalmente 2/3 mesi di durata) o per funzionalità (quante user story devono essere realizzate per lo specifico rilascio). L’importante è che ogni rilascio produca un sistema funzionante che permetta di ottenere feedback dal cliente. Gli sviluppatori devono sviluppare in modo semplice e concentrandosi sullo stretto richiesto (“il miglior modo per avere meno errori è avere meno codice!”). L’applicazione diventa quindi “il minimo insieme di codice che soddisfa i requisiti emersi” (“keep it simple”). Una riunione al giorno (in piedi!) permette di fare il punto della situazione e evidenziare eventuali problemi. Se l’iterazione è in ritardo, il cliente sceglie che storie differire alla successiva. La possibilità di tracciare il ritardo/anticipo permette di stimare la velocità di sviluppo del gruppo ed eventualmente rivedere la pianificazione del progetto. Terminata la codifica si inizia la fase di test di accettazione mediante sia test automatici al fine di certificare sia la qualità del codice prodotto sia per decidere l’eventuale rilascio (Productionizing Phase).

 

Come si può notare in questo ciclo di sviluppo appena descritto non è prevista esplicitamente né la fase di analisi né la fase di design. Queste fasi nei processi tradizionali (in questo contesto sono chiamate discipline) producono documentazione per il team stesso e per le fasi successive del progetto. In questo processo di sviluppo le fasi di analisi, design e sviluppo sono concentrate in un’unica fase e sulle medesime persone e questo fa sì che non vi sia una necessità immediata di produrre documentazione; in Xp il progetto evolve insieme al codice.

La documentazione del sistema in Xp è descritta mediante una System Methapor, una metafora del sistema che per Kent Beck è uno dei punti chiave dell’Xp. La metafora è una visione del sistema coerente e comprensibile sia dal cliente che dai programmatori. In molti casi la metafora può rispecchiare le entità nel mondo reale gestite dal sistema stesso e serve anche a dare nomi coerenti a classi, variabili e metodi del sistema, in modo che siano comprensibili a tutti i membri del gruppo di sviluppo. Le variabili in gioco in XP sono quattro: costo, tempo, qualità e portata. Generalmente tutte e quattro queste variabili sono fissate dal Management o dal client stesso. Xp dice che solo tre di queste variabili sono fissate a priori, mentre la quarta è il grado di libertà che sarà stabilita dal gruppo di lavoro in base al valore delle altre. In questo modo ad esempio a parità di costo e portata, se il management richiede una maggiore qualità, il tempo viene definito dal gruppo di sviluppo, committente permettendo. Tirando un po’ le somme, Xp si focalizza su gruppi di sviluppo piccoli (sull’ordine della dozzina di persone) per progetti di piccole medie dimensioni dove la stesura/modifica dei requisiti sono all’ordine del giorno. Il processo è semplice, snello e poco burocratico, ma deve essere comunque seguito con molta disciplina. E’ bene sottolineare che per applicare Xp il cliente ha un ruolo molto importante perché deve partecipare sia al progetto che alla sua evoluzione. Il Customer Xp è in ruolo chiave (e quindi anche critico) deve essere un esperto di dominio e quindi conoscere bene il business del cliente. Deve stabilire le priorità delle user story da implementare e specificare i relativi test di accettazione fino a tendere a condividere il successo/insuccesso del progetto. La critica più forte che viene mossa dagli oppositori di XP è che la disciplina funziona solo per buoni programmatori e che è inadatta a contesti progettuali in cui sia richiesta una tracciatura sistematica dei requisiti. Da un punto di vista organizzativo Xp prevede oltre alla figura di programmatore (stima le storie, definisce i task dalle storie, scrive il codice ed i relativi test), il Tester (esegue i test di accettazione e avverte il gruppo di sviluppo in caso di regressioni), il Tracker (tiene traccia della metrica e della storia del processo) ed il Coach; quest’ ultimo più che un Project Manager deve essere il Project Leader che segue/traccia il processo di sviluppo del progetto e aiuta in modo traversale nei casi di bisogno.