Codifica dei caratteri: Codepage

“Codepage” è il termine tradizionale utilizzato da IBM per una specifica tabella di codifica dei caratteri, cioè una mappatura nella quale ad un numero è associato a un carattere specifico.

Ad esempio, nella codifica ASCII il carattere A corrisponde al numero decimale 65. L’unica convenzione valida per tutte le piattaforme è appunto il codice ASCII standard (a 7 bit), ovvero i caratteri dal n. 0 al n.127. Sono escluse le lettere accentate ed i segni tipici di ciascuna lingua. Le tabelle codici sono definite univocamente all’interno di alcune convenzioni internazionali, diversificate per lingua, modo di scrittura, corrispondenza sulla tastiera e per il tipo di sistema su cui operano.

Introduzione a XML

XML è l’acronimo di eXtensible Markup Language. A dispetto del nome non si tratta propriamente di un linguaggio, ma di un meta-linguaggio, cioè un linguaggio per costruire altri linguaggi.

XML deriva dal linguaggio SGML (Standard Generalized Markup Language). Entrambi sono linguaggi di marcatura testuale, ossia inseriscono all’interno del documento delle etichette o marcature (tag), che permettono di descrivere il contenuto del documento stesso

L’insieme dei tag utilizzabili per creare un documento XML non è predefinito come nel linguaggio HTML per il quale, un organismo unico internazionale (Web Consortium), ha definito l’insieme dei tag utilizzabili e il loro significato. L’autore del documento XML definisce i propri tag in base alla tipologia dei dati da descrivere.

Trasferimento dati efficiente su Linux con la tecnica “zero-copy”

Trasferimento dati: l’approccio tradizionale

Consideriamo lo scenario in cui un file letto dal disco deve essere trasferito ad un altro programma in rete. Questo scenario descrive il comportamento di molti tipi di applicazioni, tra cui applicazioni Web, client o server FTP, email, e così via.
Il funzionamento classico prevede le seguenti due chiamate di base:

File.read(fileDesc, buf, len);
Socket.send(socket, buf, len);

Anche se è concettualmente il funzionamento è abbastanza semplice, internamente l’operazione richiede quattro switch di contesto tra user-mode (um) e kernel-mode (km) e quattro copie di dati prima che l’operazione venga completata.

Approfondimenti sul modello publish-subscribe

Nel modello publish/subscribe, il produttore delle informazioni è chiamato editore mentre il consumatore è detto abbonato o iscritto.
L’editore fornisce informazioni su un argomento mentre l’abbonato indica gli argomenti a cui è interessato per ricevere poi le informazioni.

L’argomento dell’informazione è chiamato “topic” e altro non è che una stringa di caratteri. L’editore specifica il topic in fase di pubblicazione mentre l’abbonato lo indica in fase di iscrizione; dopo l’iscrizione riceverà informazioni solo per i topic a cui si è sottoscritto.
Gli abbonati possono specificare una gamma di topic utilizzando i caratteri jolly. Esempi di topic sono le stringhe “Sport” oppure “Sport/Calcio” o ancora “Sport/Golf”. Se in fase di iscrizione l’abbonato indica il topic “Sport/Calcio”, verrà notificato per le sole informazioni relative al Calcio; specificando “Sport/*” verrà notificato per tutte le informazioni riguardanti il Calcio ed il Golf.

Modelli per il messaging

I modelli di base per il messaging sono il “point-to-point” ed il “publish-subscribe” (pub-sub).
Il modello point-to-point viene applicato quando il produttore necessita di inviare un messaggio esattamente ad un consumatore.
Il modello pub-sub viene applicato quando il produttore deve inviare un messaggio a uno o più consumatori interessati.

Messaging and Queuing (parte 2)

Capita molto spesso che un’applicazione di un sistema informatico necessiti di comunicare informazioni (o richiedere servizi) ad altre applicazioni dello stesso sistema o distribuite in sistemi interconnessi. Tali informazioni possono essere classificate genericamente col il termine di messaggio.
Nel modello “Messaging and Queuing” le applicazioni comunicano tra loro scambiando messaggi tramite l’infrastruttura di messaging (MOM), piuttosto che chiamandosi direttamente.

Il messaggio è sempre fornito di un corpo contenente i dati applicativi e di un’intestazione: il corpo può contenere caratteri, numeri, dati binari, o un mix di tutti questi; l’intestazione contiene parametri quali l’ID (identificativo) del messaggio, l’ID di correlazione, l’indirizzo del mittente, etc. Il rapporto tra intestazione ed il corpo dati del messaggio è lo stesso che esiste tra la busta e la lettera in essa contenuta.

Patterns per il messaging

I prodotti per la messaggistica sono intrinsecamente asincroni, nel senso che c’è indipendenza temporale tra la produzione ed il consumo dei messaggi.
Applicando opportuni patterns è possibile attivare comunicazioni sincrone su infrastrutture tipicamente asincrone.

Ci sono due principali patterns (tecniche) per il messaging con le proprie varianti:

Sincrono e Asincrono

Quando si utilizzano i termini sincrono o asincrono bisogna sempre specificare se si parla di ambiente, di trasporto o di comunicazione.

• Un ambiente (o infrastruttura) è detto asincrono se non è necessario che i sistemi mittente e ricevente siano connessi tra loro al momento dell’invio dei dati.
  Grazie ad un’infrastruttura in grado di conservare i messaggi in modo sicuro, esiste indipendenza temporale tra la produzione del messaggio ed il suo consumo (time-independent).
  Viceversa, un ambiente è sincrono se le due parti in comunicazione devono essere presenti allo stesso tempo (time-dependent).

Message-Oriented Middleware (MOM)

Il Message-Oriented Middleware (MOM) è una tecnologia di middleware basata su due concetti: il messaggio e la coda.
Tramite il MOM si semplifica enormemente lo scambio dati tra i sistemi di un’infrastruttura eterogenea.
Le applicazioni non interagiscono direttamente tra di loro in quanto il mittente ed il destinatario dell’informazione non devono necessariamente essere a conoscenza l’uno dell’altro: è il MOM che riceve i messaggi dal produttore dell’informazione e li recapita ai relativi consumatori dopo opportune trasformazioni.

Introduzione al Middleware

Le applicazioni aziendali su scala industriale (enterprise), oltre ad essere distribuite su sistemi software eterogenei, richiedono requisiti di prestazioni, scalabilità, fault tolerance, estensibilità.
La progettazione, la configurazione e la manutenzione delle applicazioni enterprise è di per sé un compito complesso; d’altro canto è sempre più crescente la necessità di applicazioni e processi aziendali flessibili, elastici e reattivi.

Il middleware svolge un ruolo cruciale per le applicazioni enterprise, permettendo di integrare i componenti dell’infrastruttura in modo affidabile, e semplificando sviluppo e gestione.
Può essere definito come lo strato software che risiede “in mezzo” alle applicazioni, uno strato intermedio che consente l’interoperabilità tra le piattaforme, i processi e le tecnologie più disparate.