Nella primavera del 2015 abbiamo effettuato una riunione con un nostro cliente storico per riprogettare alcune componenti del suo parco applicativo, che ha le seguenti caratteristiche:

• applicativi differenti, ognuno con le sue informazioni (parco dati);
• ogni applicativo gestisce le informazioni e il modo di reperirle in maniera differente;
• l’utente deve conoscere i percorsi di ricerca specifici per ogni applicativo;
• i dati sono disomogenei tra gli applicativi, di conseguenza per trovare o gestire una determinata informazione può rendersi necessario effettuare ricerche su più applicativi.

Nel corso della riunione è emersa l’idea di creare un motore ricerca semantico Google style per valorizzare e facilitare la gestione dell’enorme insieme di informazioni memorizzate e gestite dai vari applicativi:

• oltre 1000 servizi;
• applicazioni e integratori per un totale di 1200 installazioni;
• oltre 13 milioni di anagrafiche.

Il motore di ricerca è una soluzione un po’ fuori dagli schemi:

• l’utente ricerca un’informazioni sui dati di tutti gli applicativi contemporaneamente; è poi il motore di ricerca a suggerire all’utente su quali applicativi specifici è presente l’informazione ricercata.
• è possibile, attraverso il motore di ricerca, aprire l’applicativo che gestisce o contiene l’informazione, facilitando e velocizzando il lavoro quotidiano dell’utente.

Per ottenere un risultato analogo si dovrebbe riprogettare ed integrare gli applicativi con costi decisamente superiori. Il motore di ricerca fornisce una nuova modalità di ricerca mantenendo le logiche di scrittura e l’indipendenza delle applicazioni.

Perché un motore di ricerca semantico? Le informazioni hanno un significato specifico all’interno degli applicativi di provenienza. Il motore di ricerca deve mantenere questa peculiarità e contemporaneamente utilizzarla per raggruppare e categorizzare le informazioni. Le tecnologie semantiche sono utili per raggiungere l’obiettivo in quanto, da un lato consentono di creare un modello di alto livello con all’interno tutti i significati attribuibili alle informazioni e dall’altro permettono di mappare sul modello le informazioni gestite dai sistemi, così da renderle omogenee per l’utilizzatore finale. Ad esempio, il concetto di anagrafica della persona è unico, ma le singole istanze sono trattate differentemente da applicativo ad applicativo (informazioni gestite, persistenza, … ): quando un motore di ricerca le indicizza, deve riconoscere che si tratta di anagrafiche di persona e, nel caso, di una stessa persona.

Il risultato ottenuto è una visione dei dati ad alto livello che mantiene allo stesso tempo l’eterogeneità delle fonti dei dati.

Il supporto dell’approccio semantico consente inoltre di mettere le informazioni in relazione le une con le altre. Ad esempio: una persona ha un indirizzo inerente ad una città; la città, a sua volta, è un concetto legato a molte altre informazioni . Si crea quindi un grafo navigabile di relazioni. Il grafo è estendibile senza modificare le informazioni indicizzate.

In questo modo è possibile eseguire ricerche su informazioni di tipo differente evitando la replicazione. Ad esempio: cercando “Imola”, si può ottenere Imola come città, ma navigando il grafo si possono ottenere tutte le aziende che hanno delle sedi a Imola e quindi le persone che vi lavorano.

Utilizzando un motore di ricerca tradizionale, si sarebbero potuti ottenere risultati analoghi mettendo in ogni blocco di informazioni anche le altre informazioni ad esso correlate, ad esempio indicizzando le anagrafiche assieme alle informazioni sulla città, l’azienda in cui si lavora e quant’altro. Senza il motore semantico le correlazioni sono pensate durante l’indicizzazione dei dati, con il supporto semantico occorre conoscere il modello e durante la ricerca navigare il grafo per un adeguato numero di livelli. Un’eventuale cambio di correlazioni porta da un lato a dover modificare tutti i dati indicizzati, dall’altro a cambiare solamente il modello semantico.

Le performance cambiano. Il supporto semantico risulta meno performante in quanto deve risolvere i livelli di navigazione del grafo. I dati sono denormalizzati in entrambi i casi, garantendo le prestazioni su grosse moli di dati. Si tratta di un piccolo costo da pagare per avere una elevata dinamicità nell’aggregazione dei dati.

Per il POC che abbiamo implementato abbiamo usato:

• Virtuoso come storage (Triple Store), che fornisce anche un endpoint SPARQL;
• SPARQL come linguaggio di interrogazione;
• OWL / RDF come linguaggio per la modellazione delle informazioni di dominio (modello);
• JAVA per il front-end.

Dal punto di vista architetturale Virtuoso rappresenta lo strato di persistenza, mentre il front-end Java implementa il layer di presentazione, in cui presentiamo dinamicamente le informazioni ricercate, un layer di logica applicativa che permette di attuare:

• logiche di autorizzazione;
• logiche autenticazione;
• logiche di reperimento di dati per contestualizzare i risultati della ricerca;
• un layer di accesso ai dati.

Per quanto riguarda la presentazione Google style delle informazioni, oltre ad elencare i dati e a creare i “link” per aprirli nei corrispondenti applicativi, è stato anche introdotto un sistema che mostra dinamicamente le informazioni correlate al singolo risultato della ricerca, in modo tale da contestualizzarlo, ampliarlo e facilitare quindi l’operatore nell’individuare l’informazione di suo interesse. Cercando ad esempio “Mario Rossi”, oltre al nome ed il cognome vengo mostrati il codice fiscale, il luogo di residenza e l’azienda pressa la quale lavora.

Il Proof Of Concept (POC) è stato realizzato in 10-15 giornate, avendo una piena conoscenza del dominio. Il cliente ha apprezzato il POC, che verrà evoluto ampliando il numero di concetti all’interno del modello e la quantità di informazioni presenti, modificando di conseguenza l’interfaccia grafica.

Andrea Ravagli

Francesco Panico

Normanno Cacciari

Gestire un team apre spunti di riflessione non solo sulle modalità di soddisfacimento degli obiettivi di progetto, ma anche su quelli personali del team.

Da qui, è compito del referente di progetto capire le motivazioni del proprio gruppo e di ciascun singolo, ponendosi l’obiettivo di soddisfarli, perché questo si coniuga con l’obiettivo di progetto, perché se il team è motivato farà meglio il suo lavoro!

Partirei da una distinzione fondamentale delle motivazioni: intrinseche ed estrinseche.

Le motivazioni intrinseche sono quelle naturali, basate sulla curiosità e sul il bisogno di esplorare l’ambiente alla ricerca di nuove informazioni e soluzioni. Importante per la motivazione intrinseca è, inoltre, la padronanza, cioè il bisogno di sentirsi sempre più competenti.

Le motivazioni estrinseche sono quelle dettate da un impegno in un’attività per scopi che sono estrinseci all’attività stessa, quali, ad esempio, ricevere lodi, riconoscimenti, buoni voti o per evitare situazioni spiacevoli.

Notate queste caratteristiche trai propri membri del team, non sarà facile trovare il giusto compromesso tra le due; spingiamo su quelle intrinseche che mi ispirano parecchio.

La Self-determination theory (Deci, Ryan 2004) propone queste caratteristiche intrinseche:

Competence: ciò che una persona dimostra di saper fare (anche intellettualmente) in modo efficace, in relazione ad un determinato obiettivo, compito o attività in un determinato ambito disciplinare o professionale [ Centro studi Erickson].

Autonomy: non è da intendere come il dover sapere fare tutto da soli, ma consiste nella capacità di saper ricavare le giuste informazioni dai giusti interlocutori, necessarie a portare avanti il proprio lavoro.

Relatedness: la capacità di sapersi relazionare non solo coi propri colleghi ma anche coi propri clienti,  al fine di riuscire a soddisfare gli obiettivi business e commerciali.

Notare come queste 3 caratteristiche siano strettamente correlate tra loro.

Da queste 3 caratteristiche sono state formulate altre teorie basate sulle motivazioni, sino ad arrivare alla definizione di quelli che sono i 10 Desideri dei membri del team (di cui 3 sono quelli sopra descritti):

Feel accepted: sentirsi parte integrante del team, mediante la collaborazione con tutti e la condivisione delle proprie esperienze e del proprio background professionale;

Curiosity: trovare, anche di fronte ad un’attività noiosa, qualcosa di nuovo che possa stimolare la propria curiosità;

Honor: la squadra deve proporre le proprie regole di gioco (condivise dal referente), così saranno più facili da seguire;

Purpose: avere sempre obiettivi di breve, medio e lungo termine, non solo circoscritti al perimetro dell’attività che si sta portando avanti in quel periodo;

Order: recepire le norme aziendali sufficienti a consentire il buon vivere all’interno della propria organizzazione;

Influence: percepire ciò che sta accadendo intorno a noi, ascoltando ciò che hanno da dire gli altri e aiutarli col nostro contributo e col nostro carisma (avendo la fortuna di averlo;))

Status: capire il proprio valore all’interno dell’organizzazione.

Imola Informatica is pleased to announce the relase 0.2 of Jbi4Corba and Jbi4Cics, our binding components for integrating CORBA and CICS services into a JBI Enterprise Service Bus.
This release will be demoed at the JavaOne (San Francisco 8-10 May 2007) and is already included in NetBeans Enterprise installer as partner contribution.
The main features of this release are as follow:
Jbi4Corba:

• Support for OpenESB
• Netbeans plugin for using Jbi4Corba inside Netbeans Enterprise
• Support for consumer mode
• Support for i18n

Jbi4Cics:

• Support for OpenESB
• Netbeans plugin for using Jbi4Cics inside Netbeans Enterprise
• Support for i18n

Ultimamente c’è molto rumore attorno ai tentativi di standardizzazione legati al mondo SOA. I due standard più promettenti sembrano essere JBI e SCA (quest’ultimo recentemente trasferito a OASIS).

Si tratta di standard che spesso vengono presentati in contrapposizione, ma la realtà è diversa, come risulta evidente dall’analisi degli obiettivi che si pongono.

L’obiettivo di SCA è la definizione di un modello architetturale coerente con SOA e la specifica delle relative API. I componenti di SCA devono contenere logica di business (che può essere scritta utilizzando diversi linguaggi come Java, C++ e BPEL) e possono a loro volta essere composti per produrre ulteriore logica, collegati tramite binding standard. Si tratta quindi un modello estendibile per la costruzione e l’evoluzione dei sistemi informativi.

JBI invece, basandosi su un modello architetturale a bus (ESB), si occupa in maniera più specifica di integrazione. JBI non prevede un set di implementazioni “iniziali”: descrive due tipologie di componenti (binding component e service engine) che devono essere installabili su qualunque ESB JBI-compliant. Questo significa che, se si hanno esigenze di integrazione di qualunque tipologia, possono essere risolte procurandosi i componenti JBI adatti alle proprie esigenze. Un esempio di questo sono i componenti Jbi4Corba e Jbi4Cics sviluppati da Gruppo Imola.

In sintesi si tratta di specifiche sostanzialmente diverse (anche se entrambe basate su concetti SOA): JBI è orientato all’integrazione ed è meno vincolante di SCA che, dall’altra parte, si pone degli obiettivi più ambiziosi.

Non ci sono però reali sovrapposizioni! Si può tranquillamente ipotizzare in futuro di utilizzare sia SCA che JBI allo stesso tempo, ottenendo quindi i vantaggi di entrambi. Ad esempio, integrando servizi SCA su un bus attraverso un opportuno Service Engine JBI, potremmo avere i vantaggi del modello SOA di SCA uniti alla capacità di integrazione assicurata da JBI.