Industria 4.0, la struttura del software

(this post is in italian only)
E' inutile dire che industria 4.0 sia un termine molto gettonato ultimamente. Esso racchiude quello che si prospetta essere un nuovo giro di boa per il sistema manifatturiero italiano dove il software entrerà pervasivamente in tutti gli aspetti della catena produttiva. Questo avrà degli effetti non di secondaria importanza che, a mio avviso, è bene mettere in luce sin da ora.

La visione di fondo

Prima di addentrarci in qualche aspetto di dettaglio credo che sia importante mettere a fuoco la visione di fondo che sottende il processo dell'industrializzazione 4.0. Il primo slogan che si potrebbe mettere in evidenza è il seguente:

"Quasi ogni cosa può essere digitalizzata ed automatizzata. Quasi ogni cosa può essere descritta da un modello matematico e da un insieme di dati."

Ma abbiamo capito tutti cosa significa? L'idea è comprendere bene cosa comporti questa digitalizzazione pervasiva di cui si parla per cercare di indirizzarla dove vogliamo noi e non dove vogliono gli altri.

Il problema vero infatti sarà stabilire il dove noi vogliamo che vada perché allo stato attuale, dal punto di vista delle tecnologie ICT, percepisco il paese Italia (nel suo insieme) come un paese che sostanzialmente consuma tecnologie ICT producendone poche e questo aspetto ci fa partire con un po' di ritardo rispetto ad altri paesi che invece governano meglio questo settore. Ma prima di andare avanti facciamoci un'altra domanda non scontata: l'idea di non prendere parte a questa rivoluzione è perseguibile? E' possibile cioè rimanerne fuori? Sarò franco, anche se non ho la sfera magica per leggere il futuro, credo veramente che non prendere parte a questa rivoluzione significhi solamente accettare di andare verso il declino industriale. Cerchiamo allora di mettere a fuoco il valore aggiunto che potrebbe portarci industria 4.0.

Il vero valore aggiunto è quello di essere adattabili come gli artigiani ma veloci e precisi come l'industria

A prima vista il valore immediato sembrerebbe essere quello di aumentare l'automazione per ridurre i costi su larga scala. Ciò è senz'altro vero ma questo era il valore aggiunto che si inseguiva con industria 3.0 quella cioè in cui siamo tutt'ora immersi non con quella 4.0 in cui stiamo per entrare. L'abbassamento dei costi è certamente un aspetto da non sottovalutare ma personalmente non credo che sia questo qui il punto fondamentale. In realtà il vero valore aggiunto è da ricercarsi nel raggiungimento di una fascia alta del valore ossia  in una maggior capacità di adattamento e in una maggiore flessibilità di risposta alle esigenze del mercato.

Avete presente l'artigiano che fondamentalmente si adatta alle richieste del cliente al momento?

"Fammi l'angolino più smussato perché a me piace più così, a poi se in quell'angolo mi ci metti un forellino io poi ci posso attaccare il quadro del nonno che ci tengo tanto".
"Va bene"

L'artigiano dice "va bene" perché lui, che conosce sé stesso e domina la sua arte è in grado di capire come meglio soddisfare le esigenze del cliente, che magari conosce pure personalmente, ed è in grado di adattare con creatività il proprio lavoro utilizzando gli strumenti più opportuni sul momento. Il risultato finale è un prodotto unico, perché unica e personale è la richiesta del cliente ed unica e personale è la capacità dell'artigiano di soddisfarla. Questo è il valore "alto" che va ricercato con industria 4.0. Se non siete d'accordo ditelo, ne parliamo.

L'unicità della relazione

La domanda che dobbiamo farci ora è capire il perché sia necessario perseguire questa strada andando a cercare il valore aggiunto nella capacità di sapersi adattare in modo flessibile. Qui la questione si fa un po' più complessa perché bisognerebbe dotarsi di sfera magica e poter osservare il futuro per poi stabilire quale sia effettivamente la scelta migliore. Chiaramente nessuno può dire con certezza quale sia la strada maestra da seguire, il futuro come sempre è imperscrutabile per chiunque. Tuttavia, un elemento fondamentale può essere colto. Ad oggi la varietà di prodotti disponibili sul mercato è impressionante, di qualsiasi oggetto ne esistono versioni di tutti i tipi per tutti i portafogli, di tutte le qualità. Ho appena digitato la parola violino su Google Shopping e mi si è aperta l'opportunità di comprare un violino da 49 euro così come di acquistarne uno da 8.206,90 euro. Entrambi sono potenzialmente acquistabili da me con pochi click ed una carta di credito. Il pacco verrà recapitato a casa. E' già così senza bisogno di alcuna rivoluzione 4.0. Lo sappiamo tutti. Non è una novità. Che cos'è dunque, nel prossimo futuro, quello che potrebbe differenziare il nostro prodotto o il nostro servizio in mezzo ad un bazar mondiale di queste dimensioni? L'unica possibilità che vedo è quello di rendere il prodotto unico per chi lo compera ed anche per chi lo vende. E l'unico modo di renderlo unico è quello di realizzarlo secondo le esigenze dell'acquirente e secondo l'esperienza del produttore. Fatta questa osservazione diventa evidente come la centralità di tutto passi per la capacità di rendere unica la relazione con l'acquirente, unica l'esperienza di acquisto, unico il prodotto finale ma industrializzata la produzione.

Digitalizzazione, creatività e software come struttura portante

date queste premesse, a mio avviso sono tre gli aspetti fondamentali che vanno presi in considerazione:

1) Una automatizzazione pervasiva di tutte le attività ripetitive.
2) Valorizzazione del personale umano mirato all'aumento della responsabilità individuale e della creatività.
3) Gestione del software annoverata tra le attività principali del sistema industria

Per quanto concerne il primo punto che è quello di carattere tecnico l'idea di fondo è abbastanza semplice: evitare di utilizzare il lavoro umano laddove esso sia solamente un'attività ripetitiva ed automatizzabile. Si tratta chiaramente sempre di fare un bilancio tra costi e benefici ma in generale è inutile sprecare del lavoro umano per fare cose che può fare una macchina. Non ha davvero senso, pensateci. Il concetto qui è che il lavoro umano è un bene prezioso e di valore e per questo motivo non va sprecato.

Occhio però! Perché a prendere troppo alla lettera questa cosa si rischia poi di andare ad automatizzare ciò che non va automatizzato! E sapete quali sono le cose che non si possono automatizzare? la responsabilità e la creatività caratteristiche eccezionali dell'essere umano delle quali ne avrete sempre più bisogno! La cosa interessante è che c'è un motivo logico ed evidente che porta a questa conclusione. Va da sé infatti che se i lavori ripetitivi vengono svolti dalle macchine all'uomo restano quelli non ripetitivi che sono strettamente legati alla capacità di pensiero autonomo (responsabilità) ed alla capacità di avere un pensiero in grado di immaginare (creatività).
Ed è da questa riflessione che passiamo al punto 2) ossia la creazione di un ambiente di lavoro che enfatizzi queste abilità umane.

Alle macchine diamo perciò il compito di essere veloci e precise ed agli uomini lasciamo il compito di essere adattabili e flessibili. Quello che ci manca è solo una cerniera di comunicazione tra il mondo delle macchine e quello dell'uomo, ossia il punto 3: il software.

Il software come sistema nervoso essenziale che unisce la macchina all'uomo

Se idealmente possiamo dire che la macchina o le macchine rappresentano il corpo del nostro sistema azienda 4.0 e la componente umana ne rappresenta il cervello (ed il cuore), allora il software rappresenta il sistema nervoso che permette di trasportare i giusti impulsi dal cervello al corpo. Per questo motivo è molto importante dare la giusta attenzione al sistema informativo che andremo ad utilizzare poiché il risultato finale dipenderà molto da esso. Un sistema informatico mal concepito o mal gestito potrebbe essere infatti la prima causa di rallentamenti, inefficienze se non addirittura di blocco anche in presenza di una buona digitalizzazione e di una buona organizzazione del personale.

Quando si parla di informatica, in generale ricordatevi sempre di una massima che vale sempre:

"Si può fare tutto, dipende solo da quanto sei disposto a pagare"

Quindi il problema non è tanto capire se si può raggiungere un determinato obiettivo andando ad intervenire sul proprio sistema informativo. In generale, a meno che non si parli di viaggi  nel tempo o cose simili, la maggior parte delle esigenze legate all'informatizzazione sono tecnicamente possibili e realizzabili. Il problema è sempre capire quanto costa farlo.
Il vero obiettivo quindi che dovremo porci riguardo alla struttura del nostro sistema informativo è quello di realizzarlo in modo tale da minimizzare i costi di intervento in caso di modifiche e/o cambiamenti perché, credetemi, se intraprenderete una strategia 4.0 di modifiche ne avrete infinite, continuamente, tutti i giorni, le modifiche del software saranno il vostro pane quotidiano. Ed è per questo che il vostro sistema software deve essere sufficientemente elastico da poter essere plasmato e modellato all'occorrenza senza farsi male ogni volta.

Un elefante che si muove troppo lento

Fino ad oggi siamo stati abituati a vedere il sistema informativo aziendale come un insieme di software ciascuno dei quali nato per risolvere un problema specifico. Così abbiamo il gestionale per gestire la parte amministrativa, il sito web per farci trovare su Internet, il sito di ecommerce per vendere online i nostri prodotti, il documentale per archiviare i documenti, il software per la supply chain per gestire la catena di distribuzione, ecc. Tutti questi prodotti hanno sempre funzionato separatamente ed indipendentemente uno dall'altro e tutte le volte che abbiamo avuto la necessità di collegarli abbiamo richiesto un intervento di system integration andando a pianificare un'attività specifica per passare i dati che ci servivano da una parte all'altra. Così è possibile per esempio che per far comunicare l'ecommerce con il gestionale dobbiate esportare dei file su una cartella condivisa e poi schedulare un job di sincronizzazione periodico per effettuare l'importazione. Oppure è possibile che l'integrazione avvenga tramite chiamata a web service, oppure ancora, nei casi peggiori, i dati vengono portati manualmente da un applicativo ad un altro. Questa struttura, anche detta architettura, la potremmo vedere come un grande edificio all'interno del quale ci sono diversi uffici ciascuno dei quali è dedicato ad un'attività specifica. In ognuno di questi uffici ci sarà personale dedicato adibito ad assolvere a determinate funzioni e così via. I diversi uffici si scambiano dei documenti e delle informazioni per poter svolgere le loro funzioni con modi diversi: in alcuni casi si mandano un fax, in altri casi i dipendenti si telefonano, in altri casi ci sono addetti alla posta interna per lo scambio dei documenti.

Un'architettura di questo tipo verrà messa a dura prova da una strategia industria 4.0 e potrebbe rischiare di non reggere al carico. I motivi sono i seguenti:

1. Il costo da sostenere per le modifiche potrebbe essere esorbitante rispetto alle nuove funzionalità richieste. In molti casi si è costretti addirittura a rinunciare. Questo è il limite principale al quale si andrà incontro poiché lo scenario a tendere che vi dovete immaginare per industria 4.0 non è quello di effettuare interventi sul sistema informativo con una periodicità di un paio di interventi all'anno bensì con una periodicità settimanale se non addirittura giornaliera. Saranno più probabili cioè scenari in cui dovrete fare cambiamenti piccoli ma frequenti piuttosto che cambiamenti importanti ma distanziati negli anni. E questa assunzione porta con sé almeno due conseguenze immediate:
1. I prodotti che acquistate devono poter essere modificati ed adattati nelle loro funzionalità frequentemente. Questa cosa come immagino sappiate tutti porta a delle complicanze poiché una modifica nativa su un software commerciale non è generalmente a buon mercato, senza parlare poi dei tempi sia di analisi che di sviluppo che sono necessari per realizzarli. Spesso è più semplice rinunciare (cosa in contraddizione con l'adattabilità di cui abbiamo parlato sopra).
2. I flussi di interscambio dati tra diversi software devono poter essere cambiate frequentemente. Le modalità di integrazione tra i diversi applicativi sono quasi sempre diverse e create ad hoc. Spesso sono poco documentate e la loro gestione, nel peggiore dei casi, viene tramandata oralmente tra gli addetti ai lavori. Le responsabilità su di chi sia la competenza della gestione degli errori riguardanti questi flussi di interscambio è spesso vaga ed ambigua, nella peggiore delle ipotesi è distribuita su più fornitori diversi i quali si rimpallano le responsabilità pur di non doversene sorbire il carico. La gestione di progetti di integrazione è già complessa ad oggi visto che in generale richiede la partecipazione di più fornitori. Come per il punto sopra, per piccole modifiche il gioco potrebbe non valere la candela (ancora, siamo in contraddizione con quello che vogliamo raggiungere come obiettivo)
2. Spesso gli applicativi sono più potenti di quello che ci serve. In generale gli applicativi che si acquistano sono concepiti per essere generali e coprire più casistiche possibili ed hanno tantissime funzionalità al loro interno (se ci pensate è ovvio poiché solamente in questo modo si può allargare la fascia di mercato a cui vendere il prodotto). Sono ottimi per come sono stati concepiti non c'è dubbio, ma con ogni probabilità voi utilizzerete solamente una parte limitata di queste funzionalità. Per questo motivo, ogni volta che ne acquistate una porterete all'interno del vostro sistema informativo tante funzionalità software di cui non avete bisogno e che non userete ma che comunque devono essere continuamente aggiornate, mantenute ed organizzate insieme a quelle che usate da parte del produttore. Questo dipendenza indiretta verso funzionalità a voi non utili vi potrebbe creare problemi nel momento in cui ci sono da effettuare gli aggiornamenti.
3. Molti degli applicativi in commercio purtroppo sono scarsamente integrabili e vincolati ad essere utilizzati su piattaforme ben definite. Nati nei decenni passati si portano dietro impostazioni di creazione del software dove al centro venivano messe le capacità di calcolo e poco la comunicazione con altri applicativi. Per questo motivo i produttori di applicativi che non hanno aggiornato le loro logiche propongono ancora applicativi fondamentalmente vecchi e difficili da integrare con altri se non attraverso sistemi come lo scambio file. Inoltre, molti applicativi sono ancora fortemente accoppiati alla piattaforma sottostante, per esempio è molto comune trovare installati applicativi che funzionano solamente su sistemi operativi di marche specifiche. Nonostante questi applicativi possano essere di ottima qualità, voi utilizzatori finali vi ritroverete con una funzionalità software che vi vincolerà ad acquistare altre componenti software a supporto (es: sistema operativo). In molti casi sarete persino obbligati ad acquistare macchine specifiche con un taglio specifico solo per poterli tenere attivi.
4. Ogni applicativo si porta con sé i servizi di manutenzione ed aggiornamento ad esso collegati che vengono forniti dal produttore stesso o dal suo rivenditore. Questo significa che ogniqualvolta vi servano delle modifiche specifiche per quelle funzionalità sarete costretti a negoziarle con il fornitore stesso che, qualora si tratti di modifiche particolari che non rientrano all'interno di quelle da lui pianificate, potrebbe persino negarvi la possibilità di poterle realizzare.

Tutti questi elementi fanno sì che il vostro sistema informativo si trasformi in un elefante estremamente lento e poco propenso al cambiamento. Esattamente ciò che non vi potrete permettere pena il fallimento di tutta la strategia industria 4.0.

Un alveare operoso

Se dovessimo tentare di dare un'idea verso cui far tendere il nostro sistema informativo, quella dell'alveare operoso potrebbe certamente essere più vicina alla realtà. Un sistema informativo in ottica industria 4.0 ce lo dobbiamo immaginare infatti come un cantiere sempre aperto e sempre attivo in cui le diverse componenti vengono continuamente aggiornate e continuamente modificate. Ma quali sono le linee guida che dobbiamo seguire per costruire un sistema informatico di questo tipo?

1. Funzionalità software piccole e facilmente modificabili in tempi brevi
2. Funzionalità software estremamente facili da integrare una con l'altra
3. Funzionalità software indipendenti da altre componenti per noi ininfluenti (es: sistemi operativi)
4. Possibilità di modificare l'architettura in modo semplice

Tecnicamente parlando la maggior parte dei sistemi informativi aziendali è ad oggi abbastanza lontana da questo scenario, tuttavia già oggi è possibile iniziare a costruirsi il proprio sistema "alveare" in casa iniziando a considerare le seguenti linee guida:

1.  Dal punto di vista infrastrutturale sicuramente il Cloud è la strada maestra da seguire. L'idea della risorsa computazionale intesa come computer che sta nella scrivania va abbandonata. La risorsa computazionale è anch'essa un'entità software. Inutile esitare. Laddove per diversi motivi è richiesta un'infrastruttura privata di risorse computazionali, allora esse dovrebbero comunque essere configurate per essere utilizzate come un sistema cloud privato.
2. Dal punto di vista della virtualizzazione la strada dei container è sicuramente al momento la più promettente. Essa permette di abbandonare l'astrazione della macchina virtuale per iniziare a ragionare in termini di risorsa computazionale come ambiente minimo e sufficiente all'esecuzione di un applicativo o di una funzionalità software. I container inoltre permettono di spostare le componenti software in modo semplice e veloce in modo indipendente dalle piattaforme cloud sottostanti.
    
3. Dal punto di vista dello sviluppo applicativo invece la strada dei servizi e dei microservizi è quella che andrebbe seguita poiché consente di realizzare funzionalità mirate più piccole facilmente modificabili e manutenibili. Per cercare di darvi l'intuizione di cosa possa significare un'impostazione dello sviluppo software orientato ai servizi e/o ai microservizi, potreste pensare alle vostre funzionalità software come ad un grande scatolone di mattoncini lego che poi potete comporre gli uni con gli altri per ottenere di volta in volta quello che è più utile per le vostre esigenze.

L'idea finale è che il nostro sistema informativo ci appaia come un insieme di componenti software che comunicano tra di loro e che possono essere connesse, spostate, cambiate e modificate semplicemente in base alle nostre esigenze.

Ogni azienda è una piccola software house

E' chiaro che così come un alveare non produce miele senza api ed uno scatolone di lego non diventa un'astronave senza qualcuno che si preoccupi di darle quella forma, così anche un sistema informativo concepito e costruito per essere molto flessibile ed adattabile non potrà mai dare origine ad alcun risultato sensato senza nessuno che si preoccupi di gestirlo e "programmarlo".

Il sistema informativo deve diventare parte del core business di ogni azienda e non può più essere interpretato come un appendice al servizio di altre attività dell'azienda. Per questo motivo se di core business si tratta, il suo funzionamento dovrà essere conosciuto e controllato dall'azienda stessa. Un'impostazione che mira unicamente a gestire i fornitori esterni non può più essere sufficiente, diventa necessario portarsi in casa una parte di quel lavoro per poterlo gestire con responsabilità in prima persona. Chiaramente non è pensabile l'idea di portarsi in casa qualunque aspetto e funzionalità, ciò sarebbe assurdo, sicuramente però la maggioranza delle funzionalità che hanno a che fare con i processi di business e di relazione con il cliente andrebbero riportate all'interno così da mantenere un effettivo controllo su tutto il sistema informativo.

Questa osservazione porta all'ineludibile conseguenza di iniziare a pensare i propri comparti ICT come delle vere e proprie software house in grado di produrre il proprio software necessario alle proprie esigenze. 

Gestire la transizione

Chiaramente quello che abbiamo descritto qui sopra è solamente il punto di arrivo per cercare di centrare quell'obiettivo di flessibilità e di adattabilità di cui abbiamo parlato. Il nostro consiglio è quello di arrivarci gradualmente compatibilmente con le vostre possibilità senza cercare di strafare. La cosa importante è prendere consapevolezza del percorso da compiere ed iniziare a predisporsi, passo dopo passo, per il suo raggiungimento.  Alcune cose importanti si possono già iniziare a tenere sott'occhio:

1. Nei limiti del possibile, iniziate la transizione verso il cloud computing ed anche laddove dobbiate lavorare con macchine vostre, cercate comunque di vederle solo come supporto per macchine virtuali. Per chi ha già compiuto questo passo, vale la pena iniziare a valutare la tecnologia a container.
2. Evitate se possibile tutti i software che non prevedano un'interfaccia utente web (da utilizzare cioè mediante browser) ma che richiedano l'installazione di un applicativo locale alla vostra macchina. A meno che un tale requisito non sia necessario per particolari problemi di sicurezza, evitate questa configurazione il più possibile. La necessità infatti di installare uno specifico applicativo sulla macchina di ogni utente dal punto di vista della gestione è un freno.
3. Per qualsiasi software che si sta pianificando di acquistare porre tra i requisiti tecnici minimi per la sua accettazione la presenza di moduli che lo abilitino ad essere facilmente integrato (presenza di API REST o Web Service). Assicuratevi che il prodotto già abbia a catalogo tali moduli e cercate di capire bene cosa comporta, in termini di costi e licenze il doverli adottare. Tale requisito dovrebbe diventare uno standard e non un optional, un po' come richiedere che un'auto abbia il volante. In caso tali moduli non siano presenti il nostro consiglio è quello, se possibile, di scartare il prodotto a beneficio di altri che invece hanno queste caratteristiche.
4. Date priorità a software multi-piattaforma, ossia software in grado di essere lanciati in più ambienti diversi e nei limiti del possibile cercate di evitare quelli che vi obbligano ad un'unica piattaforma di supporto.
5. Se non lo avete già fatto iniziate ad introdurre software open source all'interno del vostro sistema informativo. Ricordatevi però che questa operazione va fatta considerando sempre la necessità di introdurre poi personale interno in grado di di assumersene la responsabilità e prendersene cura. In alternativa meglio andare su un software commerciale.
6. Se non lo avete già fatto iniziate un'attività di documentazione del vostro sistema informativo inteso come mappatura delle funzionalità software che avete, i loro costi, i supporti che richiedono ed i dati che si scambiano e che hanno in comune con gli altri software. Iniziate anche ad analizzare i flussi di dati e domandatevi se in molti casi non possiate automatizzare qualche procedura per far fare qualche cosa alle macchine piuttosto che agli esseri umani. Ricordatevi questa massima: i lavori ripetitivi fateli fare alle macchine!
7. Iniziate a pianificare un graduale aumento dei budget per l'ICT con corrispondente aumento del personale dedicato. Considerate sempre che il vostro team ICT non deve solo produrre software con la testa fissa sulla tastiera ma deve anche sapersi guardare intorno, sapersi aggiornare ed essere esso stesso flessibile ai cambiamenti. Cercate quindi sempre di arricchire il team anche con personalità creative che oltre ad avere le capacità tecniche per comprendere il sistema siano anche in grado di cercare soluzioni nuove e sperimentali. A questo proposito ricordatevi di iniziare a ritagliare una parte del budget per le sperimentazioni. Vi serviranno per permettere al vostro team di essere più confidente con quello che sta facendo e vi serviranno soprattutto per evitare di buttarvi in nuove avventure IT senza sapere bene dove state andando. Fidatevi.
8. Iniziate a considerare seriamente l'idea di avere un piano di formazione continua per il vostro personale. Ricordatevi che agli esseri umani dovrete affidare due compiti molto importanti: responsabilità e creatività. Per portarli a termine nel migliore dei modi avranno bisogno di essere continuamente aggiornati su quello che sta succedendo intorno a loro. L'idea che un essere umano debba essere competente solamente su un unico aspetto tecnico dell'azienda è per noi definitamente tramontata e certamente non può reggere in un'ottica di industria 4.0, abbiate cura quindi di condividere maggiormente il contesto in cui l'azienda si muove con i vostri dipendenti. L'agire responsabile e creativo nasce da una buona conoscenza del contesto.

JDM: Jolie Database Manager for PostgreSQL database

Here we host a post from Danilo Sorano who collaborated with us and the Jolie team during his training period at Imola Informatica and italianaSoftware. The training period of Danilo is part of his studies at the University of Bologna. Danilo chose to work on a project about Jolie and databases. In particular, he contributed to develop a tool for automatically extracting a jolie service which facilitates the interactions with an existing database in PostgreSQL.

Congratulations to Danilo! His post follows:

JDM

Jolie Database Manager for PostgreSQL database by Danilo Sorano

The jolie database manager is a tool whose goal is to create a facilitator for the management of PostgresSQl data sources by using microservices. The tool can be get on github: https://github.com/jolie/db_connector

The main purpose of JDM is to simplify database management operations, specifically the simplifications of the insertion, modification, deletion and retrieval of data. The tool has been designed for preventing the user to write standard queries on tables and views which can be easily automatized.

Usage instructions:

1. Creating the database and tables / views. Only if you are creating a database from scratch. Otherwise skip this step. 
2. Start the JDM server running main_table_generator.ol inside folder server
3. Configure the information necessary to connect with the database (file config.ini)
4. Start the client running createDbService.ol inside folder client
5. In folder db_services all the files will be generated: Metadata extraction from the database and creation of the service for the database.

The database service is divided in two parts:

• Automatic service
• Custom service

The automatic part provides basic operations for the database:

• Create: INSERT query
• Update: UPDATE query
• Remove: DELETE query
• Get: SELECT query

The management of more complex operations such as JOIN between tables must be managed by creating view by the user.

The custom part allows for  the development of customized query on the database and it can be freely edited by the user. This function gives to the user the possibility of being able to create the most complex operations, for example, to manage nested query.

From an architectural point of view, the database service's main part  embeds the custom part and automatic one. This mechanism allows the two parties to be independent of each other, thus allowing the modification of the automatic part every time that, for example, is added to a view without going to change the custom part.

Example: Creation of a database service In order to explain how the tool works we will use the example contained in the folder "examples", where there is a file sql "e-commerce.sql" to be used to generate the test database. The file creates a database of a simple e-commerce with three tables. The three tables are:

• user (fiscal code, name, surname, email)
• product (bar code, product name, description, quantity)
• order (Order id, product id, user id, quantity)

The service can be used by changing the information in the file "config.ini” [db_connection] HOST=localhost DRIVER=postgresql PORT=5432 DATABASE=e-commerce USERNAME=postgres PASSWORD=postgres

Creating a service for a database

1. Creation of PostgreSql database and its tables and views (It's possible using the e-commerce example.
2. Starting the Tool for generate the service (main_table_generator.ol)
3. Change the information in the config.ini file.

WINDOWS

• Start the script server TableGenerator.bat
• Start the script client CreateDbService.bat
• If everything went well the service is created

OTHER OS

• Go in the folder "server" and run the jolie file "main_table_generator.ol
• Go in the folder "client" and run the jolie file "createDbService.ol
• If the creation of the service is successful, the server print the message: “Database table generation is finished with SUCCESS”.

Using the service of the example The generated service for the example of the e-commerce is divided into two parts:

• automatic
• custom

The automatic part is represented by the file main_automatic_ecommerce.ol which contains the operations:

• createuser, createproduct and createorder
• getUser, getproduct and getOrder
• updateUser, updateproduct and updateorder
• removeuser, removeproduct and removeorder.

On the other hand, the custom part as mentioned above, allows the user to create his own customized operations. Example of a client File try_operations.ol in the example, shows the usage of the basic operations of the automatic part. The file is structred as it follows:

1. Importing of the interface and the location
   include"../db_services/e_commerce_handler_service/automatic_service/public/interfaces/includes.iol"
   include "../db_services/e_commerce_handler_service/locations.iol"
   
2. Creation of an output port for the service
   outputPort Test {
   Location: e_commerce
   Protocol: sodep
   Interfaces: userInterface, orderInterface, productInterface
   }
   Note that the default location is "socket://localhost:9100" taht is contained inside the file locations.iol
3. Inside the main you can make the call to the service operations. 

The Filter Before introducing the individual operations it is better to explain the filter field. The filter field is a FilterType type which is defined inside "automatic_service/public/types/e_commerceDatabaseCommonTypes.iol" type ExpressionFilterType: void { .eq?: bool .gt?: bool .lt?: bool .gteq?: bool .lteq?: bool .noteq?: bool } type FilterType: void { .column_name: string .column_value: any .expression: ExpressionFilterType .and_operator?: bool .or_operator?: bool } The filter field is important to define the where clause of the query:.

• column_value: value of the colum
• column_name: name of the column of the expression
• expression: the operator used to check the value, this is an ExpressionFilterType
• and_operator: we define this field only if we want to concatenate another expression, in this case an AND operator
• or_operator: we define this field only if we want to concatenate another expression, in this case an OR operator

The ExpressionFilterType define the operator:

• lteq: "<="
• eq: "="
• gt: ">"
• lt: "<"
• gteq: ">="
• noteq: "!="

As an example, let us suppose to define the following where clause "WHERE 'product_name' = 'Fried Chicken' AND quantita >= 10": getproductRequest.filter.column_name = "product_name"; getproductRequest.filter.column_value = "Fried Chicken"; getproductRequest.filter.expression.eq = true; getproductRequest.filter.and_operator = true; getproductRequest.filter[1].column_name = "quantity"; getproductRequest.filter[1].column_value = 10; getproductRequest.filter[1].expression.gteq = true; Example of a Get operation To select one or more row in the product table of the e-commerce example we use the operation getproduct getproduct( getproductRequest )( getproductResponse ) throws SQLException SQLServerException It is worth noting that the fields inside the request type is only the filter fields. type getproductRequest:void { .filter*:FilterType } In the response message we will get the rows of the select query type getproductRowType:void { .id_product:int .product_name:string .description:string .quantity:long } type getproductResponse:void { .row*:getproductRowType } This operation select one or more row inside the product table. Here an example of the call: /*Get of the all rows of “Fried Chicken” with the quantity equal or greater then ten*/ getproductRequest.filter.column_name = "product_name"; getproductRequest.filter.column_value = "Fried Chicken"; getproductRequest.filter.expression.eq = true; getproductRequest.filter.and_operator = true; getproductRequest.filter[1].column_name = "quantity"; getproductRequest.filter[1].column_value = 10; getproductRequest.filter[1].expression.gteq = true; getproduct@Test(getproductRequest)( response ); Example of a Create operation To insert a row in the user table we use createuser operation createuser( createuserRequest )( createuserResponse ) throws SQLException SQLServerException - createuserRequest The fields inside the request type are the fields of the user table. type createuserRequest:void { .fiscalcode:string .name:string .surname:string .email:string } - response: createuserResponse it's a void type This operation insert a row inside the user table, to understand better how it’s work we show an example: /*The user John Silver is inserted inside the user table*/ createuserRequest.fiscalcode = "1"; createuserRequest.name = "John"; createuserRequest.surname = "Silver"; createuserRequest.email = "john.silver@mail.com"; createuser@Test(createuserRequest)(); Example of a Remove operation To insert a row in the user table we use removeuser operation removeuser( removeuserRequest )( removeuserResponse ) throws SQLException SQLServerException - removeuserRequest There is only one filter fields, where specify the condition of WHERE clause type removeuserRequest:void { .filter*:FilterType } - response: removeuseResponse it's a void type This operation remove one or more row inside the user table, to understand better how it’s work we show an example: /*In this case we remove the user John Silver*/ removeuserRequest.filter.column_name = "surname"; removeuserRequest.filter.column_value = "Silver"; removeuserRequest.filter.expression.eq = true; removeuser@Test(removeuserRequest)(); Example of an Update operation To update one or more rows in the user table we use updateuser operation updateuser( updateuserRequest )( updateuserResponse ) throws SQLException SQLServerException - updateuserRequest The fields inside the request type are the fields of the user table and filter field type updateuserRequest:void { .fiscalcode?:string .name?:string .surname?:string .email?:string .filter*:FilterType } - response: updateuserResponse it's a void type This operation update one or more row inside the user table, to understand better how it’s work we show an example: /*Changing the surname of John from “Silver” to “Smith”*/ updateuserRequest.surname = "Smith"; updateuserRequest.filter.column_name = "surname"; updateuserRequest.filter.column_value = "Silver"; updateuserRequest.filter.expression.eq = true; updateuser@Test(updateuserRequest)(); Future features

• Ability to integrate the service, for more Database (Postgres, MySql ecc...).
• Possibility to extend the management of most types and especially more complex.

Contact

• Danilo Sorano's LinkedIn Profile 

1. C

2. 
   

L'esperienza del Meeting On Microservices 2016! (in italian)

Il 20 Dicembre si è svolto a Bologna il Meeting on Microservices (MoM) organizzato da italianaSoftware al fine di creare un primo momento di incontro tra aziende, pubbliche amministrazioni e mondo della ricerca sul tema dei microservizi. Siamo molto contenti che l'evento abbia avuto successo ed abbia visto la partecipazione di un buon numero di interessati ed una serie di interventi davvero stimolanti. Come prima conclusione a seguito di questa giornata, si può sicuramente affermare che il tema "microservizi" è ad oggi un tema di assoluto interesse e che tutti gli addetti ai lavori sono intenzionati a conoscere e a comprendere maggiormente le opportunità ed i rischi che questo nuovo approccio architetturale può offrire.

L'elemento positivo della prima edizione del MoM è certamente quello di essere riuscito a mettere insieme punti di vista sia teorici ed accademici che casi pratici d'uso di quelle aziende che per prime hanno implementato soluzioni orientate ai microservizi. La cosa probabilmente più rilevante che qui ci preme mettere in risalto è come questa soluzione architetturale possa essere adottata da aziende di tutte le dimensioni per risolvere i problemi più disparati. Le presentazioni di Monrif ed H2B hanno illustrato come si possano gestire con i microservizi sia i flussi di archiviazione documentale che l'implementazione di una vera e propria piattaforma B2B. Sicuramente va sottolineato come la loro adozione necessita di ripensare alcuni dei processi esistenti per la progettazione e la programmazione del software e che tante sfide si aprono ora nel mondo IT a seguito dell'adozione dei microservizi. Da una parte l'analisi ed il design dell'architettura diventano passi fondamentali per tutti i team IT che intendono adottare i microservizi e dall'altra molte attività che vengono generalmente esternalizzate possono ora essere riportate all'interno producendo da una parte risparmio e dall'altra una risposta più celere alle esigenze del business.

Il dibattito sui microservizi è appena entrato nel vivo e nei prossimi anni siamo certi che si riparlerà a più riprese di essi. Noi, come italianaSoftware ci saremo e lavoreremo affinchè il MoM possa diventare un evento periodico di carattere nazionale che possa diventare un riferimento per tutti coloro che sono interessati all'argomento.

Di seguito riportiamo l'elenco delle presentazioni con un brevissimo riassunto sui loro contenuti.

Genesi di una tecnologia, dalla ricerca all'industria... - Maurizio Gabbrielli (DISI - Università di Bologna)
Innovare è una sfida sempre difficile dove la possibilità di sbagliare deve essere considerata sin dall'inizio. Lo sviluppo e la maturazione della tecnologia Jolie sono un caso di studio interessante dove dallo sviluppo di un modello matematico si è riusciti a passare ad un linguaggio di programmazione che porta benefici al mondo produttivo.

La rivoluzione dei microservizi - Claudio Guidi (italianaSoftware)
I microservizi promettono di rivoluzionare il modo di progettare e programmare software. italianaSoftware propone una tecnologia specifica per affrontare la programmazione dei microservizi: jolie. Essa si distingue perché propone di approcciare i microservizi tramite un paradogma linguistico piuttosto che tramite un paradigma sistemistico che è quello più conosciuto fino a questo momento.



Implementazione di una soluzione a microservizi: benefici organizzativi ed economici - Balint Maschio (Monrif s.p.a.) Monrif s.p.a. ha iniziato ad utilizzare soluzioni a microservizi inizialmente per risolvere i problemi di system integration legati all'archiviazione documentale da ambiente SAP verso applicativi di terze parti. Ora ha iniziato a creare veri e propri flussi tramite micro-orchestratori dedicati.

Industria 4.0, come verrà rivoluzionata l'industria italiana - Paola Perini (Innovami) Industria 4.0 è la nuova parola chiave con la quale si vuole descrivere il processo già in atto di rivoluzione del settore industriale italiano dove "ogni azienda si dovrà trasformare anche in un'azienda software".


H2B e i microservices: un caso di successo - Alessandro Suzzi (H2B) I microservizi hanno aiutato H2B nel realizzare sia il loro applicativo ad agenti che i portali web B2B per la gestione del catalogo prodotti e degli ordini per un insieme di aziende nel settore delle ferramente gestite da H2B.
Dalle Service Oriented Architectures (SOA) ai microservizi - Claudio Bergamini (Imola Informatica) Service Oriented Architectures e microservizi vengono spesso accoumnati e confrontati tra di loro. Il tema è sicuramente interessante, entrambe posano le proprie radici sull'idea di servizio come componente seppure con differenze implementative. Di certo c'è che sarà l'analisi specifica dei diversi scenari di utilizzo a stabilire dove sia meglio adottare l'una o l'altra soluzione.
Devops, Cloud e Container - Luca Acquaviva (Imola Informatica) L'introduzione dei microservizi e la gestione dei loro container in particolare, porta a dover ripensare la propria infrastruttura ed i propri processi Devops. La stessa architettura di un applicativo web può arrivare a cambiare radicalmente.
Microservizi, scenari del prossimo e del lontano futuro - Saverio Giallorenzo (DISI - UNiversità di Bologna) I microservizi sono con ogni probabilità il trampolino di lancio verso scenari futuri estremamente interessanti da esplorare. Tra le diverse ramificazioni a cui essi possono portare c'è sicuramente quello delle coreografie attualmente esplorato all'interno dell'Università di Bologna.