Bash shell: trim di una stringa

Salve,
torno a scrivere qualcosina dopo mesi di inattività.. :)
Non ho scritto più nulla sia perchè non ho avuto granchè da scrivere..sia (e soprattutto) per mancanza di voglia :P

Beh, mi sono trovato a dover estrapolare una parola dall'output di un programma in bash.
La parola che mi serviva appariva sempre alla prima linea, quindi con head non ho avuto nessun problema.
Il problema è stato pulire la stringa risultante. Inizialmente credevo che non ci fosse nulla di più semplice, dopotutto dovevo solo fare un trim.

Trovare la soluzione non è stato così difficile, basta usare il comando sed (che ho scoperto in questa occasione) con un'espressione regolare, ma mi aspettavo qualcosa di molto più diretto :)

Per eseguire il trim di una stringa c'è bisogno di utilizzare sed sia per pulire l'inizio che la fine di essa.
Per pulire la parte iniziale il comando da utilizzare è questo:

$ sed 's/^ *//g'

Mentre per pulire la coda della stringa:

$ sed 's/ *$//g'

I comandi devono essere chiamati successivamente in pipe, per esempio in questo modo:

$ echo "  aaaa   bbbb      " | sed 's/^ *//g' | sed 's/ *$//g'
aaaa   bbbb

E così si conclude questo post, pieno di chiacchiere per dire una cosa semplicissima :)

Bento Book Laptop

Salve di nuovo :)

In questo post non voglio scrivere niente di impegnativo, mi va di perdere un po di tempo e allora parlo di una cosa molto figa che ho visto recentemente :D

Parlo del Bento Book Laptop!
Eccolo...

Non è forte?? :D

Il nome, Bento, è ispirato dal "Bento box", il classico cestino da pranzo giapponese, solitamente riempito con dell'ottimo sushi :P
Ma cambiamo discorso altrimenti mi viene fame :)

Cosa sarebbe questo apparecchio?
Un laptop?
Un tablet?
Un cellulare?
Tutto.

Dalla foto si vede:

• Il monitor grande è quello di un laptop
• quello nello spazio sottostante è un tablet
• nello spazio piccolino centrale va posizionato un cellulare
• in quello a destra un HD SSD da i Tera
• infine in quello a sinistra un pannellino solare che alimenta una batteria al litio

Non si sa l'hardware dei vari dispositivi quanto sarà potente, perché anche se è tutto molto bello, è solo un concept. :)

Un aggeggio del genere potrebbe essere anche scomodo..per esempio usare un tablet come tastiera touch non è il massimo..e chissà usare il telefono come trackpad..per non parlare del dover appoggiare la mano sull'HD che riscalda, ottimo in inverno ma un po meno in estate :P

Nonostante sia un concept, però, non sembra irrealizzabile.

A mio parere l'elemento più "concept" del Bento Book è la batteria al litio che dovrebbe alimentare tutto questo ambaradam.

Un display da 15,4 pollici, un altro di 11, un altro da 4..tutti touch..senza contare l'hardware dentro! (se fosse mai costruito di certo da un aggeggio simile mi aspetto delle prestazioni più che ottime :) )

A questo ci si aggiunge il consumo dell'HD.

Inoltre il pannellino solare, che sta in una mano, dovrebbe essere tanto efficiente da riuscire a ricaricare a sufficienza la batteria!

Beh..forse la batteria invece che al litio dovrebbe essere al plutonio.. il pannellino non so :D

Però, nonostante questo l'idea è veramente bella!

Non oso immaginare il costo che potrebbe avere un laptop (?) del genere!

Anzi, oso :P

Parliamo di 3 periferiche con display OLED, touch, il più grande addirittura da 15,4''!

Il laptop da solo, che più di un laptop sembra un tablet particolarmente grande, avrebbe un costo di almeno 1000 euro a mio parere.

Il tablet, voglio essere buono, ma almeno 400 € dovrà pur costare..

Il telefono, e voglio essere ancora buono, almeno 200€ li costa.

Il disco, un SSD da ben 1 Tera..beh, io ne ho visto uno da 750 Giga a più di 2300€, voglio essere ancora buono, quello da 1 Tera ne costa solo 2500 :)

Siamo già arrivati a 4100€ non male :)

A questo ci si aggiungerebbe il costo della super batteria..e dell'idea originale!

Chissà..magari tra qualche anno i prezzi di queste tecnologie saranno così bassi da poter permettere davvero l'ingresso nel mercato di qualcosa del genere :)

Magari non accadrà mai, ma sarebbe forte :D

Ok..dopo queste belle chiacchiere (non mi ero accorto di aver scritto così tanto!) vi saluto!

Prima di chiudere il post, però, vi lascio con il resto delle foto che ho trovato..

Godetevele! :)

C++ e STL: ordinare una lista

Salve di nuovo.. :)

Visto che è da un bel po che non scrivo mezza riga di codice C++ voglio scrivere un post e cogliere l'occasione di scrivere qualcosina, seppur semplice.
Avevo intenzione di scrivere un semplice programmino per ordinare una lista utilizzando il metodo sort().

Innanzitutto la lista è un container di elementi, infatti è implementata nella STL (Standard Template Library) come template. E' implementata come una lista doppiamente linkata, ovvero ogni nodo è collegato al successivo ed al precedente, inoltre ci sono 2 nodi speciali, head e tail, o header e trailer, che rappresentano l'inizio (elemento precedente al primo) e la fine (elemento successivo all'ultimo) della lista.

Ok. dopo questa bella immagine passiamo al codice.
Innanzitutto cosa voglio fare: voglio creare una lista di interi ed ordinarla usando il metodo sort().

#include <iostream>;
#include <list>;

using namespace std;


bool intComparator(int a, int b) {
 return a <= b;
}


int main() {

 list<int> intList;

 intList.push_front(2);
 intList.push_front(5);
 intList.push_front(7);

 list<int>::iterator intIT;
 cout << "Original int list: \n";
 for(intIT = intList.begin(); (intIT != intList.end()); ++intIT)
  cout << *intIT << " ";
 cout << endl;

 intList.sort(intComparator);
 cout << "Ordered int list: ";
 for(intIT = intList.begin(); (intIT != intList.end()); ++intIT)
   cout << *intIT << " ";
 cout << endl;

 return 0;
}

Allora, dopo i classici include, per prima cosa mi dichiaro il mio comparatore. Il comparatore può essere qualsiasi funzione che prende 2 parametri dello stesso tipo e restituisce true se nell'ordinamento il primo elemento viene prima del secondo elemento, false altrimenti. 

Subito dopo comincia il main. Dichiaro una lista intList che farà da container di elementi di tipo intero.

Successivamente la riempio con un po' di numeri, li inserisco da "davanti" con push_front() che inserisce un elemento alla prima posizione della lista, quindi immediatamente dopo l'header. La sequenza ottenuta è quindi [7, 5, 2].

Fatto ciò stampo a video la lista disordinata. Dichiaro un iteratore intIT, che sarà quindi un container per degli elementi di una lista che contiene interi, dunque, sarà a sua volta un container per elementi di tipo intero.

L'iteratore viene inizializzato nel for con intList.begin() che restituisce il puntatore all'header.

Questo, quindi, deve essere incrementato per puntare al primo elemento, ed è la prima cosa che viene fatta nel for. 

Dopo di che non viene fatto altro che la stampa a video dell'elemento corrente. L'iteratore è un puntatore all'elemento corrente, quindi, per essere usato, va deferenziato.

Il ciclo finisce quando l'iteratore arriva a intList.end() che corrisponde al trailer della stessa.

Subito dopo il for avviene l'ordinamento della lista. Il metodo può essere richiamato anche senza parametri, in tal caso viene utilizzato la relazione "<" per il confronto.

Il metodo però accetta anche un argomento. Questo è il puntatore alla funzione comparatore scritta, identificato dal nome della funzione ovviamente, in questo caso intComparator.

In questo modo per eseguire il confronto tra gli elementi verrà utilizzata la funzione specificata.

Il programma si chiude stampando di nuovo la lista a video, stavolta ordinata :)

Ok, questo è un post molto "tranquillo" :)

Ma ho intenzione di utilizzarlo come trampolino di lancio per capire un paio di cose e condividerle.

Per esempio: se eseguo l'overload della funzione intComparator, come faccio a passare alla funzione il puntatore "esatto" della funzione che voglio eseguire? Viene deciso a runtime?

Inoltre voglio vedere anche come posso passargli un comparatore implementato in un'altra classe.

Vediamo che ne esce fuori.. :)

Al prossimo post!

BPEL e l'orchestrazione di servizi

Salve di nuovo :)

In questo post volevo parlare di un argomento che mi sta facendo penare non poco ultimamente :P
Intendo parlare di BPEL (Business Process Execution Language).
E' un linguaggio basato su file XML e la struttura del file non serve solo a descrivere i processi di business ma anche per eseguirli, quindi può essere considerato come un linguaggio di programmazione.

Può essere visto come un linguaggio interpretato e gli interpreti sono i motori BPEL. Questi motori non funzionano come un'interprete per un classico linguaggio di programmazione come potrebbe essere l'interprete Perl, ma piuttosto funzionano come dei container per processi di business.
Infatti per essere eseguito, un processo BPEL deve essere "deployato" su un motore, che ne controlla la validità e, se conforme alla specifica, lo rende "eseguibile" dai consumer.
Uso il termine "consumer" perchè BPEL è pensato principalmente per essere utilizzato in architetture SOA (Service Oriented Architecture) ed in esse l'utilizzatore di un servizio è chiamato consumer, che in linea di massima può essere considerato il client.
Personalmente ho fatto alcune prove utilizzando il motore Apache ODE (Orchestration Director Engine), il motore messo a disposizione da Intalio BPMS (Business Process Management System) ed il motore installabile in Virtuoso Universal Server tramite un'estensione.

BPEL è utilizzato in architetture Service-Oriented perché fondamentalmente un processo è visto come un servizio, o meglio, una volta fatto il deploy di un processo su un motore questo viene esposto verso l'esterno proprio come un web service che espone le proprie informazioni tramite WSDL.
Il processo, quindi, è un servizio a tutti gli effetti. Ai client che effettuano richieste il fatto che "dietro" la loro richiesta si nasconde un motore BPEL che esegue processi di business è assolutamente trasparente, essi vedono un servizio e nient'altro.

Cosa ha di diverso un processo BPEL, quindi, rispetto ad un normale web service?
BPEL può essere visto come uno strumento per offrire un servizio che scaturisce dalla composizione di altri servizi. In un'architettura SOA si parla di orchestrazione di servizi. Un processo BPEL quindi non espone operazioni semplici. Esso non fa altro che richiamare altri servizi per raggiungere un determinato scopo. Ad esempio può richiamare in sequenza diversi servizi utilizzando l'output del precedente come input del successivo, richiamare ciclicamente dei servizi ed eseguire anche parallelamente richieste a servizi diversi.
Alla fine del suo lavoro può ovviamente restituire un risultato al consumer oppure un fault. Possono essere eseguite sia richieste sincrone che asincrone. Insomma, è un web service :)

E' una cosa utile? comoda?
Potenzialmente si, praticamente ho i miei dubbi..

Come ogni cosa, ci sono dei pro e dei contro.

Pro:
L'unico che personalmente abbia trovato è che essendo un linguaggio XML-based, la sua struttura è ben definita, è facile eseguirne il parsing e la validazione. Questo ha reso possibile lo sviluppo di tool molto comodi per lo sviluppo di processi. Editor grafici che permettono di fare il design con il classico drag-and-drop.
Personalmente ho provato ad utilizzare il plugin per Eclipse BPEL Designer ed Intalio BPMS. Quest'ultimo non è proprio un designer BPEL. E' un designer per processi di business, ma modellati tramite BMPN (Business Process Model and Notation) che, a differenza di BPEL, è stato progettato solo per modellare i processi di business. Intalio comunque dal modello BPMN genera un file BPEL che può essere installato in qualsiasi motore. Ne esistono diversi altri, sia opensource che con licenze commerciali, ma non li ho mai utilizzati.
Devo dire che soprattutto Intalio è veramente comodo per modellare i processi, anche BPEL Designer lo è, ma richiede una conoscenza maggiore di BPEL per essere utilizzato.

Contro:
Purtroppo i contro (sempre riguardo la mia esperienza) sono molti di più dei pro.
Innanzitutto, come succede in molti editor grafici che cercano di fare ogni cosa dall'interfaccia senza eseguire nessun intervento sul codice, si perde ogni controllo su cosa succede "sotto" il designer. Questo problema l'ho riscontrato soprattutto con Intalio in quanto il loro framework è stato progettato per avere quello che viene chiamato zero-code development.
Effettivamente lo scopo è raggiunto, infatti anche volendo non c'è la minima possibilità di modificare a mano il codice dei processi. L'unico modo sarebbe prendere il file BPEL generato e modificarlo con un altro editor.
Con BPEL Designer, invece, la cosa non è così grave. Nonostante tramite l'editor grafico si possa fare praticamente tutto, è possibile modificare direttamente il codice sorgente del processo. Il problema è che non sempre l'interfaccia grafica "si accorge" delle modifiche fatte a mano.

Un altro problema, che personalmente trovo molto grave, è che siccome c'è un motore che legge il file XML ed in base al suo contenuto esegue delle azioni, è impossibile eseguire il debug di un processo. I tool grafici possono dire se ci sono errori di validazione. A volte si riesce ad eseguire il deploy di processi che non passano la validazione, ma non sempre è così. Questo non è un grosso problema, perché ad esempio ODE al momento del deploy se c'è qualcosa che non va da degli errori di compilazione, indicando dov'è il problema. I messaggi di errore a volte sono chiari, altre volte sono di difficile comprensione, ma almeno da qualche errore subito. Il problema nasce quando ci sono problemi nella logica, come qualche conversione dei dati, qualche assegnamento errato (si, un semplice assegnamento può essere qualcosa di molto poco semplice in BPEL), una condizione di uscita di un ciclo che non si verifica ecc..
E' comprensibile che non sia possibile eseguire un vero e proprio debug di un processo, ma il problema è che non si riesce ad avere nessun controllo sul processo installato. Quindi niente log personalizzati, niente messaggi ecc. Anche restituire un fault in base ad una condizione non è una cosa così semplice, ma li è colpa mia che non mi sono visto bene l'argomento :)
Quindi, per il capire cosa c'è che non va in un processo ci si deve basare sui messaggi di fault e sui log del motore. Ancora una volta, non sempre questi sono immediatamente comprensibili. Nella mia (breve) esperienza ogni volta che c'era qualcosa che non andava dovevo fare diverse ricerche per capire il significato dei messaggi di errore.

Ancora un altro problema: BPEL mal si adatta ai cambiamenti.
Infatti su diversi post, non necessariamente scritti da detrattori di BPEL (addirittura su un blog di un tipo che dava dei consigli ai neofiti), ho letto che quando c'è da fare qualche cambiamento o c'è qualcosa che non va in un processo, la cosa migliore è rimodellarlo daccapo. O_O
Ok, è una cosa che posso anche accettare se sto modellando un processo di Hello World, ma che succede se devo modificare un processo che magari richiama 10 servizi in parallelo, per ognuno gestisce i fault ed in base ad i risultati ricevuti decide se e quali altri servizi chiamare?

Ancora. Gli errori di validazione.
Non so voi, ma in generale ogni volta che c'è un errore di validazione in un file XML è un mal di testa.
Quando ci sono errori di validazione in file BPEL, o WSDL è ancora peggio.
Si, a volte si devono modificare anche i file WSDL di altri servizi che magari già sono funzionanti e installati in un web service engine perché per esempio (e mi è capitato con ODE) non supporta una direttiva import per importare schemi XSD che non siano locali.

Aderenza agli standard.
Come ho detto alcuni motori fanno i capricci su alcune cose, ad esempio Apache ODE con la questione degli import nei file WSDL.
Sempre per quanto riguarda Apache ODE (si è capito che è quello che ho utilizzato maggiormente? ) ho dovuto sbattere non poco la testa cercando di usare SOAP 1.2 per poi scoprire che solo l'1.1 è supportata.
La versione 1.2 è raccomandazione W3C dal lontano giugno 2003... ed ODE è un progetto tutt'altro che morto!
Infine, mi è capitato di constatare che semplici processi siano eseguiti da alcuni motori e non da altri.
In particolare mi è capitato che un semplicissimo processo di test funzionasse tranquillamente su Apache ODE ma sul motore di Virtuoso non riuscivo nemmeno a fare il deploy.

Insomma, BPEL 2.0 è standard dal 2004, ma i motori non sono ancora abbastanza maturi.

Conclusioni
Dopo alcuni giorni spesi a fare sperimentazioni varie mi sono fatto l'idea che BPEL si presta bene per implementare processi semplici, che utilizzano tipi di dati base e con un'orchestrazione non troppo laboriosa. Però lo standard è stato ideato proprio per implementare orchestrazioni complesse..
Inoltre non è facile da imparare, soprattutto l'utilizzo degli editor grafici porta a dover trovare un tutorial per ogni cosa che si vuole fare, per capire dove si deve cliccare ecc..
Infine i tool ed i motori nonostante i molti sforzi ancora non raggiungono un buon livello per essere utilizzati in ambiente industriale, però, io ho utilizzato solo tool opensource, magari le soluzioni proprietarie funzionano meglio.

Nonostante tutto, trovo BPEL un ottimo strumento per la modellazione dei processi. Però, per la modellazione, non per l'esecuzione.
Trovo che si possano metter su orchestrazioni di servizi in modo molto più semplice utilizzando altre tecnologie, utilizzando i web service engine per esporli ai client.

Queste sono solo considerazioni mie personali, magari sono dovute alla mia poca esperienza al riguardo, ma ho notato che sono idee abbastanza condivise in rete.
Chissà, se mi capiterà di acquisire un po' di esperienza (e spero di no) magari capisco tutti gli errori che ho commesso e mi ricredo, però visti i risultati scarsi ottenuti dopo qualche giorno di sperimentazione ne dubito fortemente :)

Ok, direi che si può concludere questo post che sembra più uno sfogo personale.. :P
Alla prossima :)

Web services: request asincrone

Salve di nuovo :)

In questo post voglio parlare di come invocare un web service facendo richieste asincrone.
Partiamo dal presupposto di aver già implementato un servizio e di aver a disposizione il file WSDL che lo descrive.
Per la generazione del client ovviamente non si parte da zero, ma si può utilizzare il plugin per Eclipse WSDL2Java per generare la maggior parte del codice necessario.

Con questo tool si possono generare automaticamente le classi per fare request sincrone e asincrone contemporaneamente. Dandogli in pasto il WSDL del servizio da utilizzare, questo genera tutte le classi per eventuali tipi di dati custom che le operazioni del servizio accettano come parametri o che restituiscono.

Supponiamo che il servizio implementato sia MyService, con una sola operazione, echo, che prende in input  una stringa e la restituisce. Il servizio non lancia eccezioni, per non complicare le cose :)
Le classi che vengono generate per il client sono:

• L'interfaccia MyService
• MyServiceResponse
• La classe astratta MyServiceCallbackHandler
• Echo (una classe per ogni operazione definita)
• MyService*Exception (una classe per ogni eccezione che può lanciare il servizio)
• MyServiceStub

Come per le richieste sincrone, la classe MyServiceStub viene utilizzata per settare i parametri della request e per invocare il servizio. La classe Echo (o qualsiasi altra classe corrispondente ad un'operazione) viene utilizzata per contenere i parametri dell'operazione, utilizzati poi dallo stub. Infine la classe MyServiceResponse ovviamente viene utilizzata per immagazzinare la risposta restituita dal servizio.

Per poter effettuare una request asincrona, è necessario utilizzare MyServiceCallbackHandler.

Questa è una classe astratta contenente dei metodi con implementazione vuota, uno per ogni operazione del servizio ed uno per ogni eccezione che questo può lanciare.

Quando la richiesta asincrona viene effettuata, viene lanciato un nuovo thread che si mette in attesa del completamento della request e viene eseguito il metodo associato all'operazione richiamata (o ad una condizione di eccezione) per gestire la risposta del servizio.

Infatti, tutti i metodi associati alle operazioni accettano come parametro un oggetto di tipo Response.

Invece, i metodi corrispondenti alle condizioni di eccezione, come si può immaginare, accettano un parametro di tipo Exception.

Bisogna quindi estendere tale classe ed implementare i metodi che ci interessano. Fortunatamente non c'è bisogno di implementarli tutti: i metodi di MyServiceCallbackHandler hanno tutti un'implementazione vuota, quindi se il nostro client utilizza una sola delle operazioni offerte da un servizio si può fare l'override dei metodi appropriati.

Supponiamo che la classe che implementa il callback handler si chiami CallbackImplementation (accorciamo un po il nome :P). 

Giusto per scrivere un po' di codice riporto l'implementazione di questa classe :) 

public class CallbackImplementation extends clientstubpackage.MyServiceCallbackHandler {

   private boolean complete;

   public CallbackImplementation() {
      complete = false
   }


   @Override
   public void receiveResultecho(
            clientstubpackage.MyServiceResponse result
                ) {
      System.out.println(result.getReturn());
      complete = true;
   }
}

L'implementazione del client che chiama il servizio è praticamente uguale ad un client sincrono, cambiano un paio di cose. I passi da seguire per richiamare il servizio sono:

• Istanziare un client stub
• Istanziare un oggetto per l'operazione da eseguire
• Istanziare un callback handler
• Settare eventuali parametri per l'operazione
• Richiamare il servizio con il metodo startOperation dello stub (invece di stub.operazione)

Ecco qui il codice che implementa il client ed esegue tutti i passi descritti:

public class ClientImplementation {

   public static void main(String[] args) {
  
      try {
         //inizializzazione stub
         MyServiceStub stub = new MyServiceStub();
         //inizializzazione handler
         CallbackImplementation handler = new CallbackImplementation();

        //inizializzazione dell'oggetto per l'operazione e settaggio parametri
        Echo echo = new Echo();
        echo.setContent("Stringa da restituire");
   
        long start = System.currentTimeMillis();
   
        stub.startecho(echo, handler); //inizio della chiamata asincrona
   
        while(!handler.hasCompleted()) {
           Thread.sleep(1000);
           long now = System.currentTimeMillis();
           System.out.println("Waiting.. " + ((now - start)/1000));
        }
   
        System.out.println("Done!");
       } catch (IOException e) {
          e.printStackTrace();
      } catch (InterruptedException e) {
          e.printStackTrace();
      }
   }

}

E questo è quanto.
Ci sono giusto 2 cose da mettere in evidenza, riguardante il metodo startecho.
La prima è che, come si vede dal codice, oltre ai parametri dell'operazione esso ha bisogno di un'istanza del callback handler.
La seconda, molto importante, è che si deve tener presente che al contrario delle request sincrone, quando viene fatta una request asincrona, richiamando il metodo startOperation dello stub viene lanciato un nuovo thread e l'esecuzione del metodo chiamante continua parallelamente.
Per questo c'è bisogno di controllare che questo finisca. In questo caso molto semplicemente l'handler quando completa il suo lavoro setta un flag a true, ed il metodo chiamante non fa altro che ciclare e controllare ogni secondo se la richiesta è stata completata (magari l'echo non ha bisogno di aspettare "secondi".. :P).

Ed anche questo post è finito, era da un po' che non postavo qualcosa..
Per i prossimi post ancora non ho deciso che scriverò, ho un paio di idee..vedrò il tempo e la voglia cosa mi porteranno a fare :)

Alla prossima!

Virtuoso Universal Server: un DBMS per tutto

Salve :)
In questo post volevo parlare di un DBMS che ho scoperto recentemente e ho trovato molto interessante.

Parlo di Virtuoso Universal Server (http://virtuoso.openlinksw.com/), un DBMS che, un po come tutti, promette di risolvere tutti i problemi del mondo :)
La particolarità di questo server è che effettivamente può fare un po' di tutto, nel senso che può essere usato sia come DBMS relazionale, sia come un NoSQL Database, come XML Store e come Triple Store.

Come DBMS relazionale offre un po' tutte le caratteristiche che offrono gli RDBMS tipici come MySQL e simili. Ovviamente supporta il linguaggio SQL, inoltre mette a disposizione molte funzioni utili.

Per quanto riguarda le sue funzionalità come XML Database, Virtuoso non è uno store nativo, cioè il documento XML non è visto come unità fondamentale di memorizzazione e i dati fisicamente non vengono memorizzato secondo la struttura di questi documenti. Infatti questi vengono memorizzati in tabelle SQL, come tipo di dato XML appunto. In pratica questo tipo di dato sarebbe un long varchar, ma utilizzando il tipo XML viene fatto anche il parsing dei documenti, in modo tale che, se durante un inserimento viene passato qualcosa che non è un documento ben formato, viene notificato direttamente un errore.
Ha diverse funzioni per l'utilizzo dei documenti XML e supporta XPath, XQuery e le trasformazioni XSLT.

Per quanto riguarda invece le sue funzionalità come Triple Store, il modello di dati utilizzato è il modello a grafo, che è quello utilizzato dalla maggior parte dei Triple Store che non si basano su database relazionali. In realtà non so il modello di dati fisico quale sia, ma il modello utilizzato per i dati in memoria è sicuramente a grafo.
E' possibile interrogarlo tramite il linguaggio SPARQL , eseguire update tramite SPARUL ed è possibile importare ed esportare dati in formato RDF. I formati di serializzazione RDF supportati sono HTML+RDFa, RDF-JSON, N3, Turtle, TriG, TriX e RDF/XML.


Virtuoso permette di essere utilizzato sia come SQL che NoSQL Database grazie alla virtualizzazione dei dati. Il modello fisico di memorizzazione è comune a tutti i motori DBMS, ma ognuno di essi vede i dati come se fossero memorizzati nel formato che più si adatta a loro.
La cosa penalizza le prestazioni?
In teoria potrebbe, ma in pratica leggendo in giro sembra sia abbastanza veloce. Personalmente l'ho provato solo su pochi dati e non ho eseguito nessuno stress test quindi non ho elementi per giudicare.
Come Triple Store sembra si comporti particolarmente bene. Ho visto diversi benchmark che lo confermano e anche in questa classifica W3C sembra si comporti abbastanza bene: http://www.w3.org/wiki/LargeTripleStores.

Questa immagine riassume un po la virtualizzazione dei dati e i vari moduli da cui è composto Virtuoso:

Un'altra caratteristica molto interessante è che è molto semplice esporre le funzionalità di Virtuoso come web services. Infatti supporta può essere interrogato sia utilizzando SOAP che REST.

Si possono scrivere delle stored procedures e pubblicarle direttamente come servizi, con tanto di generazione automatica del WSDL.

Inoltre è possibile in qualche modo riutilizzare anche i web service scritti in Java, modificando un po il codice per eseguire una sorta di wrap. E' possibile riutilizzare anche i servizi scritti in linguaggi della piattaforma .NET.

Infine è disponibile un'estensione per poter utilizzare Virtuoso come motore BPEL4WS!

Grazie a questa è possibile organizzare le orchestrazioni dei servizi facendone il deploy direttamente nel DBMS.

Insomma, a mio parere le potenzialità sono molte, soprattutto negli scenari in cui si ha bisogno di dover gestire diversi tipi di dati ed avere la gestione migliore per ognuno di essi.

Inoltre poter gestire i dati, i servizi e magari anche le orchestrazioni da un unico punto semplifica parecchio la gestione..

Per concludere, Virtuoso è disponibile sia in versione commerciale che open source. La versione open source ovviamente ha qualche limitazione, non supporta infatti la replicazione dei dati e quello che chiamano "Virtual Database Engine", che permette di eseguire query SQL su database multipli remoti.

Personalmente ho fatto qualche sperimentazione con la versione opensource. Credo che sia molto più comodo utilizzarlo su sistemi Unix che non su Windows. Su sistemi come Ubuntu, per esempio, sono disponibili già i binari installabili dal gestore di pacchetti. Su Windows invece per poterlo compilare c'è bisogno di strimenti come Visual Studio ed altra roba..

Bene, direi che ho concluso con questo post pubblicitario :)

In questi giorni ho accantonato Virtuoso per fare delle prove con l'XML Database eXist. Se lo trovo interessante magari scriverò qualcosina anche su quello :)

Al prossimo post!

Java e la ridirezione con processi esterni

Salve di nuovo :)

Visto che ultimamente ho scritto un post con tante chiacchiere e 2 righe di codice che servivano ad eseguire il redirect dello standard output e lo standard error su altri stream, ora voglio scrivere un post che parla di una cosa molto simile: eseguire il redirect di standard output e standard error, ma di processi esterni.

Ovviamente la cosa si può fare solo su processi di cui si ha il controllo via codice. per esempio dopo averli eseguiti con il metodo exec() di  java.io.Runtime.

Siccome il processo lanciato è indipendente da quello che l'ha generato allora l'I/O e l'error saranno su stream separati. In poche parole sul video non viene visualizzato nulla di quello che il nuovo processo stampa.
Quindi per poter ottenere comunque i dati che vengono stampati bisogna catturare lo stream di tale processo e successivamente stamparlo su qualche altro stream, magari lo standard I/O ed error del processo padre.

Il codice per fare tutto ciò è il seguente:

try {
   Process p = Runtime.getRuntime().exec("comando");
  
   String line;

   BufferedReader in = new BufferedReader(
               new InputStreamReader(p.getInputStream()) );

   while ((line = in.readLine()) != null) 
       System.out.println(line);
        
   in.close();
        
   in = new BufferedReader(
               new InputStreamReader(p.getErrorStream()) );

   while ((line = in.readLine()) != null)
       System.err.println(line);
        
   in.close();
}
catch(IOException | InterruptedException e) {
   e.printStackTrace();
}

E questo è quanto.
Ovviamente questo funziona con Java 7, altrimenti non si può fare la cosa figa del multi catch :)

Al prossimo post!

Tomcat e i file stream "pendenti"

Bene, oggi voglio parlare di un problemino che ho avuto un paio di giorni fa.

Mi ritrovavo a scrivere un web service e come engine usavo il solito Axis (eh si, ultimamente ho lavorato solo sui web services :P).
Il servizio utilizzava una libreria esterna che doveva fare delle conversioni e come output creava dei file. Dopo la conversione, il servizio creava un archivio zippato dell'output della libreria e cancellava i singoli file creati.
O almeno, questo era quello che volevo fare.
Infatti mi sono accorto che alcuni file non venivano cancellati. Sullo stesso output, a volte non riuscivo a cancellare dei file e a volte altri.
Il dubbio iniziale era che ci potesse essere qualche problema di permessi di Tomcat, ma ho scartato subito questa possibilità perchè altrimenti i file avrebbe dovuto cancellarmeli o tutti o nessuno.
Quindi ho capito che semplicemente restavano dei file aperti. La conferma l'ho avuta controllando con Process Explorer.

In un servlet container come Tomcat, quando restano dei file handler aperti, questi non vengono chiusi per tutta la vita del processo. Solo riavviando Tomcat questi vengono chiusi in quanto muore il processo che li tiene aperti.
Infatti nel mio caso, la prima esecuzione funzionava benissimo, erano le successive che mi davano problemi!

Ora, la libreria che utilizzavo fortunatamente era opensource, ma visto che non avevo tempo (e soprattutto perchè sono pigro :P), non potevo mettermi a capire quando e come la libreria apriva e chiudeva file, anche perchè non era così semplice il codice..

L'idea che ho avuto è questa: visto che gli handler vengono chiusi quando muore il processo, se questi vengono aperti in un processo esterno, vengono chiusi quando questo muore.

La libreria era un jar eseguibile anche da riga di comando, quindi potevo eseguirla tranquillamente con il metodo exec() della classe java.io.Runtime.
Il codice per fare ciò è questo:

try {   
    Process p = Runtime.getRuntime().exec("java -jar library.jar parameters");
    p.waitFor();
} catch (InterruptedException | IOException e) {
    e.printStackTrace();
}
  

In caso non sia possibile eseguire il jar da linea di comando basta creare un jar composto da una semplice classe che fa da wrapper ed utilizza il jar.

Magari questa non è la migliore soluzione a questo tipo di problemi..però è quella che mi è venuta in mente, ha funzionato e la condivido :)

Invio e ricezione di file da web services

Eccomi qui con un nuovo posto..
Ultimamente sto tenendo una bella media, chissà se riuscirò a tenere questa costanza.. :)

Bene, oggi volevo scrivere un post sull'invio e la ricezione di file verso e da un web service, visto che è una cosa che mi sono ritrovato a fare solo recentemente.

In questo post sia i servizi1 che i client saranno scritti in Java. Il web service engine che utilizzato è Apache Axis (installato su Tomcat 7) ed il protocollo di comunicazione è SOAP.

Per la generazione del pacchetto .aar contenente le classi per "deployare" il servizio in Axis è stato utilizzato il plugin per Eclipse "Service Archiver", mentre per creare il file WSDL dal codice del servizio e generare il client dal WSDL creato sono stati utilizzati Java2WSDL e WSDL2Java, entrambi contenuti nel plugin "Code Generator". Questi tool sono disponibili all'indirizzo: http://axis.apache.org/axis2/java/core/tools/index.html.

Prenderemo in considerazione un servizio, FileService che mette a disposizione 2 operazioni: UploadFile e GetFile.
La cosa importante affinchè le cose funzionino è definire la firma dei metodi corrispondenti alle operazioni affinchè il Code Generator possa generare un file WSDL con il giusto mapping tra i tipi.

Una prima prova potrebbe essere fatta specificando come parametro dell'operazione UploadFile e come tipo restituito dall'operazione GetFile semplicemente java.io.File. 
Purtroppo questa non è una buona soluzione. Se si prova ad utilizzare Java2WSDL con i metodi così definiti, verrà generato un correttamente il file WSDL desiderato. Il problema, però, nasce quando si utilizza WSDL2Java per generare il client. Dalle classi create si vede che il mapping dei tipi è abbastanza sballato, infatti ci sono delle classi come java.io.xsd.File che per essere utilizzate come minimo dovrebbero essere incluse in un package diverso, in quanto l'uso del nome java.io per un package è ovviamente proibito.
Non so se sia possibile utilizzare comunque java.io.File per il trasferimento dei dati, probabilmente definendo a mano i tipi complessi nel WSDL e costruento i messaggi SOAP tramite codice è possibile, ma se uno non ha tempo, o non ha voglia, o una combinazione delle 2, allora sarebbe preferibile percorrere un'altra strada :)

Bene, dopo aver visto questa non-soluzione passiamo alle 2 che ho sperimentato:

• trasferire dati tramite array di byte e DataHandler
• trasferire dati tramite DataHandler utilizzando MTOM per gli allegati SOAP

Array di Byte
Questo metodo è abbastanza intuitivo, per fare l'upload di un file si passa un'array di byte che rappresenta il contenuto del file e il web service che lo riceve lo scrive su file. Lato client, però, non si può passare semplicemente un array di byte, ma dev'essere passato un DataHandler.

Il servizio può essere per esempio il seguente:

public class ImportService { 
  public String importSingleFile(String name, byte[] content) {
     try {
       File f = new File(name); 
       BufferedWriter out = new BufferedWriter(new FileWriter(f));
       out.write(s);
       out.close();

       return "Import Successful!";
    } 
    catch(IOException e) {
       e.printStackTrace();
    }
  } 
 }  

Con Java2WSDL si può creare il file che descrive il servizio e con WSDL2Java si può generare il client che lo interroga. Il client sarà composto da una serie di classi,tra cui ImportStub e ImportSingleFile che corrispondono rispettivamente al servizio ed all'operazione da richiamare.

Il client, per poter trasferire il file al servizio, dovrà:

• aprire il file che vuole trasferire
• associare il file ad un DataSource (presente in javax.activation)
• associare il DataSource ad un DataHandler (sempre in javax.activation)
• richiamare il servizio

Ecco il codice:

public class Client { 
  public static void main(String args[]) {
     try {
       ImportStub stub = new ImportStub(); 
       ImportSingleFile single = new ImportSingleFile();
       
       File f = new File("upload.txt");
       FileDataSource ds = new FileDataSource(f);
       DataHandler dh = new DataHandler(ds);

       single.setName(f.getName());
       single.setContent(dh);

       ImportSingleFileResponse res = stub.importSingleFile(single);

       System.out.println(res.get_return());
    } 
    catch(IOException | AxisFault e) {
       e.printStackTrace();
    }
  } 
 }  

 E questo è quanto.
Il problema con questa soluzione è che i dati binari vengono codificati come testo per poi venire spediti in messaggi SOAP. Per ovviare a questo problema è possibile utilizzare MTOM.


MTOM e DataHandlers
MTOM  (Message Transmission Optimization Mechanism) è una raccomandazione W3C per inviare e ricevere dati binari da web services. Altri meccanismi possono essere utilizzati per lo stesso scopo, come SwA (SOAP with Attachments) e i DIME Attachments, ma a MTOM sembra sia migliore di questi ultimi.

Per poterlo utilizzare in Axis è necessario abilitarlo: bisogna editare il file di configurazione axis/WEB-INF/conf/axis2.xml e settare a true il parametro enableMTOM.

Fatto ciò si può scrivere il servizio. In realtà cambia molto poco: invece di un array di byte come parametro prende un DataHandler. Ecco il codice:

public class ImportService { 
  public String importSingleFile(String name, DataHandler dh) {
     try {
       File f = new File(name); 
       FileOutputStream fos = new FileOutputStream(f);

       dh.writeTo(fos);
       fos.close();

       return "Import Successful!";
    } 
    catch(IOException e) {
       e.printStackTrace();
    }
  } 
 }  

Il client invece resta esattamente uguale.

E così si conclude questo post..spero di scrivere qualche altra cosa presto! :)

Java e la redirezione

Salve :)
Eccomi qui con un nuovo post. Voglio parlare di una questione che ho affrontato pochi giorni fa.

In C in ambiente Unix è molto semplice fare la ridirezione di flussi come lo Standard I/O o lo Standard Error. In Java, come si può immaginare, è altrettanto semplice :)
Mi sono ritrovato ad utilizzare la ridirezione utilizzando delle librerie in un progetto. Era una libreria opensource per eseguire delle conversioni di manualistica che segue lo standard S1000D. Funziona bene, fa il suo sporco lavoro, ma sfortunatamente quando c'è qualcosa che non va invece di lanciare eccezioni, restituire qualcosa in particolare o qualsiasi altra cosa, scrive semplicemente sullo Standard IO l'eccezione avvenuta.
Questo fin quando la si utilizza da riga di comando è tranquillamente accettabile, ma quando la si utilizza attraverso un web service deployato sotto Axis fallisce "silenziosamente", infatti non è possibile visualizzare eventuali messaggi di errore.
Da bravo pigro e per sbrigarmi non sono stato a modificare i sorgenti della libreria, ma ho rididezionato l'I/O e gli errori su file.

E' un'operazione estremamente semplice, facile anche da cercare su google, ma visto che avevo voglia di scrivere un post, che non fosse troppo lungo o impegnativo, la riporto qui :)

I passi da seguire sono 2:

1. Aprire un PrintStream sul file nel quale si desidera siano scritti i contenuti
2. Settare il System.out affinchè utilizzi lo stream

Di seguito c'è un esempio su come ridirigere lo standard I/O e lo standard error su 2 file diversi:

PrintStream ioStream = new PrintStream(new File("IO.txt")); 
PrintStream errorStream = new PrintStream(new File("error.txt"));  


System.setOut(ioStream); 
System.setErr(errorStream);
 

Bene, un post intero per 4 righe di codice!
Ma avevo voglia di scrivere, cosa alquanto rara e non avevo voglia di scrivere niente di impegnativo :)

Cotton Candy, una smart pen Android!

E' da una vita che non scrivo qualcosa su questo blog...
Ogni tanto però ritorno :)

Ultimamente mi sono trovato ad affrontare molte problematiche interessanti in ambito lavorativo e spero di avere tempo e soprattutto voglia di scrivere qualcosa sulle problematiche che mi sono trovato ad affrontare e che mi hanno fatto impazzire.

 Per ora voglio buttare giù 2 righe su questa Cotton Candy (http://www.fxitech.com/products/).

Praticamente un mini PC in una chiavetta, che permette di utilizzare un qualsiasi televisore che abbia una porta HDMI come un PC, con la comodità di poterla portare sempre con sè viste le ridotte dimensioni.
La cosa interessante è che le caretteristiche tecniche non hanno nulla da invidiare agli smartphone più avanzati:

• CPU ARM Cortex-A9, 1.2GHz (non so se dual o quad core)
• GPU ARM Mali, 400MP Quad Core
• 1 GB di Ram
• Storage fino a 64GB con micro SD

 I sistemi operativi a che può montare sono Ubuntu o Android, ma dispone persino di un client per la virtualizzazione per Windows e Mac OS!
Inoltre ha connettività Bluetooth e Wifi b/g e persino n.

Questo apparecchietto dovrebbe essere commercializzato in italia a fine estate, il costo approssimativo si stima essere intorno ai 200 dollari..
In questo articolo è presente anche un bel video dove dimostrano il suo utilizzo.

Intanto che l'apparecchio venga commercializzato, la FXI permette di preordinare la Cotton Candy :)
http://www.fxitech.com/2012/02/fxi-launches-cotton-candy-developers-site-take-pre-orders/

Beh, sarebbe molto interessante poter "giocare" con un apparecchietto simile, chissà in Italia se e a che prezzo verrà messo in vendita!!