Visualizzazione post con etichetta Common Data Model. Mostra tutti i post
Visualizzazione post con etichetta Common Data Model. Mostra tutti i post

venerdì 18 dicembre 2015

Cos'è il Blockchain (Block Chain)


Il Block Chain (letteralmente Catena di Blocchi) è un registro pubblico e condiviso che contiene tutte le transazioni effettuate in Bitcoin. 
Visto come un nuovo importante protocollo di trasmissione e memorizzazione dei dati, essendo continuamente ricondiviso da tutti i client partecipanti alla rete bitcoin rappresenta la prova di tutte le transazioni, il blockchain è in costante crescita in quanto vengono sempre aggiunti nuovi Blocks per registrare le movimentazioni. 

Un Block (Blocco) è l'anello della catena, quando viene completato con l'inserimento delle informazioni relative alle transazioni recenti, viene chiuso e non è più modificabile. 
Successivamente viene quindi generato e collegato alla catena un nuovo blocco, contenente un identificativo del blocco precedente, alimentando così una banca dati lineare con tutte le operazioni in ordine cronologico.



Per fare un'analogia con i processi bancari tradizionali, il blockchain è come una storia completa delle operazioni bancarie: le transazioni in bitcoin sono gestite cronologicamente come le transazioni bancarie. Mentre i Blocchi possono essere assimilati ad estratti conto di operazioni fatte in determinati spazi temporali.

Vengono chiamati Nodes (Nodi), tutti i computer che partecipano alla rete Bitcoin e che svolgono il compito di convalidare e di ricondividere il blockchain.
Ciascun Nodo utilizza un programma client che riceve automaticamente una copia integrale del blockchain con le informazioni di tutte le movimentazioni contenute, a partire dal primo blocco (Genesis Block) fino a quello completato più di recente.

Questa continua condivisione su tutti i client in rete, di fatto valida tutte le transazioni e ne diventa il database storico distribuito.

Considerando che in media viene creato un nuovo blocco ogni 10 minuti, la dimensione sempre crescente del blockchain è una delle criticità che dovranno essere gestite in futuro, potrebbero infatti nascere problemi di spazio per la memorizzazione e sincronizzazione.


venerdì 11 settembre 2015

Cos'è il NewsML

Il NewsML (News Markup Language) è un formato dati progettato per la memorizzazione e la trasmissione delle notizie digitali.
Utilizzato dai più importanti media, giornali, TV, agenzie di stampa, ecc., è uno standard riconosciuto e sviluppato dal consorzio internazionale IPTC  (International Press Telecommunications Council).

La necessità di avere un Common Data Model di riferimento, è derivato dalla continua crescita della produzione e dello scambio di notizie in formati eterogenei (testo o multimedia) dovuto alla rapida espansione di Internet e delle comunicazioni veloci world wide.

Il formato NewsML può essere applicato a tutte le fasi del ciclo di vita delle notizie digitali.  Un uso tipico lo prevede nelle comunicazioni:


  • interne ad un sistema editoriale
  • verso altri sistemi editoriali
  • tra agenzie di stampa e loro clienti 
  • tra editori ed aggregatori di notizie 
  • tra i fornitori di servizi di stampa e gli utenti finali. 

Basato sul linguaggio XML (eXtensible Markup Language) , il NewsML ha l'obiettivo di fornire struttura dati generica in grado di rappresentare tutte le tipologie di notizie (testi, foto, video, audio, multimedia, rss, links, composte), in modo da abilitarne lo scambio, l'interpretazione e l'elaborazione in modalità standard da parte dei sistemi editoriali.

A tale scopo è disponibile il NewsML Toolkit, una libreria Java-based che può essere integrata all'interno delle applicazioni per facilitare la gestione delle News espresse in tale formato.

Sono state prodotte 2 main release del NewsML, aggiornate poi con versioni successive:
  • NewsML 1.* - la cui versione 1.0 è stata presentata nel 2000;
  • NewsML-G2 - standard di nuova generazione la cui prima versione è del 2008.

Ciascuna versione prevede un documento descrittivo (metadati in formato DTD e/o XSD) che definisce la struttura del file NewsML e gli attributi possibili delle informazioni che può contenere.  


Image courtesy of Stuart Miles at FreeDigitalPhotos.net



Articoli Correlati

giovedì 6 novembre 2014

Il confronto XML vs JSON

L' XML (eXtensible Markup Language) è il formato più utilizzato per la condivisione di dati in formato open.
Non essendoci disponibili in passato altri standard altrettanto semplici e strutturati, l' XML è da parecchi anni la codifica migliore per lo scambio dati tra diverse applicazioni.

Nate in un contesto di sviluppo WEB/HTML, sul finire degli anni 90 le specifiche XML sono state consolidate dal W3C (World Wide Web Consortium) ed hanno permesso di estenderne l'uso anche in altri contesti applicativi, in particolare nell'Application Integration.

Questo linguaggio di markup, oltre ad essere ottimo per la gestione di dati testuali e numerici, può essere sfruttato, utilizzando gli opportuni encoding, anche per la rappresentazione ed il trasferimento di documenti, immagini, audio, video ed altre tipologie di files in genere.

Per facilitare l'uso dell'XML, nel tempo sono state sviluppate innumerevoli librerie e programmi software in grado di automatizzare il parsing, la validazione, l'interpretazione del codice e la conversione dei dati.


Negli ultimi anni sta prendendo sempre più piede l'utilizzo anche di un altro formato, il JSON (Javascript Object Notation), il cui successo è dovuto principalmente alla semplicità di utilizzo in ambito Web a supporto delle tecnologie Ajax e Javascript diffusissime nei siti dinamici di ultima generazione.
Nella sostanza, considerando la sintassi del codice e le modalità funzionali, le analogie tra XML e JSON sono evidenti, tuttavia ci sono effettivamente delle specificità che li distinguono e che fanno preferire uno o l'altro a seconda delle esigenze. 

Leggibilità

Uno degli aspetti da considerare in un linguaggio di codifica testuale dei dati, è la facilità con cui una persona può leggere e comprendere le informazioni contenute.
Premesso che entrambi i formati sono molto leggibili ed è quindi soprattutto una questione di abitudine personale, tuttavia JSON sotto questo aspetto si fa preferire per una sintassi più snella, con meno vincoli, opzioni e tag di formattazione.

Interoperabilità

Un altro tratto comune tra JSON e XML è che implementano caratteristiche di Auto-Descrizione (Self-Describing) ed Internazionalizzazione dei dati (Internationalization).
Entrambi utilizzano standard e codifiche che permettono la manipolazione delle informazioni mediante utilizzo di strumenti software generici.  Ciò ne ha facilitato l'uso in una vasta gamma di applicazioni.

Gli strumenti di descrizione e validazione (dtd e xsd), i linguaggi di navigazione all'interno dei nodi (xquery e xpath) e le librerie di elaborazione a disposizione per l'XML sono sicuramente più consolidate ed affidabili, pertanto si fanno preferire in un contesto di integrazione tra sistemi, di Web Services con transazioni Server to Server.
Grazie a questi aspetti, il formato XML è spesso utilizzato anche per implementare su files veri e propri database strutturati.

In una tipica interazione Web Client->Server (siti web, App) invece le caratteristiche del JSON sono più indicate in quanto, oltre che essere un linguaggio più leggero (una minore verbosità corrisponde ad una minore grandezza dei file e quindi a performance migliori nel trasferimento dati), è immediatamente integrato con la programmazione Javascript e per lo scambio dati con i meccanismi Ajax.

Estensibilità

La possibilità di estendere gli attributi dei dati memorizzati permette all'XML di essere più flessibile.
Mentre JSON si limita a gestire solo dati classici come testo e numeri, l'XML consente di memorizzare e descrivere in modo più completo qualsiasi tipo di dato.

Inclusione di altri file

Con XML è possibile includere file di qualsiasi formato, questo significa che è possibile inserire documenti, foto, audio, video e altri file all'interno di un file XML (file embedded).
La stessa cosa non è possibile farla con JSON.

Trasmissione di dati alfanumerici

Con JSON i dati sono memorizzati in array e object mentre in XML le informazioni sono strutturate ad albero.
Entrambe le soluzioni hanno i loro vantaggi, ma utilizzando le tecnologie web di ultima generazione il trasferimento dati è molto più semplice e veloce quando i dati sono già organizzati in un modo direttamente interpretabile con la programmazione orientata agli oggetti.

Questo rende il JSON più indicato per importare i dati di testo e numerici con diversi linguaggi e quindi è da molti considerato migliore per lo sviluppo di funzionalità web con elaborazione lato client.

Per fare la stessa cosa con l'XML bisogna trasformare i dati prima di poterli utilizzare all'interno del programma.

Conclusioni

XML ha sicuramente uno spettro di utilizzo molto più vasto dovuto sia alle caratteristiche intrinseche nel linguaggio stesso sia al fatto che intorno a questo formato si è da tempo evoluto un mondo molto significativo di direttive, metodologie, strumenti ed applicazioni.

JSON invece, in forte ascesa solo da qualche anno, si caratterizza per la semplicità nella rappresentazione ed è ottimo per la serializzazione e la trasmissione di dati di tipo classico.

XML è un linguaggio di markup in grado di gestire in modo completo qualsiasi tipo di informazione, mentre JSON è un formato di interscambio dati che risulta essere di più agile utilizzo in determinati contesti.

venerdì 5 settembre 2014

Impatti delle applicazioni mobili sui sistemi server

Con l'aumento esponenziale delle APP e più in generale degli accessi al WEB dai dispositivi mobili, sono cresciuti enormemente i volumi delle connessioni e delle richieste verso i sistemi server che effettivamente detengono le informazioni. 



Per fare un esempio, se fino a pochi anni fa chi si collegava al sito del Meteo lo faceva al massimo una volta al giorno dal PC, oggi gli utenti che usano la specifica APP sullo smartphone sono tantissimi e lo fanno con frequenza molto più elevata.

Qualsiasi servizio o tipologia di informazione le aziende mettano a disposizione della propria clientela online, il numero delle transazioni client-server è decuplicato rispetto al passato.

Il trend è in continua ascesa, gli impatti sui sistemi di backend sono importanti e per reggere l'urto le aziende sono costrette a potenziare le proprie infrastrutture hardware ed implementare architetture software più efficienti.



A seconda delle specifiche situazioni, esigenze e disponibilità, si stanno mettendo in campo soluzioni di diversa tipologia (non esclusive).

Soluzione 1 - Potenziamento HW

La cosa che viene più facile ed immediata pensare è quella di incrementare le risorse HW (CPU, RAM, dispositivi di rete) dei sistemi impattati in modo da poterne aumentare performance e stabilità.
Per una attività di approvvigionamento HW, particolare importanza riveste la qualità del Capacity Plan, che deve essere fatto in modo accurato per evitare investimenti inutili, insufficienti o di corto respiro.

Pro:
  • Facilità di realizzazione (basta comprare ed installare)
  • Tempi di realizzazione
Contro:
  • Incrementare l'HW su un numero elevato di sistemi complessi ed eterogenei potrebbe rivelarsi molto costoso
  • Soluzione non risolutiva se in futuro dovesse aumentare il carico oltre quanto stimato nel Capacity Plan.



Soluzione 2 - Ottimizzazioni applicative 

La review funzionale dei sistemi, della architettura di integrazione ed un tuning sistemistico sono sempre attività opportune in questi casi.
Le ottimizzazioni possono essere apportate su più livelli:
  • Processi 
  • Software applicativo 
  • Configurazioni sistemistiche.

Pro:
  • Riprogettare i processi e rendere l'architettura applicativa dei sistemi maggiormente performante e scalabile, potrebbe consentire una corretta ripartizione del carico sulle risorse a disposizione, quindi di fatto risolvere il problema
Contro:
  • Rivedere processi e apportare modifiche al software applicativo potrebbe rivelarsi non fattibile o molto costoso
  • Non sempre le architetture dei sistemi si prestano ad essere estese in modo da implementare correttamente le nuove funzionalità 
  • I tempi di realizzazione sono legati alla quantità ed alla tipologia degli interventi.

Soluzione 3 - Introduzione di un layer applicativo di Data Caching

In caso i volumi siano molto elevati, la soluzione migliore prevede l'introduzione all'interno dell'architettura IT di un nuovo layer applicativo (Data Cache Service Layer), un sistema molto performante in grado di recuperare inizialmente dai sistemi server tutte le informazioni necessarie, memorizzarle all'interno di una propria cache e rispondere velocemente ai client.

Con questa soluzione, le richieste provenienti dai client non arrivano mai ai sistemi server ma vengono gestite direttamente dal Data Cache Service Layer.

Accorgimenti necessari:
  • implementare gli opportuni meccanismi di aggiornamento delle informazioni in caso vengano variate, per mantenerle sempre allineate tra i sistemi e la cache
  • strutturare internamente alla cache un Data Model adatto alla tipologia dei dati che si trattano ed alle modalità di interrogazione da parte dei client.




Pro:
  • Performance al top (non si perde tempo ad interrogare i sistemi di backend ma le informazioni sono già disponibili nella cache)
  • Nessun potenziamento HW sui sistemi
  • Ottimizzazione SW dei sistemi non necessaria
  • Massima predisposizione se in futuro dovesse aumentare ulteriormente il carico (basterà adeguare il Data Cache Service Layer senza dover toccare tutti i sistemi di backend)
Contro:
  • Necessario un investimento iniziale
  • Tempi e costi di realizzazione da valutare a seconda della complessità delle informazioni, dei sistemi e dei processi


Articoli Correlati



venerdì 21 febbraio 2014

Il concetto di Common Data Model (CDM)

I dati sono la componente più importante di un qualsiasi sistema o architettura informatica.

Una delle maggiori criticità che si riscontrano in un contesto IT di tipo enterprise, è la complessità dell’integrazione tra sistemi che hanno modelli dati e linguaggi di comunicazione eterogenei anche dal punto di vista semantico.
La diversità tra i formati dati dei sistemi coinvolti nei processi di business è uno degli aspetti principali da considerare nell'adozione di una architettura di integrazione (EAI) con approccio a servizi (SOA).

Avere interfacce di comunicazione non generalizzate, ma specifiche per singolo sistema o addirittura singolo processo, comporta un aumento della complessità generale con conseguente incremento dell'effort necessario per ciascun nuovo sviluppo o intervento di manutenzione evolutiva. Infatti, per ciascun flusso dati che viene scambiato è necessario implementare una differente trasformazione, con il rischio oltretutto di mal interpretare il vero significato dell'informazione che viene veicolata.

Per mitigare questo problema e rendere l’integrazione dei dati più efficiente dal punto di vista tecnologico ed economico, un approccio efficace è quello di utilizzare un Common Data Model, noto anche come CDM.

Un CDM viene definito per rendere univoca la comunicazione tra sistemi eterogenei in un comune ambiente di business; è un formato dati standardizzato e condiviso, utilizzato per facilitare l'integrazione tra diverse aree applicative e quindi lo scambio dati tra di esse.

Il CDM è un modello predefinito che esprime la rappresentazione logica, semantica e le relazioni dei dati a cui ciascun sistema deve far riferimento per comporre ed interpretare nel modo corretto le informazioni che invia e riceve.



La definizione di un CDM può rivelarsi un'attività lunga ed articolata e va fatta con la massima attenzione tenendo in considerazione tutti i requisiti e le specificità dei processi di business e dei sistemi coinvolti.

Come base di partenza per definire un nuovo CDM, una delle possibilità può essere quella di estendere il formato dati utilizzato dal sistema più importante tra quelli coinvolti apportando le opportune modifiche, ma forse la più valida alternativa è quella di cercare se esiste già un modello standard per il tipo di contesto a cui si fa riferimento.

Per alcuni dei più importanti ambiti di business (es. Telecomunicazioni, News, Pubblica Amministrazione, Sanità, ecc.) infatti sono disponibili dei CDM più o meno consolidati che documentano il formato dati "standard". Tali CDM cercano chiaramente di essere onnicomprensivi e quindi è quasi sempre opportuno ritagliarli per le proprie necessità.

Gli strumenti per descrivere un CDM, tipicamente sono:

  • Grafici relazionali (entità/relazioni);
  • Grafici gerarchici;
  • Markup languages (xml, xsd, uml);
  • Documenti e tabelle descrittive dei vari campi che compongono il data model.



Articoli correlati: