Archive

SOA

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 VS2008) è 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.

Abbiamo appena pubblicato un white paper che parla dell’uso di SOA per la realizzazione di sistemi MES (Manifacturing Execution System). Lo trovate qui: http://www.santineassociati.com/ViewSelectedNews.aspx?NewsId=40.

Nel frattempo stiamo anche cercando di preparare anche un blog dedicato alle nostre esperienze SOA e alla tecnologia sottostante. Sarà scritto a più mani e molto più “serioso” di questo, ovviamente. Ma speriamo possa interessare un’altro tipo di platea e che possa creare un punto di riferimento e discussione interessante.

Qui comunque continuerò a parlare di Vista.

Questo è un post sulle “tubature”.

IBM WebSphere Process Server implementa SCA e SDO, delle specifiche molto note per chi lavora con tool simili. Fondamentalmente usando questo tipo di tool è possibile definire una serie di servizi e di oggetti utilizzati/forniti dai servizi utilizzando linguaggi come WSDL e XSD. Da questi è poi possibile passare a delle implementazioni in vari linguaggi (fondamentalmente Java e C++). E’ anche possibile definire un servizio partendo dal codice stesso. Il canale di comunicazione utilizzato è poi fondamentalmente indipendente dal definizione del servizio (e dal codice che lo implementa, ovviamente).

Scartabellando qua è là mi è saltato l’occhio su un esempio di codice Java che potrebbe costituire un semplice servizio:

    public interface Calculator
    {
        float add(float operand1, float operand2);
    }

    public class CalculatorImpl implements Calculator
    {
        public float add(float operand1, float operand2)     {
            return operand1 + operand2;
        }
    }

Questo codice definisce una interfaccia e una classe che la implementa.  Grazie ad una serie di file di configurazione (in XML)  e/o a delle operazione di deployment il sistema genera il codice che ne permette l’utilizzo remotamente (via code, WebServices o meccanismi analoghi).  In generale i meccanismi che realizzano i “tubi” sono nascosti dai tool. In realtà usando Process Server si procederebbe alla definizione del servizio (tramite un tool basato su Eclipse che fondamentalmente genera WSDL) e poi alla generazione del codice.

In WCF (e C#) si procederebbe così:

    [ServiceContract()]
    public interface ICalculator
    {
        [OperationContract]
        float add(float operand1, float operand2);
    }

    public class CalculatorImpl : ICalculator
    {
        public float add(float operand1, float operand2)
        {
            return operand1 + operand2;
        }
    }

Poi grazie ad una serie di file di configurazione (in XML)  e/o a delle operazione di deployment il sistema genera il codice che ne permette l’utilizzo remotamente (via code, WebServices o meccanismi analoghi).  In generale i meccanismi che realizzano i “tubi” sono nascosti dai tool. 

Perchè mi sembra di ripetermi? 😉

E’ interessante notare che normalmente nel mondo Microsoft si procede scrivendo il codice e poi lo si decora con degli attributi. Infine un tool procede a generare il codice di implementazione e i file di configurazione. Nulla vieta però di partire direttamente dal WSDL.

Direi che oggi la principale differenza fra i due mondi è proprio questa: il programmatore Microsoft solitamente parte dal codice e poi procede a generare la definizione del servizio, il programmatore IBM/Java solitamente parte dalla definizione dei servizi e poi procede a generare il codice. Da notare che questo aspetto riguarda soprattutto i tool.

Tuscany è una implementazione del consorzio Apache di SCA e SDO. Quando sarà terminato la piattaforma Java avrà un meccanismo open source (e quindi diffuso e a basso prezzo) per realizzare una buona parte di quello che si fa con WCF. Se i due mondi saranno in grado di interoperare senza particolari problemi si potrà utilizzare un meccanismo ad alto livello che faciliterà enormemente l’integrazione di programmi su piattaforme differenti.

Come sempre WCF fa parte di .NET 3.0 e quindi gira anche su XP e 2003 ma su Vista viaggia ancora meglio.

WCF potrebbe essere la tecnologia di base per realizzare un Enterprise Service Bus (in senso SOA) su Windows (aggiungendo Biztalk e un po’ di testa). Le implicazioni su Vista sarebbero interessanti da sviscerare e magari ci tornerò in futuro.

Poi WCF ha delle altre particolarità che lo rendono ancora più valido per chi sviluppa su Windows ma questo esula dal discorso.