Archive for Cultura generale ITC

Uniface e i Web Services, 1. parte – Generalità

Il W3C definisce un “web service” come “un modulo software disegnato per supportare l’interoperabilità e l’interazione tra macchine collegate in rete”.
I Web Services sono univocamente il fulcro delle possibili integrazioni tra ambienti applicativi eterogenei per piattaforma, sistema, linguaggio ma le tecnologie utilizzate si differenziano; negli anni aziende diverse, leader di mercato, hanno  sfortunatamente avuto idee diverse su quale potesse essere la soluzione ideale per garantire interoperabilità ed interazione in rete. Questo fatto ha generato sostanzialmente due tipi diversi di Web Services:
1 – basati sulla specifica SOAP
2 – in linea con i criteri REST
La specifica SOAP è di poco più anziana dei criteri REST (SOAP 1.0 del 1998, mentre 2000 Tesi di laurea di Roy Fielding per REST) ma mentre SOAP è stato adottato da subito su larga scala, REST ha ricevuto una notevole spinta solo negli ultimi anni, in base al suo ampio utilizzo dovuto alla semplicità dei criteri che lo caratterizzano, in linea con le tecnologie comunemente in uso. Va chiarito che REST NON è una specifica formale ma una serie di criteri oggetto di raccomandazione a supporto di una architettura software per la gestione di dati in ambiente ipertestuale.

Un minimo di approfondimento su entrambi i tipi di Web Services:
SOAP = acronimo per Simple Object Access Protocol: può operare su differenti protocolli di rete, ma HTTP è il più comunemente utilizzato per il trasporto, anzi è l’unico ad essere stato standardizzato dal W3C. La busta SOAP si basa su XML e la sua struttura segue la classica configurazione Head-Body, analoga ad HTML. Il segmento opzionale Header contiene meta-informazioni come quelle che riguardano il routing, la sicurezza, le transazioni e parametri per l’Orchestration. Il segmento obbligatorio Body trasporta il contenuto informativo che talora viene detto carico utile (payload). Questo deve seguire uno schema definito dal linguaggio “XML Schema”. SOAP può essere utilizzato in due modi diversi:
– il client controlla in un Service Registry l’oggetto d’interesse e sviluppa il messaggio secondo i parametri contenuti nel Service Registry.
– il client conosce a priori i parametri e non necessita di consultare il service registry. All’interno del body del messaggio si inseriscono i dati scritti nel formato concordato.

REST = acronimo per REpresentational State Transfer: Web services di tipo REST permettono di richiedere ad un sistema l’accesso a determinate risorse ricevendo in cambio una rappresentazione testuale delle medesime attraverso l’uso di un predefinito ed uniforme insieme di operazioni “stateless”. Le risorse sono identificate attraverso un URI (Uniform Resource Identifier) mentre le operazioni che si utilizzano sono quelle tipiche del protocollo HTTP (HTTP verbs): GET, POST, PUT, DELETE, OPTIONS. La rappresentazione testuale della risorsa ricevuta in risposta può essere strutturata in modi diversi, ad esempio: XML, HTML, JSON o addirittura semplice testo; JSON è il formato che più ha preso piede nel corso del tempo. Un sistema che voglia essere pienamente compatibile con una architettura REST dovrebbe comprendere ed implementare in modo rispettoso le seguenti caratteristiche:
– modello client-server: separazione netta delle competenze, client = interfaccia, server = accesso funzionale alle informazioni.
– dialogo di tipo stateless: ciascuna richiesta da un qualunque client contiene tutte le informazioni necessarie e lo stato della sessione è totalmente gestito lato client. Lo stato della sessione può essere trasferito al server e, se necessario, mantenuto persistente per il tempo necessario a gestire la transizione allo stato successivo.
– risposte cacheable: ogni tipo di dialogo web deve essere definito “cacheable” o “non cacheable”; i servizi REST dovrebbero sempre essere gestibili in cache dai nodi sui quali transitano.
– sistema a livelli: ogni client non deve riconoscere se è collegato al server vero e proprio o ad un suo intermediario; gli intermediari diversi possono essere implementati al fine di poterli  specializzare su funzioni diverse (sicurezza, gestione dei carichi e conseguente scalabilità, ecc)
– “code on demand”: alcuni server possono, anche su base temporanea, estendere, anche in modo specifico, le funzionalità di un client attraverso il trasferimento di codice eseguibile.
– interfaccia uniforme: è fondamentale nella definizione di qualsiasi insieme di servizi REST; dovrebbero SEMPRE essere soddisfatte le seguenti linee guida:
. Identificazione delle risorse: specifiche risorse sono identificate nella richiesta, per esempio utilizzando direttamente URI di riferimento. L’identificazione delle risorse da richiedere è concettualmente separata dalla loro rappresentazione restituita al richiedente. Ad esempio: il server può inviare informazioni dal suo database come HTML, XML o JSON, la cui struttura nulla ha a che vedere con quella interna del server.
.. Manipulazione delle risorse mediante la loro rappresentazione: quando un client riceve la reppresentazione di una risorsa, inclusi eventuali metadati, ottiene sufficienti informazioni per modificare o cancellare la risorsa.
… Messaggi auto-descrittivi: ciascun messaggio include sufficienti informazioni per permetterne la completa gestione del suo contenuto. Ad esempio: quale parser va invocato per riconoscere il contenuto potrebbe essere specificato con un “Internet media type” (conosciuto anche come MIME type).
…. Hypermedia come motore degli stati applicativi (HATEOAS): avendo avuto accesso una applicazione REST inizialmente a un URI, il client REST dovrebbe essere in grado di avere sufficenti informazioni, per essere in grado di utilizzare i (hyper)link ricevuti per accedere a tutte le ulteriori possibili azioni o risorse necessarie. Mano a mano che il dialogo tra server e client prosegue il server restituisce ulteriori (hyper)links che abilitano il client all’esplorazione dell’ecosistema applicativo disponibile sul server.

Entrambi i protocolli si basano su trasporto mediante HTTP ed entrambi sono correntemente supportati da Uniface:
– SOAP con il driver SOP: inizialmente in versione 1.0, ora in versione 2.0.
– REST sin da Uniface7 con la costruzione di componenti Web che restituiscono un contenuto coerente con i criteri elencati.
Nella seconda parte vedremo dei semplici esempi di come si implementano o come si fruisce di “web services” con Uniface con entrambi i protocolli.

Utilizzare al meglio la tastiera italiana del PC Windows

Questo articolo ha direttamente poco a che fare con l’ambiente Uniface, ma la conoscenza è stata indotta da una esigenza relativa ad una applicazione Uniface.

Come utilizzare al meglio la tastiera italiana del PC Windows?

Per prima cosa esistono fondamentalmente due tipi di tastiere: quelle con e quelle senza tastierino numerico. Quelle senza tastierino numerico permettono di attivarlo logicamente mediante il tasto “Block Num” o “Bl Num”; una volta attivo alcuni tasti della tastiera emulano il tastierino numerico. Questo fatto è importante perché le sequenze di tasti da premere per ottenere certi caratteri prevedono l’uso fondamentale del tastierino numerico.

Si possono generare direttamente dalla tastiera italiana senza tastierino numerico, tipica di molti notebook, i seguenti caratteri:

!”#$%&'()*+,-./0123456789:;<=>?@

ABCDEFGHIJKLMNOPQRSTUVWXYZ

[\]^_

abcdefghijklmnopqrstuvwxyz

{|}àèéìòùç°§€£

Per completare il set di caratteri più comunemente utilizzati nella lingua italiana si possono utilizzare le seguenti sequenze utilizzando il tasto Alt alla sinistra della barra spaziatrice ed i numeri sul tastierino numerico:

Alt 0096 =   `   singolo apice inverso
Alt 0126 =   ~   tilde
Alt 0160 =   á   a minuscola con accento acuto
Alt 0205 =    í   i minuscola con accento acuto
Alt 0243 =   ó   o minuscola con accento acuto
Alt 0250 =   ú   u minuscola con accento acuto
Alt 0192 =   À   A maiuscola con accento grave
Alt 0193 =   Á   A maiuscola con accento acuto
Alt 0200 =   È   E maiuscola con accento grave
Alt 0201 =   É   E maiuscola con accento acuto
Alt 0204 =   Ì    I maiuscola con accento grave
Alt 0205 =   Í    I maiuscola con accento acuto
Alt 0210 =   Ò   O maiuscola con accento grave
Alt 0211 =   Ó   O maiuscola con accento acuto
Alt 0217 =   Ù   U maiuscola con accento grave
Alt 0218 =   Ú   U maiuscola con accento acuto

Possono tornare utili anche:
Alt 0169 =   ©   Simbolo di copyright
Alt 0174 =   ®   Simbolo di diritti riservati
Alt 0188 =   ¼   Un quarto
Alt 0189 =   ½   Un mezzo
Alt 0190 =   ¾   Tre quarti

Si diventa “pianisti”…e si completa la conoscenza del PC con cui si lavora!

Lavorando in ambito internazionale potrebbero essere necessari ulteriori caratteri, come quelli con la dieresi (umlaut in tedesco) con l’accento circonflesso (tipici in francese) o i caratteri greci molto usati in matematica; chi avesse esigenze di questo genere esistono su Internet documentazioni più appropriate e complete di questo breve articolo.

Tornando alle applicazioni, non tutti questi caratteri debbono necessariamente essere accettati su un campo di tipo stringa; in Uniface è possibile applicare direttamente su ogni campo stringa un filtro limitando i caratteri che vengono accettati:
– Solo i caratteri ASCII (sono escluse TUTTE le lettere accentate minuscole e maiuscole)
– Solo i caratteri ASCII estesi (sono compresi tutti caratteri sopra riportati tranne il simbolo dell’Euro)
– L’intero insieme di caratteri disponibili (TUTTI quelli riportati sopra e molti altri…)
E’ ovviamente possibile costruire routine specializzate a supporto di casistiche più complesse.
Per avere un adeguato supporto a livello di database si devono definire i campi stringa di tipo Unicode (packing codes W).

Ho costruito una semplice form di esempio sulla base di quanto descritto: chi volesse riceverla mi invii una email.

Buona digitazione!

Migliorare le applicazioni Uniface esistenti

Negli ultimi due mesi sono stato spesso coinvolto in attività di consulenza mirate a migliorare applicazioni Uniface esistenti.
Ci sono a tutt’oggi in produzione, sia a livello internazionale che in Italia, applicazioni Uniface 5, Uniface 6, Uniface 7, Uniface 8 e, ovviamente, Uniface 9.
L’ambiente di sviluppo si è ampiamente evoluto nei suoi 30+ anni di presenza sul mercato ed ancora oggi continua ad evolvere piuttosto rapidamente: la nuova versione Uniface 10 ne è l’immediata controprova.
Le nuove funzionalità, rese disponibili nel corso degli anni, vanno integrate nelle modalità di sviluppo originarie facendo attenzione a mantenere l’integrità funzionale dell’applicazione originale.

Nella prima fase di queste attività si esplorano gli “Standard & Guidelines” adottati nello sviluppo dell’applicazione, che nella terminologia corrente vengono denominati “Framework di sviluppo”.
Analizzando il modo con cui l’applicazione è stata sviluppata si possono tracciare le linee di potenziale miglioramento, che ricadono in 6 possibili passi:

  1. Da “Stacked forms” char a “Stacked forms” GUI
    2. Da “Stacked forms” GUI a “NonModal forms” GUI
    3. Su “NonModal forms” GUI inclusione di una API applicativa
    4. Da “NonModal forms” GUI a “Web 2.0 pages”
    5. Da “Web 2.0 pages” a “Mobile pages”
    6. Da “Mobile pages” a “Fully partitionable application”

Lo sforzo necessario per ammodernare un applicazione è ovviamente funzione del punto di partenza e del punto di arrivo selezionato. Conviene definire tre obbiettivi: uno a breve, uno a medio ed uno a lungo termine; in questo modo risulta in genere possibile miscelare la quotidiana attività di manutenzione evolutiva dell’applicazione con gli obbiettivi di miglioramento aziendali rilasciando progressivamente le novità sviluppate sul proprio mercato di riferimento.

Chi volesse approfondire l’argomento mi contatti: gianni.sandiglianoATunifacesolutions.com

Da “Standard & Guidelines” a “Framework”

L’argomento che si dibatte più frequentemente in questi ultimi anni durante le attività su Uniface è quello che definisce il titolo di questo articolo: stabilire i metodi / criteri di sviluppo per riscrivere od estendere le proprie applicazioni al mondo Web/Mobile.

Più che un articolo che fornisce una soluzione ideale vuole essere l’inizio di una riflessione su quale sia il metodo scelto, ed eventualmente applicato, per:
– migrare una applicazione client/server esistente a 3 livelli
– sviluppare estensioni a 3 livelli per una applicazione client/server esistente

Nell’ambito della classica architettura applicativa a 3 livelli DATI -> SERVIZI -> (API) -> PRESENTAZIONE risulta in particolare sempre un poco ostica la decisione di quale/i componente/i di programmazione della presentazione lato browser (MV*) includere nel proprio framework per via della molteplicità di proposte e di scelte offerte dal mercato. Potete dare un’occhiata al sito http://todomvc.com per comprendere cosa si intenda per “molteplicità”.

Le proposte disponibili sul mercato vanno sostanzialmente suddivise in due gruppi:
– Framework server-side
– Framework client-side
e la decisione sulla strada da seguire per perseguire gli obbiettivi che l’applicazione si propone di affrontare e risolvere non sempre risulta immediata. In molti casi un ragionevole equilibrio tra le funzionalità svolte dal server e quelle attuate dal client è necessario ma non sempre è immediata la linea di demarcazione tra i due fronti in quanto molto (se non tutto!) dipende dalle funzionalità che si devono sviluppare. L’ideale sarebbe sviluppare applicazioni utilizzando un framework che sia in grado di lavorare su entrambi i fronti (Vedere http://isomorphic.net).

La difficoltà legata alla molteplicità di scelte tecnologiche disponibili va in genere a braccetto con l’esigenza di mantenere il miglior grado di indipendenza dai browser disponibili sulle varie piattaforme, utilizzate dagli utenti; alcune di queste accoppiate browser/piattaforma fanno parte del mondo mobile, per cui si portano appresso esigenze specifiche a livello di presentazione e richiedono di conseguenza un approccio, perlomeno in parte, dedicato. Quando questo approccio dedicato diventa prioritario nel panorama complessivo si parla di “Mobile First Framework”.

Le scelte che ho riscontrato essere maggiormente utilizzate ad oggi sono:
– Bootstrap + jQuery
– AngularJS
– ReactJS
– Custom / Personalizzato (della serie “uso quello che mi serve quando mi serve!”)

Ringrazio anticipatamente chi volesse aggiungere un contributo o una riflessione.

Uniface Lectures

Gli Uniface Lab di Amsterdam hanno lanciato una nuova iniziativa molto interessante: “Uniface Lectures”.

“Uniface Lectures” è una costituita da serie di webinar organizzati per contribuire alla diffusione di conoscenza tecnica su Uniface ed è orientata a TUTTI gli sviluppatori Uniface.

Una volta al mese verrà gestita una sessione serale via web direttamente dai Lab di Amsterdam su un argomento specifico. Utilizzando la versione più aggiornata di Uniface verranno dimostrate funzionalità, tips and tricks con l’obbiettivo di condividere conoscenza a livello tecnico e tecnologico.

Durante questo mese di febbraio verrà svolto il primo di questi webinar: Modernization.

Maggiori informazioni sul calendario già definito e le modalità di iscrizione ai webinar dell’iniziativa possono essere recuperate a questo link sul portale tecnico aziendale.

Buongiorno Unifacers!

Benvenuti a UnifaceSolutions.
Questo sito internet si propone di essere il punto di interscambio di informazioni tra e per gli utenti Uniface in Italia; affianca il sito istituzionale uniface.info (in inglese), anche raggiungibile da unifaceinfo.com, per coloro che preferiscano dialogare in italiano oppure abbiano esigenze specifiche da affrontare in Italia, sia di ordine tecnico che commerciale.
Qui troverete un’area di blogging ed un forum multi-livello nei quali condividere le vostre idee o le vostre esigenze relative allo sviluppo applicativo con Uniface.
Siete TUTTI invitati ad intervenire!
Per accedere al sito registratevi…

Chimichanga!
chimichangaU--icon80x80