Capitolo 2

Capitolo 2

Tecnologie Informatiche

2. 1 Tecnologie in uso

Le tecnologie utilizzate per lo sviluppo di FSE Visualizer sono state scelte ed indicate dal team di supporto G&E e dal team di sviluppo del software. Il team di supporto ha evidenziato la necessità di compatibilità dell'applicativo con i sistemi già presenti e con gli ambienti di sviluppo in uso in area IT G&E.

Questo per facilitarne la comprensione e la gestione del codice , garantendo lo share (ovvero la condivisione) , del prodotto in fase di deploy e di test nelle 3 ambienti di sviluppo di riferimento:

• DEV (test e sviluppo) • QA (test qualitativo )

• PROD (rilascio in produzione)

In tutti e tre gli ambienti è presente come Application Server JBOSS versione 5.1, già installato e configurato per il nuovo applicativo.

La gestione della progettazione software è stata garantita dall'applicazione della metodologia Agile , modalità operata in tutti i settori di business aziendali G&E. Questo approccio verrà ampiamente descritto nel paragrafo 2.5 confrontandolo con altre modelli di Ingegneria del software attualmente conosciuti.

JAVA2EE , che attualmente è una delle modalità di programmazione in Java code più interessanti dal punto di vista di :

• portabilità del codice; • creazione del codice; • robustezza;

• efficienza;

é una piattaforma creata in collaborazione tra la SUN, Oracle, ed IBM, basata su linguaggio java orientato agli oggetti .

Si permette la creazione di componenti modulari, semplice e sicuri.

2.1.1 JAVA2EE

JAVA 2EE si definisce come una tecnologia Enterprise Java , in quanto viene incontro alle esigenze aziendali per progettare applicazioni robuste ed affidabili in un contesto distribuito. Per contesto distribuito si intende sistemi informativi aziendali con dislocazione fisica dei dati non centralizzata ma distribuita su vari nodi server di rete LAN o WAN.

Adatta alla definizione di servizi aziendali che coinvolgono diverse figure dette Stakeholders, come i fornitori, i clienti , gli impiegati aziendali. Ogni singola parte può accedere a diverse sezioni del sistema informativo avendo una visualizzazione generale come se fosse un'unica entità, quando in realtà le parti modulari che lo compongono non è detto che risiedano sullo stesso server di accesso.

La modularità permette anche la facile manutenzione del codice e del riuso di quest'ultimo su nuovi ampliamenti di codice.

La Java2EE favorisce la creazione di modelli per B2B e B2C, rispettivamente per Business to Business e Business to Consumer.

L'accesso ai dati può avvenire tramite diverse forme e dispositivi: • da web browser

• da tablet • da applet

• da sistema esterno

servizio per implementare un processo aziendale, senza preoccuparsi della gestione di controllo del livello base di effettiva esecuzione. Possiamo identificarla come un raccoglitore di diverse architetture per lo sviluppo distribuito.

1) Le tecnologie che presenta JAVA2EE in ambito front-end, quindi per l'interazione con l'interfaccia grafica sono:

• Java Server Page – JSP • Java server Faces – JSF

• XML

• Librerie di Custom Tag come le JSTL

2) Le tecnologie legate alla logica di Business possiamo indicarle in: • Enterprise Java Bean – EJB

• JNDI • Java Mail

• Java Transaction

Esse permettono la gestione degli accessi ai dati in Database, ne consentono di mantenere la persistenza, e ne gestiscono l'accesso in concorrenza di richieste. 3) Le tecnologie Web Service si basano su Architettura Service Oriented, quindi orientata ai servizi esposti:

• Web Service

• Java API xml based – JAX-WS • Java Api RPC – JAX RPC

Si aggiungono a questi le tecnologie per la gestione di servizi di autenticazione e sicurezza della transazione dei dati aziendali:

• Java Authentication and autorization service – JAAS • Java Connector architecture – JCA

Per far sì che lo sviluppo in Java2EE sia ben supportato è necessario che l'Application Server scelto per l'esecuzione di deploy e run dell'applicativo, sia adatto al controllo dei servizi esposti ed implementati.

Ne rappresenta lo strato software presente sul server che li espone, e li elabora secondo i file di configurazione indicati in fase di sviluppo.

Gli application server attualmente in uso sono diversi;

Bea Weblogic, IBM Websphere, Sun Application Server, Pramati ,Jboss, Glassfish, Apache Tomcat.

La scelta va effettuata in base alla conoscenza dei singoli strumenti ed alla comunità software che sta dietro le quinte, pronti a risolvere eventuali bug in fasi delicate di clustering e deploy applicativi.

Una volta scelto va installato ed avviato come un Web Server, presenta anche un pannello accessibile in remoto da browser per la gestione dei servizi, e dov'è possibile installare le applicazioni da sviluppare; quindi definire la gestione delle transazioni e delle sorgenti dati DB.

La connessione ai servizi può avvenire mediante l'uso di protocolli HTTP, RMI .

In ambiente JAVa è fondamentale l'utilizzo di componenti servlet, visti come oggetti java residenti sul server necessarie per costruire logiche applicative. Vengono gestite dal Container messo a disposizione dall' Application Server, che ne identifica il ciclo di vita dall'iniziodell'istanza per la richiesta di un servizio.

Esistono diverse tipologie di servlet, che ereditano da un super tipo presente nel package javax.servlet. La loro estensione dipende dal protocollo di comunicazione utilizzato. Possono essere delle HttpServlet in grado di comunicare con i client e rispondere dinamicamente in base alle loro richieste. Analizzando il funzionamento delle servlet da un punto di vista delle performance, si osserva come il container ha l’obiettivo di mantenere efficienti le risorse del sistema ottimizzando la vita delle servlet che sono attive. L’idea è quella di condividere un unico oggetto con tutti i clienti che ne richiedono i servizi. In tal modo vengono evitate le operazioni di creazione e istanza dell’oggetto; la creazione di connessioni verso sorgenti dati ; l’eliminazione delle stesse connessioni e dell’oggetto alla fine del servizio. Questo modello porta ad un notevole aumento di performance dovuto alla drastica diminuzione delle risorse di sistema, ora condivise da tutti coloro che vorranno utilizzare il servizio.

Si tratta in ogni caso di comunicazioni del tipo Client/Server con la possibilità di gestire più richieste per la stesso servizio.

L'uso delle tecnologie JSP ed JSF per la visualizzazione delle pagine di risposta e quindi a livello di presentazione non aggiungono quasi nulla di nuovo a quanto finora detto. Si tratta di semplici file testuali, che accanto al codice HTML, presentano codice in linguaggio Java, permettendo un utilizzo dinamico del servizio web e definendo la gestione grafica in moduli adatti per creazione di stili in CSS (Cascading Style Sheet), per la formattazione dei documenti ipertestuali in HTML, XML basato sulle raccomandazioni per la progettazione web del consorzio W3C.

Per la logica applicativa di business l'utilizzo dei JAVA Bean non sono altro che oggetti java che gestiscono la comunicazione tra le richieste in servlet e le pagine JSP per la presentazione del contenuto dinamico.

Sono gli oggetti che rappresentano la corretta mappatura di riferimento delle entità tabellari presenti in strutture Data Base.

Le diverse esigenze applicative sono state divise in tre aree principali: • Session Bean

• Message-Driven Bean

I Session BeanSession BeanSession BeanSession Bean sono EJB dedicati alla logica di business, cioè oggetti adibiti ad effettuare operazioni logiche come, per esempio calcolare dei prezzi, elaborare dei dati dinamici su richiesta esplicita di servizio.

Gli Entity BeanEntity BeanEntity BeanEntity Bean sono EJB dedicati alla rappresentazione dei dati. Attraverso questi oggetti è possibile leggere e scrivere dati da sorgenti persistenti: generalmente fanno uso di database, ma possono essere usati anche come sorgente dati legacy. I Message-Driven BeanMessage-Driven BeanMessage-Driven Bean sono EJB dedicati allo sviluppo di applicazioni asincrone,Message-Driven Bean cioè tutte quelle applicazioni che non necessitano una risposta immediata da parte del sistema a cui ci si connette. Si tratta di applicazioni che fanno uso di scambio messaggi, come i sistemi di invio mail o sms, e non è inusuale trovare sistemi di billing e reporting che ne fanno uso.

Lo scambio di informazioni tra le due macchine avviene attraverso delle Immagine 2.3. Esempio architettura Bean in diverse modalità di

chiamate su protocolli di rete. La macchina client invia la richiesta al server. Il server elabora la richiesta e produce un risultato. Il server invia il risultato al client.

Utilizzando gli EJB, ed in generale degli oggetti distribuiti, non cambia il paradigma object oriented. Lo sviluppatore non sa dove risiede il componente, ma, conoscendo le interfacce sa come richiamare i servizi e quali sono gli output attesi.

La presenza di questi componenti ed il loro particolare ciclo di vita permette una gestione molto efficiente delle risorse del sistema. Esistono due tipologie di session bean:

● stateless (senza stato) ● stateful (con stato)

Gli stateless session bean sono dei componenti di logica usati quando non c’è necessità di mantenere informazioni tra il client ed il server. In pratica sono oggetti per una richiesta ed una risposta. Questo particolare modello, che non li lega ad alcun client in maniera forte, rende possibile una gestione di risorse eccellente attraverso il meccanismo del poolingpoolingpooling.pooling

L’ application server mantiene una struttura dati (pool) in cui esistono una serie di istanze attive di stateless session bean. Ad ogni richiesta verrà utilizzato il primo bean del pool libero. Così facendo è evidente che un pool ben dimensionato può servire migliaia di utenti simultaneamente con pochissimi oggetti disponibili. L’ application server infatti non dovrà sprecare risorse nelle operazioni di creazione e distruzione, riutilizzando quanto già presente in memoria.

Gli stateless session beanstateless session beanstateless session bean sono evidentemente molto efficienti, ma possono esserestateless session bean utilizzati solo nel caso in cui tra un’operazione ed un’altra non debbano essere mantenuti informazioni tra client e server. In questo caso utilizzeremo gli Stateful Session Bean.

A differenza dei precedenti, il ciclo di vita dello stateful session bean è legato alla presenza di un utente.

Un tipico stateful session bean è il carrello della spesa, un componente utilizzato di continuo durante la navigazione di un sito di e-commerce.

L’application server mantiene in memoria una struttura dati che lega ad ogni utente l’eventuale stateful session bean, e la loro gestione questa volta differisce rispetto al pooling.

L’ application server, per mantenere efficienti le risorse, procede a mettere in uno stato passivo gli stateful session bean che in un dato momento non sono attivi, riattivandoli nel momento in cui l’utente effettua delle operazioni.

Il ciclo di vita di questi componenti prevede le fasi di passivazione ed attivazione. Le procedure di passivazione e di attivazione sono delle procedure di scrittura o lettura su disco fisso (swap), come accade per i sistemi operativi e la memoria virtuale.

In questo modo, l’ application server manterrà in memoria solo gli stateful session bean che stanno effettuando delle operazioni, riattivando gli altri nel momento del bisogno .

2.1.2 Tecnologie grafiche

Nello sviluppo di FseVisualizer si utilizza la versione di Html 5 per la rappresentazione grafica dell'interfaccia utente. Da G&E viene fornito un modulo di librerie grafiche a cui far riferimento tramite HTML5.1 , definite come IIDS.

Tale modulo caratterizza la grafica di tutte le finestre modali, le tabelle, gli input box, i form di ricerca e l'intestazione della home page di tutte le sezioni visibili, con l'inserimento del logo immagine proprietario G&E.

Html5 è un linguaggio di markup, in uso dal 2014, presenta delle innovazioni rispetto al classico html, ma la gestione dei tag nelle pagine html rimane invariata.

Le novità introdotte sono finalizzate soprattutto a migliorare il disaccoppiamento fra struttura, definita dal markup, caratteristiche di resa (tipo di carattere, color), definiti dal testo vero e proprio.

Inoltre prevede il supporto per la memorizzazione locale di grandi quantità di dati prelevati dal web, per consentire l'utilizzo di applicazioni basate su componenti più complessi come le caselle di posta o altri servizi analoghi;

anche in assenza di collegamento a Internet.

In particolare:

• vengono rese più stringenti le regole per la strutturazione del testo in capitoli, paragrafi e sezioni;

• vengono introdotti elementi di controllo per i menu di navigazione; • vengono migliorati ed estesi gli elementi di controllo per i moduli

elettronici;

• vengono introdotti elementi specifici per il controllo di contenuti multimediali (audio e video);

• vengono deprecati o eliminati alcuni elementi che hanno dimostrato scarso o nessun utilizzo effettivo;

• vengono estesi a tutti i tag una serie di attributi, specialmente quelli finalizzati all'accessibilità, finora previsti solo per alcuni tag;

• viene supportata la creazione di animazioni e grafica bitmap;

• introduzione della geo-localizzazione dovuta ad una forte espansione di sistemi operativi mobili come Android o iOS.

• sistema alternativo ai normali cookie chiamato Web Storage, più efficiente, il quale consente un notevole risparmio di banda;

• standardizzazione di programmi JavaScript;

• sostituzione del lungo e complesso doctype , con un semplice <!DOCTYPE html>.

2.3 Caratteristiche dell'Architettura Rest

In questo paragrafo viene analizzata la modalità di connessione ai servizi esposti, scelta nell'architettura REST, acronimo di Representational State Transfer.

Compare per la prima volta nel 2000 con la tesi di Roy FieldingRoy FieldingRoy FieldingRoy Fielding, “Architectural Styles and the Design of Network-based Software Architectures”, discussa nell'Università della California, ad Irvine.

Si analizzano alcuni principi alla base di diverse architetture software, tra cui appunto i principi di un’architettura software che consente di vedere il Web come una piattaforma per l’elaborazione distribuita. Il World Wide Web ne è un esempio concreto.

Il Web ha tutto quello che serve per essere considerata una piattaforma di elaborazione distribuita , secondo i principi RESTRESTREST, non sono necessarie altreREST sovrastrutture per realizzare quello che è il Web programmabile. Il che è una dichiarazione di aperto antagonismo ai Web Service Web Service Web Service Web Service basati su SOAPSOAPSOAPSOAP.

Le risorse sono gli elementi fondamentali su cui si basano i Web Service Web Service Web Service Web Service RESTful, a differenza dei Web Service Web Service Web Service Web Service SOAP-oriented che sono basati sul concetto di chiamata remota.

Per risorsa si intende un qualsiasi elemento oggetto di elaborazione. Per fare qualche esempio concreto, una risorsa può essere un cliente, un libro, un articolo, un qualsiasi oggetto su cui è possibile effettuare operazioni. Per fare un parallelismo con la programmazione ad oggetti possiamo dire che una risorsa può essere assimilata ad una istanza di una classe.

Ciascuna risorsa deve essere identificata univocamente.

Essendo in ambito Web, il meccanismo più naturale per individuare una risorsa è dato dal concetto di URI o URL, rispettivamente Uniform Resource Indentifier ed Uniform Resource Locator. La prima identifica una risorsa generica come un indirizzo web in rete , la seconda oltre a identificare una risorsa, fornisce mezzi

per agire su di essa o per ottenere una rappresentazione della stessa descrivendo il suo meccanismo di accesso primario o la sua "ubicazione" ("location") in una rete.

Esempi di URL per singole risorse:

http://www.myapp.com/prodotti/7654 http://www.myapp.com/ordini/2011

tale rappresentazione viene riportata da una pagina html che ne visualizza lo stato attuale della medesima risorsa.

Si cambia la rappresentazione dello stato per ogni richiesta client da visualizzare, accedendo con metodi del protocollo HTTP, usato già ampiamente in Rete.

La rappresentazione della risorsa è come se evocasse un'immagine di come un'applicazione Web si comporterebbe .

Una rete di pagine web ( uno stato - macchina virtuale) , in cui l'utente progredisce attraverso un'applicazione selezionando link (in transizioni di stato ) , conseguente alla pagina successiva ( che rappresenta lo stato successivo dell'applicazione ) essendo l'utente trasferito al rendering per il loro utilizzo. Il Rest non è uno Standard ma un tipo di Architettura che utilizza degli standard per la costruzione del Client-Server:

● HTTP

● URL

● XML/HTML/GIF/JPEG/etc (Resource Representations)

● text/xml, text/html, image/gif, image/jpeg, etc (MIME Types) Possiamo quindi affermare che il Web è un sistema REST .

Molti dei servizi messi a disposizione ed offerti in rete, si usano abitualmente come :

● books ,

● ordinazioni,

● servizi di ricerca on-line , ● servizi di dizionario

● etc..

La forza di tale tecnologia intrinseca in rete, è quelli di poterne osservare il funzionamento nella forma globale. Non ci si immerge in dettagli implementativi con la creazione di java servlet o di interfacce GCI per l'implementazione del servizio esposto . Quindi diamo un'occhiata a un esempio di creazione di un servizio Web visualizzando il " quadro generale " .

L'architettura REST è caratterizzata da uno stile Client-Server basato su logica Pull, in cui le componenti lavorano su rappresentazioni di stato. Ovvero lo svolgimento delle attività del server avviene su richiesta dello stato della risorsa, l'attività a valle segue quella a monte.

É di tipo StateLess, quindi ogni richiesta client al server deve contenere tutte le informazioni per comprendere la richiesta del servizio, e memorizza contesti generati dal server.

Ha una Cache per migliorare le risposte in efficienza, quindi con richieste o elaborazioni di stato cacheable.

Ha un' Interfaccia uniforme, tutte le risorse sono accessibili da una pagina html generica con protocollo HTTP ed i suoi metodi : GET, POST , PUT, DELETE.

Le risorse sono Nominative, Named, ovvero il sistema è composto da risorse associate ad un URL di riferimento. La rappresentazione di tali risorse comunicati avviene con URL interconnessi, consentendo al Client di passare da uno stato all'altro del servizio richiesto.

I componenti Layered, intermediari come i server proxy , server cache, e gateway possono essere inseriti tra i client e le risorse, migliorando le prestazioni e la sicurezza delle transazioni visibili.

La chiave per la creazione di servizi Web in una rete REST è quella di individuare tutte le entità concettuali che si desidera esporre in rete.

Categorizzare le risorse a seconda che i client possano solo ricevere una rappresentazione della risorsa o modificarla . In caso di richiesta di accesso in lettura della risorsa , il protocollo usato è HTTP ed il metodo GET . Nel caso di modifica della risorsa o creazione di una nuova i metodi del protocollo HTTP da considerare sono POST, PUT, DELETE.

Tutte le risorse accessibili via HTTP GET dovrebbero essere privi di effetti collaterali . Cioè , la risorsa deve solo restituire una rappresentazione della stessa , non deve creane alcuna modifica.

Nessuna rappresentazione dovrebbe essere un'isola . E dunque, inserire collegamenti ipertestuali all'interno le rappresentazioni di risorse, per consentire

ai client di eseguire il drill down per ulteriori informazioni e / o per ottenere informazioni correlate.

La progettazione è organizzata per rivelare dati gradualmente , non tutto in un unico documento risposta.

Il formato dei dati in risposta va specificato utilizzando uno dei possibili schemi di visualizzazione dei dati quali:

✔ DTD ,

✔ W3C Schema , ✔ RelaxNG , ✔ Schematron .

I servizi invocati verranno descritti utilizzando un documento WSDL , o semplicemente un documento di Ipertesto, HTML .

2.3.1 Esempio di Architettura tipo client-server

Restful

Verifichiamo in pochi passi di un semplice esempio come tale architettura possa essere utilizzata.

Una società decide di implementare alcuni servizi web per consentire ai propri clienti di :

(1) ottenere un elenco delle risorse;

(2) ottenere informazioni dettagliate per una risorsa; (3) inviare un ordine d'acquisto;

Avremo dunque una Società, delle risorse, un Order, un Client , un Server.

1) Il servizio web mette a disposizione un URL per una risorsa elenco utilizzando il seguente URL per accedervi:

Si noti che il "come" il servizio Web genera l' elenco delle parti, è completamente trasparente per il cliente . Dall'indirizzo URL verrà restituito un documento. Poiché l'implementazione è trasparente per il Client , la Società è libera di modificare l' implementazione sottostante di questo servizio senza incidere sulla stessa richiesta del client. Questo viene identificato come lllloose coupling (accoppiamento lasco).

Nei sistemi di progettazione un accoppiamento lasco accoppiamento lasco accoppiamento lasco accoppiamento lasco indica un sistema in cui ciascuno dei suoi componenti ha o fa uso di poca o nessuna conoscenza delle definizioni dei componenti separati, quali le aree che includono l'accoppiamento di classi , interfacce, dati e servizi.

Questo è quello che il client riceve come documento html richiesto:

<p:Parts xmlns:p="http://www.parts-depot.com" xmlns:xlink="http://www.w3.org/1999/xlink">

<Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/> <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/> <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/> <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/> </p:Parts>

Come si può notare la lista delle risorse è a sua volta una lista di link contenenti ulteriori informazioni di dettaglio della stessa.

Questa è una caratteristica fondamentale di REST . I trasferimenti client avvengonoda uno stato all'altro , esaminando e scegliendo tra gli URL alternativi nel documento di risposta .

2) Esplorando , dunque, singola risorsa da uno dei links presentati dal documento lista , si avrà la seguente html page :

<?xml version="1.0"?>

<p:Part xmlns:p="http://www.parts-depot.com" xmlns:xlink="http://www.w3.org/1999/xlink"> <Part-ID>00345</Part-ID>

<Name>Widget-A</Name>

<Description>This part is used within the frap assembly</Description> <Specification

xlink:href="http://www.parts-depot.com/parts/00345/specification"/> <UnitCost currency="USD">0.10</UnitCost> <Quantity>10</Quantity>

Ancora una volta possiamo osservare come questo dato è legato ad ulteriori approfondimenti ; le specifiche per questa risorsa può essere trovata attraversando il collegamento ipertestuale . Ogni documento di risposta consente al client di eseguire il drill down per ottenere informazioni più dettagliate .

3) Il servizio web mette a disposizione un URL per inviare un ordine di prenotazione . Il client crea un documento di istanza per la prenotazione conforme allo schema progettato dalla Società, esposto in un documento WSDL.

Il client invia un file order.xml come payload di una chiamata di protocollo del

tipo POST HTTP .

Il servizio Order risponde alla POST HTTP con un URL per l'ordine presentato . Quindi , il client può recuperare l'ordine in qualsiasi momento successivo ( per aggiornare / modificarlo ) . L'Ordine è diventato a questo punto ,un pezzo di informazione condivisa tra il client e il server . Le informazioni condivise ( Order ) vengono associate ad un indirizzo ( URL ) dal server ed esposte come

Web services .

Una risorsa è un'entità concettuale . Una rappresentazione è una manifestazione concreta della risorsa .

Il seguente URL :

http://www.parts-depot.com/parts/00345

è un URL logico , non un URL fisico . Così come non deve esserci una pagina HTML statica per ogni risorsa .

Infatti, se ci fossero un milione di risorse ed un milione di pagine HTML statiche non si avrebbe un accesso facilitato alla consultazione delle medesime.

La Società potrebbe implementare il servizio che riceve i dati dettagliati su una risorsa particolare , impiegando una Servlet Java che analizza la stringa URL che contiene il nome dell'Host , utilizzando il numero di risorsa per interrogare la banca dati che contiene tutte le risorse.

Lo scopo della tecnologia Rest è non impattare i client quando vengono effettuate delle modifiche a livello di tecnologie implementative del Web Service. All'occhio dell'utente rimane il semplice utilizzo del URL , senza che possa interessarsi di come verranno elaborate le richieste e da come verranno presentate.

2.4 Tecniche di Persistenza dei dati - MyBatis

MyBatis è un framework di persistenza di prima classe con il supporto per SQL personalizzata, stored procedure e “mappature” avanzate. Elimina quasi tutto il codice JDBC e manuali impostazioni di parametri e recupero dei risultati. MyBatis può utilizzare XML semplice o annotazioni per configurazione. Mappa interfacce e POJO Java (Plain Old Java Object) al record del database.

É software libero distribuito con licenza Apache 2.0, ed aiuta a collegare il framework di librerie Spring con database relazionali utilizzando xml o annotazioni.

Ogni applicazione di MyBatis gira intorno all’istanza di SqlSessionFactorySqlSessionFactorySqlSessionFactorySqlSessionFactory. Un’istanza di questo oggetto può essere ottenuta grazie alla classe SqlSessionFactoryBuilder

SqlSessionFactoryBuilder SqlSessionFactoryBuilder

SqlSessionFactoryBuilder, che prende in pasto un file XML (o un’istanza della classe Configuration).

Il codice per ottenere un SqlSessionFactory attraverso un file XML è molto semplice: basta infatti definire la risorsa che contiene il path del file, come una stringa. Opzionalmente è possibile specificare l’environment che vorremmo che sia utilizzato. Vediamo un semplice esempio:

String resource = "org/mybatis/example/Configuration.xml"; Reader reader = Resources.getResourceAsReader(resource); sqlMapper = new SqlSessionFactoryBuilder().build(reader); Il file di configurazione xml viene definito come di seguito:

<!DOCTYPE configuration

PUBLIC "-//mybatis.org//DTD Config 3.0//EN" "http://mybatis.org/dtd/mybatis-3-config.dtd"> <configuration> <environments default="development"> <environment id="development"> <transactionManager type="JDBC"/> <dataSource type="POOLED">

<property name="driver" value="${driver}"/> <property name="url" value="${url}"/>

<property name="password" value="${password}"/> </dataSource> </environment> </environments> <mappers> <mapper resource="org/mybatis/example/BlogMapper.xml"/> </mappers> </configuration>

I tag <mappers> e <mapper> specificano la lista dei mapper, ovvero i file XML che contengono il codice SQL e le definizioni di mapping.

Una volta ottenuta la SqlSessionFactory, per ottenere una SqlSession basta invocare il metodo openSession()openSession()openSession()openSession(). :

SqlSession session = sqlMapper.openSession(); try {

Blog blog = (Blog) session.selectOne(

"org.mybatis.example.BlogMapper.selectBlog", 101); } finally {

session.close(); }

A seguito della SqlSession si conclude la fase di setup e si può utilizzare MyBatis per interrogare e/o modificare il DB. Una volta creato, SqlSessionFactory, il ciclo di vita dura per tutta l'esecuzione.

In MyBatis non è necessario creare la connessione, prepareStatement, ed impostare i parametri per chiudere la connessione da soli per ogni chiamata al database. Basta configurare le proprietà della connessione al database e le istruzioni SQL, e MyBatis si prenderà cura di tutto il lavoro.

Altri framework di persistenza più conosciuti ed usati sono JPA Java e Hybernate.

2.4.1 JPA

JPA è una specifica Java per mappare un POJO su un database, pertanto richiede un’implementazione. E' un progetto open-source di Apache che supporta le Api JPA delle specifiche EJB 3.0.

Il vantaggio offerto da JPA consiste nell’abilitare un mapping di oggetti-relazioni attraverso annotazioni o XML standard, definendo come avviene il mapping tra classi Java e tabelle di un database relazionale. JPA definisce inoltre le API di un EntityManagerEntityManagerEntityManager, il cui scopo è la gestione a EntityManager runtime di queries e transazioni su oggetti resi persistenti.

JPA è la più recente tra le specifiche Java volte a fornire la persistenza.

Un’altra specifica Java, è lo standard JDOJDOJDOJDO (Java Data Objects), che ha riscosso attenzione e ha visto lo sviluppo di diverse implementazioni commerciali o open source, ma senza trovare l’appoggio dei principali attori del Java EE.

Nel confronto tra gli standard, vi sono soluzioni di tipo proprietario, tra le principali ricordiamo HibernateHibernateHibernateHibernate e TopLinkTopLinkTopLinkTopLink..

Il processo di trasformazione da oggetto istanza di una classe a dato di un database prende il nome di ORMORMORMORM (Object Relation Mapping ) ,usato in JPA. Il vantaggio di ORM sta essenzialmente nel riuso. Lo scopo è ridurre tempi e conseguentemente costi di sviluppo demandando a librerie già realizzate (testate ed ottimizzate) la gestione dei driver JDBC, del codice SQL e in generale del mapping tra oggetti e database.

Le soluzioni offerte risultano indipendenti da schemi e database e si appoggiano su di una cache utile a migliorare le performance. Non ultimo vantaggio il supporto alla concorrenzaconcorrenzaconcorrenzaconcorrenza. .

Ai vantaggi offerti dall’ ORM si aggiungono quelli di JPA. In primo luogo essendo uno standard molte implementazioni sono free e open source, garantendo portabilità tra i diversi prodotti che richiedono o offrono la persistenza (ciò evita la dipendenza da uno specifico prodotto, problematica conosciuta come vendor lock-in). Le specifiche inoltre sono funzionali e supportano sia JEE che JSE ( Java Enterprise e Java Standard).

2.5 Spring Framework

Spring è un framework che offre molte funzionalità di base prima fra tutte la gestione delle transazioni tramite AOP che libera il programmatore dal dover gestire il commit e rollback via codice. Lo Spring framework offre anche un supporto web Model View Control adatto per interfacce REST o interfacce web molto semplici. Si può usare “ collante” in quanto dispone di moduli per integrare le librerie più diffuse.

Fra le librerie più diffuse ci sono quelle per l’accesso al database relazionale ovvero che hanno lo scopo di aiutare il programmatore a leggere e scrivere i dati automatizzando la conversione di tabelle in oggetti Java.

1. Librerie che generano l’ sql ,

2. Librerie che richiedono al programmatore di scrivere l’ sql ,

Scegliere fra una libreria e l’altra Se l’applicazione ha come necessità principale di ricevere dei dati, salvarli, mostrarli, gestire un workflow e qualche elaborazione la scelta ricade senza dubbi sulla seconda opzione.

Se l’applicazione è database centrica ha senso avere il pieno controllo dell’ SQL e usarlo fino in fondo ovvero usando anche le funzioni proprietarie (per esempio la ricerca full text di Postgres o il supporto per i dati JSONB, l’istruzione merge o quella pivot in Oracle).

Tra le librerie che permettono di scrivere SQL e gestirlo in maniera strutturata ritroviamo Mybatis che consente di salvare le istruzioni per il database in un file xml (nei casi più semplici anche via annotation) e consente di avere parti di sql che si compongono dinamicamente per ottenere la query necessaria, come mostrato nel paragrafo 2.4 .

Alcune doverose considerazioni nella configurazione ed utilizzo di spring a livello di codice riguardano i valori di:

• bean con id =”propertyConfigurer” indica a Spring di caricare le properties contenute in jdbc.properties;

• bean con id =”dataSource” è un’ implementazione di javax.sql.DataSource. L’id “dataSource” è una convenzione di Spring per

designare il dataSource dell’applicazione, nel caso ve ne fosse solo uno; • bean con id =”transactionManager” definisce il componente che si

occuperà di coordinare le transazioni delle classi annotate come @Service o @Transactional.

2.5.1 Spring e JDBC

Questa libreria è già inclusa nelle dipendenze del progetto (spring-jdbcspring-jdbcspring-jdbc) espring-jdbc contiene diverse classi di utilità che consentono di gestire in maniera molto elegante e affidabile le complesse JDBC API, consentendo di concentrarsi sulla realizzazione delle query e non su aspetti di apertura/chiusura delle connessioni e delle transazioni, gestione delle eccezioni, ed iterazione sui risultati.

La classe più importante del framework è:

org.springframework.jdbc.core.JdbcTemplate

e come molte delle classi di utilità di Spring utilizza il Template Design pattern. Questa classe esegue query o update SQL, inizializzando l’iterazione sui ResultSet, catturando le eccezioni JDBC e traducendole nelle corrispettive generiche e più informative definite nel package org.springframework.dao.

Spring mette a disposizione una classe astratta:

org.springframework.jdbc.core.support.JdbcDaoSupport.

Estendendola, e configurando un dataSource, si ha a disposizione un DAO con un’istanza già pronta e funzionante di JdbcTemplate;

Senza configurare nulla o specificare transazioni ed eccezioni JDBC.

Le stringhe SQL vengono create tramite degli StringBuilder per la massima flessibilità;

• ai metodi query() e queryForObject() di JdbcTemplate viene passata un’istanza di RowMapper . Questa verrà utilizzata per mappare correttamente i dati contenuti nel ResultSet nelle property delle istanze di oggetti Insertion.

2.6 Logica Agile per la progettazione software

La metodologia Agile si riferisce ad un approccio iterativo ed evolutivo nella gestione progetti in cui i requisiti e le soluzioni maturano in corso d’opera attraverso la collaborazione del team di sviluppo con la committenza.

Il termine è stato coniato nel 2001 quando fu pubblicato l' ”Agile Manifesto” che fa riferimento ad un insieme di approcci e strumenti come, lo SCRUM, l'Extreme Programming, etc; ideati con particolare riferimento alla gestione di progetti per lo sviluppo del software.

La logica di fondo è quella di arrivare a produrre il più rapidamente possibile i deliverables, ovvero gli obiettivi preposti, e poi rifinirli attraverso cicli successivi di miglioramento.

Comporta un tempo di rilascio delle singole attività più rapido ed un costo più basso rispetto ad un approccio classico “waterfall”, ovvero a cascata . Frequenti modifiche possono diventare onerose in fase di una rielaborazione del lavoro creando una maggiorazione del costo finale di progetto.

Per questo è bene che le modalità complessive di governo di un progetto rimangano strutturate secondo la logica “waterfall” e solo alcune fasi siano gestite con modalità di sviluppo iterativo o per prototipi.

Punti di forza della metodologia Agile Punti di forza della metodologia Agile Punti di forza della metodologia Agile Punti di forza della metodologia Agile:

➢ l’avvio dell’implementazione è rapido e lo sviluppo è incrementale; ➢ i requisiti possono evolvere in corso d’opera;

➢ la risposta ad esigenze di cambiamento è rapida; ➢ frequenti momenti di test e di revisione dei requisti;

➢ collaborazione attiva nello sviluppo tra fornitore e committente. Punti di debolezza della metodologia Agile

Punti di debolezza della metodologia Agile Punti di debolezza della metodologia Agile Punti di debolezza della metodologia Agile:

➢ in assenza di pianificazione e documentazione del lavoro da svolgere, questo può essere frainteso o procedere in modo indisciplinato con conseguente rework;

➢ il tempo richiesto al cliente per il suo coinvolgimento è elevato;

➢ l’orizzonte è concentrato sul breve termine è c’è quindi il rischio che si perda la prospettiva di lungo periodo;

➢ la documentazione prodotta è poco dettagliata e questo può creare problemi di utilizzo da parte dell’utente o di governo del progetto da parte del Project Manager .

2.6.1 Processo di Scrum

Lo Scrum non è altro che un metodo di Agile per definirne i corretti passi di esecuzione.

Le organizzazioni di solito cercano metodi più specifici all'interno del movimento agile, Questi includono Crystal Clear, Extreme Programming, Feature Driven Development, Dynamic Systems Development Method (DSDM), Scrum, e altri. Lo Scrum è gestito da uno Scrum Master, in genere il manager di Progetto, che svolge attività di supporto in fase di anali e sviluppo , nell'identificazione dei processi di esecuzione degli obbiettivi finali.

Il prodotto software viene mantenuto in uno stato sempre potenzialmente pronto alla consegna, dunque funzionante e ben testato.

Alla fine di ogni Sprint di elaborazione e sviluppo le parti interessate dal lato sia Business che di sviluppo, si incontrano per delinearne possibili miglioramenti ed avanzamenti del medesimo prodotto.

2.6.2 Approccio Waterfall

L’approccio “waterfall” descrive la struttura del ciclo di vita di un progetto come una sequenza di fasi in cascata. Il ciclo di vita descrive le modalità di produzione degli obiettivi previsti e non va confuso con i processi di project management che invece costituiscono l’infrastruttura di governo di un progetto. In generale l’approccio sequenziale “waterfall” privilegia la prevenzione dei cambiamenti nell’ambito e nei requisiti del progetto dovuti a scarsa analisi e pianificazione e vede la stima dei costi e dei tempi come una conseguenza delle specifiche delle singole attività.

La struttura del ciclo di vita è tipica di uno specifico progetto in uno specifico contesto organizzativo. Ad esempio può essere articolata in:

➢ analisi dei requisiti; ➢ disegno;

➢ implementazione; ➢ test;

➢ installazione; ➢ manutenzione.

Punti di forza dell’approccio “waterfall” Punti di forza dell’approccio “waterfall” Punti di forza dell’approccio “waterfall” Punti di forza dell’approccio “waterfall”::::

➢ i requisiti sono ben definiti, concordati e formalizzati;

➢ molti potenziali difetti sono “intercettati” nelle fasi preliminari di analisi e pianificazione;

➢ la documentazione è dettagliata;

➢ può essere gestito con personale con skill non elevato in virtù del livello di dettaglio della documentazione;

➢ i vincoli temporali di ciascuna fase ed il piano dei rilasci consentono un agevole monitoraggio e controllo.

Punti di debolezza dell’approccio “waterfall” Punti di debolezza dell’approccio “waterfall”Punti di debolezza dell’approccio “waterfall” Punti di debolezza dell’approccio “waterfall”:

➢ il tempo necessario all’attività di analisi e pianificazione può ritardare l’implementazione;

➢ i requisiti, una volta formalizzati, possono essere modificati solo attraverso specifiche procedure di escalation;

➢ il cliente prende visione dei deliverable solo al momento del loro completamento;

➢ possono emergere esigenze di nuove funzionalità in corso d’opera che necessitano di un approccio più flessibile.

Gli approcci iterativi si concentrano sui tempi e costi di contratto e li gestiscono con una logica di tipo TimeBoxingTimeBoxingTimeBoxingTimeBoxing adattando di conseguenza l’ambito di progetto che rimane flessibile in funzione delle esigenze di rapidità di sviluppo e di massimo valore erogabile nei tempi e costi concordati.

Eventuali esigenze di modifica vengono raccolte e gestite all’interno di nuove release o versioni del prodotto.

In presenza di requisiti ben definiti e documentati un approccio integralmente “waterfall” è da preferire, mentre a fronte di esigenze e specifiche mutevoli è preferibile adottare approcci Agile ma all’interno di un sistema di governo complessivo del progetto.

2.6.3 Tabella KANBAN

Un valido aiuto alla modalità Agile, in supporto alla progettazione software è la tabella o lavagna Kanban, divisa per colonne.

Il termine Kanban deriva dal Giapponese e significa “Insegna”. Esso indica una metodologia di produzione basata su logica organizzativa di tipo “pull”, che si contrappone al metodo di produzione di Ford con la catena di montaggio (detto anche “Push”).

A differenza di quest’ultima, che puntava sulla produzione di massa, il Kanban (introdotto da Toyota negli anni 50) si propone di analizzare i fabbisogni dei consumatori per poi soddisfarli con un bene dalle specifiche caratteristiche e prodotto nelle corrette quantità.

In questo modo si evitano problemi di sovrapproduzione e nascono i famosi termini Just In Time e Lean Manufacturing, con cui Toyota ha fatto la sua fortuna, i quali prevedono di limitare al minimo le scorte di magazzino sufficienti per produrre un determinato prodotto in breve tempo.

Nel 2010, David Anderson scrive un libro in cui spiega come trasporre alcune caratteristiche del Lean Manufacturing anche al mondo della tecnologia e delle applicazioni software, consentendo di:

➢ visualizzare, misurare e gestire il flusso di lavoro;

➢ limitare i lavori lasciati a metà e andare a concludere tutte le attività; ➢ esplicitare agli addetti ai lavori le regole alla base del processo che

seguono;

➢ creare la possibilità di migliorarsi di continuo potendo sempre aggiustare il tiro in base all’analisi dei risultati.

Questo si ottiene tramite una lavagna suddivisa in colonne dove è riportato tutto il ciclo di lavoro; essa permette di mostrare a tutto il team quali sono i task in essere, chi se ne occupa, a quale stadio di avanzamento si trovano e, data la complessità del task e il suo grado di avanzamento nel flusso, quanti altri lavori possono essere seguiti in contemporanea in quello stato.

Vediamo che ogni persona ha ben chiaro quali sono i task che gli spettano all’interno del progetto e quanti steps dovrà effettuare affinché il suo lavoro venga completato. Più riescono a portare il loro task verso la destra del foglio, più vicini saranno al loro traguardo.

In basso a sinistra vediamo una riga dove vengono inseriti i lavori urgenti, che quindi hanno la priorità sugli altri.

La modalità più semplice da utilizzare per implementarlo è servirsi di un foglio excel e crearne uno stile tabellare come mostrato in figura:

2. 7 Sheduling in Framework Quartz

Quartz è una libreria di API che permette la gestione dello Sheduling del Job che esegue l'esecuzione dell'appplicazione web FSEVisualizer.

Ha poche dipendenze, ma richiede sempre almeno il file jar sl4j-api. Quartz offre numerosi vantaggi , analizziamo i principali:

• i processi possono essere configurati molto semplicemente, seguendo la sintassi delle familiari espressioni crontab di unix.

• i processi possono essere resi persistenti facilmente, perché possono essere memorizzati da qualche parte (ad esempio in una banca dati), ed essere ri-schedulati in fase di start-up dell’applicazione.

• i processi possono essere schedulati anche in un ambiente di cluster. • i processi schedulati e il loro flusso di esecuzione può essere monitorato

facilmente.

Le librerie di supporto al quartz sono: • commons-beanutils-1.7.0.jar • commons-collections-3.2.jar • commons-digester-1.8.jar • commons-logging-1.1.jar • jta.jar • quartz-1.6.2.jar

Per creare un processo “schedulabile” con Quartz, occorre definire una classe che implementa l’interfaccia org.quartz.Job. Tale interfaccia, definisce il metodo execute che dovrà essere implementato nella nostra classe. Il metodo execute riceve in ingresso un’istanza della classe JobExecutionContext che contiene tutte le informazioni sul processo in esecuzione, come ad esempio il suo nome, il suo gruppo di

appartenenza, l’orario di inizio elaborazione ed altro ancora.

Una volta fatto questo, è possibile implementare il codice con un metodo di start().

Un altro possibile sheduler presente sul mercato è il Timer ServiceTimer ServiceTimer ServiceTimer Service , un servizio del Container che consente di schedulare l’esecuzione dei metodi di tutti i tipi di session bean eccetto il tipo stateful. Possiamo schedulare il timeout di un Timer in diversi modi: come calendario, a singola azione dopo un tempo specificato, o come task che si ripete ad intervalli di tempo.

Un Timer può essere di due tipi: programmaticoprogrammaticoprogrammaticoprogrammatico o automaticoautomaticoautomatico. Un Timerautomatico programmatico viene creato utilizzando l’interfaccia TimerService, mentre un Timer automatico viene creato con il deploy di EJB che contengono metodi marcati con annotation java.ejb.Schedule o java.ejb.Schedules.

2.7.1. Multitrhead in Java

Sicuramente uno degli approcci intrinsechi del linguaggio Java , è la possibilità di gestire il multithreading grazie alle classi Thread e Runnable presenti nelle API. Grazie all'implementazione del metodo run(), esposto in Thread class, è possibile gestirne l'attivazione dei singoli Thread per singolo servizio da esplicare.

Ogni Thread può essere in stato di ready, wait, notify.

Nello stato di ready, il thread è in coda pronto ad eseguire un servizio; in wait è bloccato in genere in fasi di accesso a risorse condivise; e notify è in stato di ri-attività sull'utilizzo della risorsa in cui era stato bloccato in wait.

La gestione della concorrenza su risorse condivise è in particolare modo delineata dall'utilizzo di metodi di tipo Synchonized, i quali racchiudono parti di codice identificate come sezioni critiche.

Sono sezioni di codice che necessitano transazioni rispecchianti le proprietà ACID (Atomicità, Coerenza, Isolamento e Durabilità) della persistenza e consistenza dei dati acceduti in data base.

Le operazioni si definiscono atomiche in quanto devono essere completate prima di rilasciare la risorsa ad altri.

La gestione della coda dei processi di threading dipende dalla Virtual Machine in uso, ma in genere è possibile indicare una priorità di esecuzione su determinati Thread rispetto che in altri.

Quindi usando una funzione di timer(), è possibile delineare una sequenza di attività di esecuzione della classe Job di riferimento , schedulando senza usare framework esterni da importare e configurare.