In Vista

Oggi io e un mio collaboratore siamo quasi impazziti per capire come mai le chiamate seguite da una portlet Java (ospitata in un IBM WCS) non funzionavano con un servizio REST/POX scritto in WCF. La cosa interessante è che le chiamate al servizio effettuate da un paio di (veramente piccoli) script PowerShell di prova funzionavano. Era evidente quindi che si trattava di un problema di comunicazione fra i due mondi. I problemi spaziavano dalla dalla indicazione della codifica alla mancanza di namespace e di campi. Il tutto dovuto fondamentalmente allo stack Java troppo vecchio (con l’IBM WebSphere Portal Server 6 non sarebbe successo).

Per fortuna che il WCF ha delle ottime funzionalità di tracing che ci hanno aiutato a isolare i problemi. E, nonostante questo, ci abbiamo perso delle ore.

Forse l’ho già detto ma io penso che il WCF sia proprio un gran bel pezzo di software! 

A causa di un problema di specifiche supportate troppo vecchie da parte di una vecchia versione di portale IBM WebSphere Portal Server, ho dovuto cimentarmi nell’esporre in WCF un servizio tramite REST e POX. Andato a caccia di un po’ di esempi nell’SDK e dopo qualche esperimento in poco tempo ho avuto il servizio attivo. Indubbiamente il framework è molto potente e permette il controllo praticamente totale del dialogo. Però utilizzare un modello REST con POX vuol dire scendere ad un livello più basso cioè “lavorare con le tubature”. Efficace ma sicuramente meno elegante.

Invidiate il NY Times per il loro lettore offline? Volete creare una rivista elettronica aziendale? Aggiornata in modo automatico? Volete fare in modo che le stampe siano di ottima qualità e in stile giornalistico? Oppure semplicemente volete vedere come costruire una applicazione del genere usando WPF?

Allora il Syndicated Client Experiences Starter Kit è quello che ci vuole.

Come esempio forniscono MSDNReader, un lettore per gli articoli MSDN Magazine.

Devo dire che all’inizio LINQ in C# mi lasciava un po’ perplesso. L’idea di complicare il linguaggio di programmazione aggiungendo costrutti mi rende nervoso. Io la chiamo sindrome da PL/I ma l’ho sperimentata con il C++: il linguaggio diviene così complesso che per realizzare un progetto serve un esperto del linguaggio stesso.

LINQ in realtà si integra bene con C# e diviene presto naturale utilizzarlo. Per provarlo ho aggiunto delle funzioni di ricerca relativamente sofisticate ad un mio programma (in realtà è il mio Pet Project che uso per fare esperimenti) utilizzando il binding SQL.

Ho creato un piccolo parser utilizzando una serie di if con una serie di espressioni regolari. Ho cablato diverse query utilizzando i risultati di questo piccolo parser. In pratica prelevo il contenuto del TextBox di ricerca e quando soddisfa il match con una espressione regolare simile a questa (ho semplificato il codice)

Regex reAnnoMese =
   new Regex(@"^([0-9]){4}\s+[a-zA-Z]+$");

eseguo la query corrispondente simile a questa

if (reAnnoMese.Match(searchText).Success)
{
   RicevutaDataContext dcRicevuta
      = new RicevutaDataContext();
   int posSpazio = searchText.IndexOf(" ");
   string anno = searchText.Substring(0, posSpazio);
   string mese = searchText.Substring(posSpazio + 1);
   int numeroMese = GetMonthNumber(mese);
   var queryRicevuta =
      from ricevuta in dcRicevuta.Ricevutas
      orderby ricevuta.Anno descending,
              ricevuta.Numero descending
      where ricevuta.Anno.Equals(anno)
         && ricevuta.DataEmissione.Value.Month
            == numeroMese
      select ricevuta;
   DataContext = queryRicevuta;
}

RicevutaDataContext è un DataContext creato con un semplice drag&drop della tabella Ricevuta dal mappatore del VS2008. GetMonthNumber è una funzione che restituisce il numero ordinale corrispondente al mese e utilizza al suo interno le funzioni .NET per la localizzazione e che restituiscono i nomi dei mesi. Nell’ultima istruzione effettuo il binding della query con un elemento WPF (una Page contenente una ListView in questo caso).

Se nel TextBox scrivete 2006 giugno (o June: dipende dalle impostazioni) questo codice estrae tutte le ricevute emesse nel giugno 2006. LINQ genere codice SQL del tipo:

SELECT [t0].[IdRicevuta],
       [t0].[Numero], [t0].[Anno],
       [t0].[DataEmissione], [t0].[Intestazione], ....
FROM [dbo].[Ricevuta] AS [t0]
WHERE ([t0].[Anno] = @p0)
AND (DATEPART(Month, [t0].[DataEmissione]) = @p1)
ORDER BY [t0].[Anno] DESC, [t0].[Numero] DESC

Il fatto che il risultato della query LINQ non sia altro che una collezione .NET (per la precisione un IEnumerable su cui è possibile navigare) ne rende l’utilizzo praticamente trasparente.

Il codice non è particolarmente furbo (e neanche elegante) ma è proprio questa la sua bellezza: l’ho scritto senza pensarci troppo e ho ottenuto un buon risultato. Altri meccanismi mi avrebbero costretto a ragionare troppo (Ehi, sono quasi in vacanza!), ad utilizzare classi più complesse, a passare per sofisticati ORM, a scrivere SQL.

Mi sono divertito ad utilizzare un po’ di icone vettoriali (convertendo alcuni file WMF).

Come si nota il risultato nel Magnifier di Windows Vista è notevole. Mi piace soprattutto il contrasto tra la grafica vettoriale del WPF e la grafica raster del cursore del mouse.

IBM ha rilasciato PowerShell for WebSphere MQ, un Support Pac per MQ sulla piattaforma Windows che ne permette la gestione tramite PowerShell. MQ è un middleware IBM che permette la comunicazione di differenti programmi su differenti piattaforme tramite un sistema a code distribuite. E’ un software estremamente affidabile e longevo che abbiamo usato con successo in molteplici scenari multipiattaforma. Ovviamente è un ottimo software utile in scenari di integrazione di sistemi (o in certe implementazioni di architetture SOA).

Non è la prima volta che IBM si integra egregiamente con Windows (il DB2, per esempio) e non è neppure la prima volta che si avventura sulle nuove caratteristiche rese disponibili da Microsoft. Ma, riguardo MQ,  molto interessante è il canale MQ per WCF. Questo software integra il Windows Communications Framework con MQ utilizzando SOAP per JMS. In altri termini rende facile la comunicazione fra sistemi .NET 3.x (e in ultima analisi Windows) e sistemi collegabili a WebSphere MQ come WebSphere Application Server o il CICS. Significa che si potrebbero integrare queste potenti tecnologie IBM (legacy e non) con i nuovi potenti framework di Microsoft. Peccato sia solo un proof of concept e per di più con alcune mancanze fondamentali e quindi non utilizzabile in produzione.

Uno dei progetti che sto seguendo in questi giorni prevede l’integrazione in architettura SOA di un sistema di radio terminali con Windows CE e Wi-Fi con altri sistemi tra cui un iSeries e alcune applicazioni WebSphere. Trattandosi di un progetto pilota in un “Java Shop” (più propriamente un utente IBM WebSphere) abbiamo simulato la presenza di un ESB mediante una semplice applicazione J2EE (processi, coreografie e business object sono molto semplici quindi il discorso ci stava).

Dal punto di vista tecnologico quando si fa integrazione di sistemi eterogenei esiste un forza che contrasta l’obiettivo. Io la definisco genericamente “impedenza”. In pratica se due sistemi si devono parlare queste impedenza fa di tutto perchè ciò non avvenga. Un sistema completamente chiuso senza alcuna documentazione e nessuna possibilità di utilizzarne i dati e/o le transazioni porta l’impedenza all’infinito. Se ho N sistemi l’impedenza totale è data dalla combinazione dell’impedenza di ogni interazione possibile. Oltre a questo l’impedenza aumenta quando i due sistemi devono essere fortemente accoppiati (come al limite in un classico client server). Per semplificare l’integrazione occorre diminuire il valore di questa impedenza. In tal senso, dato che riduce il numero di interazioni e semplifica l’uso della tecnologia di integrazione, un ESB diminuisce questa impedenza. SOA lo fa ulteriormente estendendosi anche alla parte “organizzativa”.

Tornando al nostro progetto, per diminuirne l’impedenza abbiamo deciso di utilizzare .NET per l’integrazione dei terminali e il server di gestione degli stessi. In altri termini il software sui radio terminali è scritto in .NET Compact Framework mentre il server dei radio terminali è nato come una applicazione .NET Framework. Per far parlare i terminali con il server e, soprattutto, il server con il nostro pseudo ESB abbiamo utilizzato il Windows Communication Framework (WCF). Il nostro pseudo ESB utilizza poi Java per comunicare con altri sistemi Java e con l’iSeries (tramite JTOpen 400).

Chiaramente l’impedenza di due elementi che utilizzano lo stesso framework per comunicare è veramente bassa. Fatta l’interfaccia e pubblicato i servizi la scrittura del client su radio terminale ha richiesto poche ore. Lo stesso è accaduto tra gli elementi Java dove si è perso più tempo nel decidere cosa fare che nel farlo.

L’aspetto che però, come sempre, più mi ha colpito è la comunicazione fra WCF e J2EE. Se si tolgono alcune noiosità l’impedenza tecnologica tra J2EE (su WebSphere Application Server 6.1 ed Eclipse 3.3) e WCF (su .NET 3.5 e VS200 è veramente bassa. Gli standard WS-qualcosa semplificano la vita ma soprattutto i tool sono in grado di utilizzarli in modo efficace (non era così ai tempi di .NET 2.0). Alcuni aspetti di scrittura di codice ripetitivi e noiosi si possono aggirare utilizzando furbescamente e in modo parametrico la reflection sia in Java che in .NET. Ed è interessante il fatto che io stia parlando della parte bassa dello stack senza scomodare tool come Biztalk o WebSphere Process Server.

Se aggiungiamo il fatto che entrambi i framework parlano con il proprio legacy (IBM J2EE con mainframe/COBOL/DB2/CICS/IMS/iSeries/ecc. e Microsoft con COM/DCOM/COM+/WIN32/ecc.) ci si rende conto di trovarsi di fronte a delle possibilità molto ampie.

Certo utilizzare questi tool richiede una certa esperienza (ci è capitato persino di trovare WebServices assolutamente perversi e praticamente inutilizzabili) ma, in definitiva, quando si parla di interoperabilità tra i due mondi sia le tecnologie Microsoft che quelle IBM/J2EE possono essere utilizzate con fiducia.

The Architecture Journal is an independent (di Microsoft a mio giudizio) platform for free thinkers and practitioners of IT architecture. New editions are issued quarterly with articles designed to offer perspective, share knowledge, and help you learn the discipline and pursue the art of IT architecture. The Architecture Journal reaches over 53,000 subscribers worldwide.

Ora si può leggere anche offline usando l’Architecture Journal Reader, una applicazione WPF (quindi su .NET 3.0) simile a quella del NYT.

Cosa c’è di particolare in questa immagine?

Si tratta di una applicazione XBAP eseguita su Windows (Vista) ma all’interno di Firefox.

Infine è arrivato. Mi riferisco a Visual Studio 2008. Sicuramente la notizia non è nuovissima ma dopo qualche giorno d’uso della versione definitiva mi sembrava necessario accennarne.

Visual Studio 2008 è la versione dell’ambiente di sviluppo più adatta a Windows Vista. Ovviamente si installa e gira perfettamente sopra il sistema senza necessità di fix. Ma la parte più significativa è l’integrazione dei tool per sfruttare bene il framework .NET 3.5. Ha parecchie funzionalità interessanti (LINQ, il nuovo progetto per i servizi WCF, il supporto AJAX, ecc.).

Ma in questi giorni mi affascina l’editor per lo XAML del WPF: vedere in azione le capacità di aiuto contestuale nella digitazione del codice è impressionante. Soprattutto se si pensa alla complessità di XAML nel contesto di una programmazione WPF.

Veramente un bel lavoro.