4. Interfacce di Remote Call
Il presente capitolo pone obiettivo di utilizzare le informazioni presentate precedentemente in moda da poter fissare i punti nevralgici necessari per la soluzione della problematica introdotta nel primo capitolo.
4.1 Descrizione del problema
Come definito precedentemente uno dei più grandi limitazioni degli attuali sistemi di content management è l’assenza di un sistema sufficientemente potente per poter acquisire in maniera automatica informazioni provenienti da altri sistemi di cui si ha accesso.
Per meglio chiarire il concetto si prende in considerazione il seguente scenario.
Nell’azienda A sono presenti diversi computer connessi in rete tra loro, inoltre essi sono connessi ad Internet tramite un router.
All’interno dell’Azienda A è presente un server di content management per la gestione dei documenti aziendali.
All’esterno è presente un server che pubblica informazioni che utili per essere utilizzati all’interno dell’azienda.
Inoltre non si ha nessuna descrizione della tipologia (stringhe, numeri interi, numeri reali, date, etc.) delle informazioni che vengono pubblicate.
L’ottimo sarebbe permettere ad un generico utente dell’azienda A di richiedere in maniera automatica le informazioni dal proprio form di immissione dati.
Per meglio chiarire il concetto, si prenda in considerazione un generico modulo di rimborso spese di viaggio del content management dell’azienda A:
Figura 14: Form di immissione dati
Dall’immagine sopra si può notare che le informazioni che vengono richieste sono: matricola, nome, cognome, città natale, data di nascita, sesso, destinazione e costo.
Si consideri che l’azienda A possiede un sistema interno di anagrafica dipendenti contente il primi sei campi della form di immissione dell’immagine sopra.
Essendo il content management e il server di anagrafica sconnessi tra di loro, l’utente dovrà riempire manualmente tutti i campi od al limite accedere al server di anagrafica e “copiare ed incollare” di dati sulla form di immissione.
Questo sistema può portare a diversi errori di trascrizione e cospicuo dispendio di tempo.
Come accennato sopra l’ottimo sarebbe che l’utente finale inserisca soltanto la matricola, la destinazione ed il costo e sia la form di immissione a recuperare i dati dal server di anagrafica.
Questo sistema migliorato porta ad una maggiore efficienza di inserimento dati oltre che ad una minore probabilità di errore, la form dati originaria si potrebbe ripensare nel seguente modo:
La logica di comportamento del sistema è il seguente, si hanno i campi di richiesta esterna, i campi di risposta esterna ed un bottone “Request”.
Dopo che l’utente avrà inserito la matricola dovrà cliccare sul bottone “Request”, questo scatenerà l’evento di interrogazione del server anagrafico esterno e la relativa risposta sarà inserita all’interno dei campi di risposta esterna.
Ovviamente la logica che corrispondeva ai campi di destinazione e costo oltre che al bottone invia rimangono invariate, si ha solo un passaggio intermedio di interrogazione di un server esterno.
Questo primo semplice scenario di riferimento può essere complicato a piacere, infatti possono essere presenti più server esterni da cui prelevare informazioni oppure il server esterno può essere collocato all’interno dell’Azienda A, ma essere diverso dal server di content management.
Inoltre può essere utile non utilizzare il bottone di “Request”, ma fare in modo che l’applicativo interroghi autonomamente il server remoto durante l’invio delle informazioni.
Altre operazione potrebbero essere quelle riguardanti l’aggregazione di diversi valori (massimo, minimo) provenienti da web services diversi.
Ma in generale i passi previsti possono essere i seguenti:
1. inserimento delle informazione nei campi di richiesta esterna 2. interrogazione di uno o più server esterni
3. esecuzione della/e operazione/i con relativa scrittura dei campi di risposta esterni 4. eventuale riempimento di altri campi non relativi a richieste esterne
5. terminazione dell’operazione richiesta
Da notare che l’esecuzione temporale del punto 4 è indipendente dai punti 1, 2 e 3 ed ha come vincolo di precedenza solo il punto 5.
Nell’ottica di sistemi di document workflow potrebbe essere utile che la richiesta al server avvenga nel momento della creazione del documento stesso.
Per l’effettiva implementazione delle operazioni sopra indicate bisogna prendere in considerazione il content management e la tecnologia di comunicazione dati da adottare.
Il secondo aspetto è molto delicato, infatti soprattutto all’interno di aziende o di pubbliche amministrazioni possono essere presenti sistemi legacy non modificabili e che non permettono la pubblicazione di informazioni.
In questo secondo scenario, basterebbe sviluppare un applicativo che funga da proxy tra il sistema legacy ed il content management.
Ovviamente questa soluzione è di semplice realizzazione in tutti quei casi in cui la pubblicazione di informazione è la semplice lettura da un database o da un altro sistema di memorizzazione dati, infatti questa relativa complicazione, permette di non cambiare il sistema legacy con un notevole risparmio di tempo e denaro
4.2 Soluzione
Nel capitolo precedente è stata presentata la tecnologia dei web service, i suoi punti di forza ed i suoi componenti che la compongono.
Sia dalle specifiche dell’infrastruttura CART che dell’introduzione del problema del paragrafo precedente, si evince che questa tecnologia risulta vincete rispetto ad altre (come per esempi XML-RPC) in quanto il linguaggio WSDL fornisce una descrizione molto completa dei parametri che servono per la comunicazione delle informazioni.
Questa descrizione permette, inoltre, la creazione di documenti creati ad-hoc per la gestione della richiesta delle informazioni.
Ovviamente i server da cui poter prendere le informazioni potrebbero essere diversi e quindi occorre riuscire a creare modalità di visualizzazione di informazioni.
Questo genere di operazione è concettualmente molto simile a ciò che si fanno i software di Data Manipulation Language (DML) di un qualsiasi DBMS (DataBase Management System), quindi ha senso prevedere opportuni aggregatori di valori del tutto simili a quelli utilizzati dal linguaggio SQL.
Inoltre essendo un applicativo web da sviluppare molta importanza ha l’interfaccia grafica che deve essere user-friendly.
4.3 Caratteristiche
In questo e nei paragrafi successivi verranno descritte le classi di utenti, i requisiti utente oltre che la specifica dei requisiti dell’applicativo da sviluppare.
Siccome l’applicativo che si appoggia ad un sistema di content management viene ipotizzato che le funzioni di quest’ultimo siano già implementate e quindi non verranno trattate nella seguente discussione.
Verranno infatti descritte solo le funzioni aggiuntive da realizzare.
Per l’applicativo sono stati definite le seguenti classi di utenti:
1. utente semplice: utente registrato nel content management che usa l’applicativo 2. utente amministratore: utente registrato che gestisce l’applicativo
Nella definizione verrà usato la dicitura “tipo di documento” per indicare una form web di immissione dati formato da un’insieme di parametri da inserire (vedi figura 15) e che abbia una semantica per il content management
4.3.1 Definizione dei requisiti utente
1. l’utente semplice deve poter effettuare richieste di informazioni da server remoti in accordo con la politica del tipo di documento
2. l’utente amministratore deve poter gestire la configurazione dell’applicazione per l’inserimento di web service, gestire operazione di un web service in relazione a tipi di contenuti, gestione template di aggregatori in relazione a tipi di contenuti
4.3.2 Specifica dei requisiti utente
1. Utente semplice : in questo paragrafo verrà discusso la specifica dei requisiti dell’utente semplice chiamandolo ‘utente’
L’utente deve poter:
1.1. effettuare richieste di informazioni proveniente da sistemi remoti e visualizzarne le risposte in associazione al tipo di documento usato
1.2. visualizzare le informazioni provenienti da sistemi remoti in accordo al template di aggregazione, deciso dall’utente amministratore, per il tipo di documento usato
2. Utente amministratore : in questo paragrafo verrà discusso la specifica dei requisiti dell’utente amministratore chiamandolo ‘amministratore’
L’amministratore deve poter:
2.1. poter analizzare la descrizione WSDL di un web service
2.2. poter salvare la descrizione del web service all’interno del sistema
2.3. poter creare un nuovo tipo di documento che permetta la richiesta di informazioni da un’operazione di un web service precedentemente inserito 2.4. poter aggiungere ad un tipo di documento precedentemente creato la
possibilità di richiedere informazioni da un’operazione di un web service precedentemente inserito
2.5. poter effettuare il mappaggio manuale tra i campi di un tipo di documento ed i parametri di un’operazione di un web service precedentemente inserito 2.6. poter scegliere la modalità di richiesta dei dati, per ognuna delle operazioni
inserite all’interno del tipo di documento, tra le seguenti tre: a) alla creazione del documento (before mode)
b) durante l’editazione del documento (during compiling) c) dopo il salvataggio del documento (after saving)
2.7. poter sceglie, in caso di più operazioni all’interno di un tipo di documento, di usare come unica modalità di richiesta dati la “during compiling” comune a tutte
2.8. poter cancellare la connessione tra un tipo di documento creato e l’operazione di richiesta ad essa associata
2.9. poter ricercare per nome tra i web service inseriti le operazioni
2.10. poter creare sistemi di scelta delle risposte di operazioni di web service, chiamato template di aggregazione, tramite i seguenti aggregatori:
a) massimo b) minimo
c) maggioranza
d) conteggio delle risposte
e) conteggio delle risposte diverse f) valore mediano
2.11. poter specificare il mappaggio del template di aggregazione sia dei campi di richiesta che di quelli di risposta in accordo alla seguente politica:
a) per i campi di richiesta si effettua un operazione di mappaggio manuale
b) per i campi di risposta viene effettua la specifica dei campi su cui effettuare l’aggregazione dei valori
2.12. poter inserire un template di aggregazione all’interno di un tipo di documento preesistente
2.13. poter cancellare un template di aggregazione preesistente
4.3.3 Analisi dei requisiti di sistema
Il sistema deve:
1. essere compatibile con la tecnologia web service ed in particolare deve essere in grado di gestione il protocollo SOAP ed il linguaggio WSDL
2. permettere l’inserimento delle informazioni di web service
3. essere in grado di interfacciarsi con un sistema di content management system
4. essere in grado di creare un tipo di documento all’interno del content management system
5. permettere la ricerca di operazioni tra i web service inseriti 5.1. permettere la ricerca usando il nome dell’operazione 5.2. permettere la ricerca usando l’url del web service 6. essere usabile
6.1. utilizzare la definizione data da ISO 9241-11 come linea guida per la realizzazione dell’usabilità: “l’efficacia, l’efficienza e la soddisfazione con cui determinati utenti possono raggiungere determinati obiettivi in determinati ambienti d’uso”.
6.2. le funzionalità dell’applicativo devono essere raggiunte tramite menu all’interno dell’area di amministrazione del content management di riferimento
6.3. il sistema deve segnalare in maniera opportuna una condizione di errore tramite le seguenti informazioni:
a) una descrizione semplificata dell’errore b) una lista delle possibili cause
c) una lista delle possibili azioni da per risolvere il problema (qualora abbia senso)
7. esperienza utente
7.1. l’applicativo deve utilizzare la tecnologia AJAX al fine di migliorare l’esperienza utente
