Web Services: stili, overloading e databinding

Nei precedenti post avevo già segnalato il fatto che per mantenere l’interoperabilità dei web services, partendo da un file wsdl, occorre rispettare il cosiddetto Basic Profile 1.1. Il Basic Profile non fa altro che far applicare delle restrizioni sulla scrittura del file wsdl in modo tale da garantire una certa interoperabilità.

L’interoperabilità non significa che tutto puo’ funzionare come vogliamo noi e difatti uno dei problemi di cui vi sto accennando nell’articolo è il problema dell’overloading dei metodi.

Occorre dire che ci sono principalmente 2 modi per descrivere un file wsdl compatibile con il Basic Profile e questi sono RPC/literal e Document/literal (per maggiori dettagli vedere il seguente articolo). Fatto sta che tra le 2 quella più usata è Document/literal in versione “wrapped”.

Questa versione è usata in pratica da .NET di default mentre la versione RPC no, tra l’altro Microsoft fa parte del consorzio WS-I, di consequenza scegliere per scegliere uno stile conviene adottare questo in modo da essere interoperabili con .NET (non me ne vogliano i puristi ma io lavoro con web services in java e questi devono comunicare in web services in .NET).

Secondo l’articolo che vi ho linkato un esempio di file wsdl in stile Document/literal wrapped è il seguente:

<types>
    <schema>
        <element name="myMethod">
            <complexType>
                <sequence>
                    <element name="x" type="xsd:int"/>
                    <element name="y" type="xsd:float"/>
                </sequence>
            </complexType>
        </element>
        <element name="myMethodResponse">
            <complexType/>
        </element>
    </schema>
</types>
<message name="myMethodRequest">
    <part name="parameters" element="myMethod"/>
</message>
<message name="empty">
    <part name="parameters" element="myMethodResponse"/>
</message>

<portType name="PT">
    <operation name="myMethod">
        <input message="myMethodRequest"/>
        <output message="empty"/>
    </operation>
</portType>

Come vedete la sezione message contiene solo una “part” per input/output. La parte che contiene l’input ha l’elemento myMethod, nome che deve essere uguale al nome dell’operazione. L’elemento myMethod è quindi un tipo complesso definito da una sequenza di elementi.

Uno dei problemi messi in evidenza è l’impossibilità di fare overloading dei metodi perchè se il metodo myMethod  con i 2 parametri corrisponde all’elemento myMethod non è possibile aggiungere in xml un secondo elemento dal nome myMethod con un solo parametro per via dell’XML stesso.

Tuttavia il problema diciamo non si pone poichè solo con file WSDL 1.1 è possibile l’overloading mentre con file WSDL 2.0 no anche se l’adozione di quest’ultimo non trova piena applicazione.

A riguardo l’uso dello stile wrapped vi suggerisco un articolo tratto dal blog di  Anne Thomas Annes, esperta in web services, che ha collaborato con WS-I ed una interessante spiegazione in questa mailling list (vedere ore 13:43)

Il tutto ovviamente si ricollega al databinding perchè, stile a parte,  occorre scegliere il databinding, e il fatto che ADB e Jibx supportano lo stile unwrapped e wrapped mentre Xmlbeans solo wrapped  (vedi articolo) viene meno se scegliamo lo stile wrapped.

Personalmente uso Xmlbeans per una serie di metodi utili forniti dall’interfaccia che ogni oggetto xml implementa. Per alcuni dettagli sulla storia e struttura di xmlbeans suggerisco questo articolo (oltre che il sito ufficiale) di David Bau uno dei creatori di Xmlbeans.

Nota a parte: ADB e Xmlbeans sono databinding della Apache foundation. Xmlbeans in particolare è stato donato da Bea System (nel settembre 2003), una delle società fondatrici della WS-I, da sempre coinvolta nel campo dei web services con il suo Esb, e di recente (aprile 2008) comprata da Oracle altra società fondatrice e leadership della WS-I.

Non penso di rompervi più con il Basic Profile :-)

Advertisements

Web Services e interoperabilità

Lavorando con i web services sorge il problema dell’interoperabilità, magari qualcuno si chiede “ma come è possibile? I web services garantiscono l’interoperabilità grazie al fatto che espongono servizi sulla rete e poi ho li ho anche validati…”. Ebbene si questo è in parte vero in parte perchè spesse volte si riferiscono a xml schema e quindi strumenti (come Eclipse) ne garantiscono la validità se questi schema vengono rispettati.

Ma ciò non basta. Non basta perchè il modo in cui sono scritti influenza il modo in cui le classi java o C# sono generate e ne sto qui a parlare proprio perchè in azienda abbiamo avuto questo problema. Un’altra azienda ha scritto dei file wsdl da cui ha generato classi java (tramite lo strumento di Axis2 wsdl2java) e su cui poi ha lavorato per un progetto. Questo progetto dovrà poi essere realizzato in C# con piattaforma .NET.

Fatto sta che gli strumenti che generano le classi C# non riescono perchè non trovano valido il file wsdl utilizzato!!! Vi domanderete “come faccio a sapere quali sono gli accorgimenti che devo prendere?”

Attualmente la bibbia di riferimento è il Basic Profile, una sorta di studio che ha portato a definire delle regole per ridurre i rischi derivanti dall’interoperabilità. Il BP è stato realizzato dal Web Service Organisation WS-I una specie di consorzio guidato da SAP, Fujitsu, Microsoft, HP, Sun, IBM, Intel, Oracle ecc

In questo BP si fa cenno a diverse tecnologie per usate per i web services SOAP, WSDL UDDI, XML schema, HTTP e HTTPS vi invito quindi a dare uno sguardo.

Al di là della sola lettura occorrono strumenti di verifica e che ho trovato grazie a questo articolo. In pratica il WS-I ha rilasciato uno strumento chiamato Interoperability Testing Tools (su un accenno a come si usa vedere qui) che è stato poi integrato in altri strumenti come soapUI un software in parte rilasciato open source con licenza GNU Library o Lesser General Public License (LGPL) in parte, la versione Pro, in via commerciale. soapUI è stato realizzato come applicazione stand-alone ma anche come plugin per Eclipse, Netbeans, IntelliJ e Maven.

Esistono altri strumenti che troverete nell’articolo che vi ho indicato e che da oggi ho cominciato a valutare.

Benvenuti nel meraviglioso mondo dell’interoperabilità :-)