Per prima cosa in .NET si definisce una interfaccia e la si decora con i soliti attributi ServiceContract, DataContract, OperationContract. E importante notare che la gestione di campi XML in maiuscolo non è ben supportata dal generatore Java e pertanto conviene creare DataContract con campi con iniziali in minuscolo. In alternativa si possono sfruttare gli attributi di generazione XML sui DataContract

[DataContract(
	Name="DatiServizio",
	Namespace="<http://example.com/esempio>")];
public class DatiServizio
{
	[DataMember]
	[XmlElement(Name="testo")]
	public string Testo { set; get; }
	[DataMember]
	[XmlElement(Name="numero")]
	public decimal Numero { set; get; }
} 

[ServiceContract(
	Name="DatiServizio",
	Namespace="<http://example.com/esempio>")];
public interface IServizio
{
	[OperationContract]
	string FaiQualcosa(DatiServizio dati);
}

Nella implementazione della interfaccia si utilizza l’attributo ServiceBehaviour per
fornire altre informazioni sui namespace:

[ServiceBehavior(
	Name="Servizio",
	Namespace="http://example.com/esempio")]
class ServizioType : IServizio
{
	// codice omesso...
}

A questo punto è necessario creare un corretto file di configurazione app.config. In particolare nella sezione dedicata al WCF si inseriscono queste informazioni:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <services>
      <service behaviorConfiguration="Servizio" name="ServizioType">
        <endpoint
           address="Servizio"
           binding="basicHttpBinding"
           bindingConfiguration="ServizioBinding"
           name="ServizioEndpoint"
           bindingName="Servizio"
           bindingNamespace="http://example.com/esempio"
           contract="IServizio" />
        <host>
          <baseAddresses>
            <add baseAddress="http://localhost:8000/Servizio" />
          </baseAddresses>
        </host>
      </service>
    </services>

    <bindings>
      <basicHttpBinding>
        <binding name="ServizioBinding" />
      </basicHttpBinding>
    </bindings>

    <behaviors>
      <serviceBehaviors>
        <behavior name="Servizio">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Con queste configurazioni tutti i namespace risultano a posto e il WSDL generato automaticamente (http://localhost:8000/Servizio?wsdl) è in grado di essere mangiato direttamente dal generatore WSDL del RAD/AST.

Non è la prima volta che IBM si integra egregiamente con Windows (pensiamo al 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.

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.

Il problema, secondo me, è che Microsoft manca di credibilità in questo ruolo di player nell’arena della SOA. Ha tutti i tool necessari e comincia a fornire anche le risorse per supportare questo modo di sviluppare le organizzazioni e le applicazioni. Però, storicamente, i forti player SOA arrivano dal mondo cross-platform e della integrazione. Microsoft non ha mai avuto una grande visibilità in questo mondo per ovvi motivi: fino a poco tempo fa la sua visione era totalmente Windows-centrica. Per supportare veramente tutto questo devono darsi da fare e creare una rete di partner veramente qualificati sull’argomento e devono cominciare a proporre il concetto ai loro clienti in modo molto più attivo. E questo è difficile farlo.

Tutto questo mi ricorda la “guerra” degli application server. Microsoft ha avuto un application server simile a quelli J2EE in ogni sistema Windows con .NET ma non l’ha mai venduto come concetto.

A onor del vero molti altri player forti in altre aree che si cimentano (o almeno tentano) in questa arena SOA soffrono di una visione “proprio prodotto”-centrica. Ed in effetti hanno gli stessi problemi.

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.