WCF, IBM WebSphere Process Server e Tuscany

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.

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). Poi WCF ha delle altre particolarità che lo rendono ancora più valido per chi sviluppa su Windows ma questo esula dal discorso.