Comprendre la génération du fichier WSDL

SCA pour PHP génère un fichier WSDL pour les composants qui contiennent une annotation @binding.soap, après l'annotation @service. Pour générer le service, SCA analyse la classe, et les annotations @param et @return pour chaque méthode publique, ainsi que les annotations de @types dans le composant. Les informations des annotations @param et @return sont utilisées pour construire la section <types> du fichier WDSL. Toutes les annotations @types qui spécifient un schéma distinct engendreront un élément <import> pour ce schéma dans le WSDL.

Attribut de localisation pour l'élément <service>

A la fin du fichier WSDL, l'élément <service> utilise un attribut de localisation 'location', pour identifier l'URL du service. Par exemple :

Exemple #1 Attribut location

<service name="ConvertedStockQuote"
...
location="http://localhost/ConvertedStockQuote/ConvertedStockQuote.php"/>

Notez que cette localisation est relative à la racine du document du serveur Web, et ne peut pas être connue à l'avance. Elle ne peut être résolue que lorsque le composant est mis en place dans un serveur Web en fonctionnement, lorsque le nom d'hôte et le port peuvent être connus et placés dans le fichier WDSL. Des informations de l'URL appelante sont aussi utilisés, ce qui fait que si le WSDL est produit en réponse à la requête http://www.example.com:1111/ConvertedStockQuote/ConvertedStockQuote.php?wsdl, une localisation de http://www.example.com:1111/ConvertedStockQuote/ConvertedStockQuote.php sera insérée dans l'attribut.

Inclusion des documents dans le WSDL et paramètres positionnés

SCA pour PHP produit des fichiers WSDL en incluant les documents et littéraux. Ce style encadre les paramètres et les valeurs de retour d'une méthode dans un 'gestionnaire' qui est nommé à partir de la méthode. L'élément <types> au début du fichier WSDL définit chacun de ces gestionnaires. Si nous étudions la méthode getQuote() de notre exemple ConvertedStockQuote :

Exemple #2 une méthode avec deux arguments

<?php
   
/**
     * Lit une cotation pour une action à partir de son symbole et dans une devise
     *
     * @param string $ticker Le symbole
     * @param string $currency La devise cible
     * @return float La valeur de l'action dans la devise demandée
     */
    
function getQuote($ticker$currency)
    {
        
$quote  $this->stock_quote->getQuote($ticker);
        
$rate   $this->exchange_rate->getRate($currency);
        return  
$rate $quote;
    }
?>

Pour définir cette méthode, le fichier WSDL va donner des noms à la méthode et aux paramètres, puis donner au schéma XML le type des paramètres. La section de type du fichier WSDL produit ressemble à ceci :

Exemple #3 Section types avec paramètres nommés

<types>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
      targetNamespace="http://ConvertedStockQuote">
      <xs:element name="getQuote">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="ticker" type="xs:string"/>
            <xs:element name="currency" type="xs:string"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
      <xs:element name="getQuoteResponse">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="getQuoteReturn" type="xs:float"/>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
    </xs:schema>
  </types>

L'exécutable SCA gère la conversion de la liste des paramètres positionnés en une requête SOAP, puis de nouveau en liste de paramètres, au retour de la requête. Pour comprendre où cela est important, vous pouvez étudier comment PHP qui utiliserait une autre interface pour faire un appel SOAP devrait construire la liste de paramètres. Un script PHP utilisant la classe SoapClient, a besoin de passer les paramètres "ticker" et "currency", peut-être sous forme de tableau associatif. Pour cela, il faudrait que les appels à des services Web ou des fonctions locales se fassent avec des interfaces de programmation différente, et ce n'est pas voulu.

Quand SCA génère un fichier WSDL pour un composant SCA, il inclut des commentaires dans le WDSL qui indique le ce composant est un composant SCA. Dans ce cas, quand un composant SCA est appelé par un autre composant via un service Web, l'exécutable SCA prend la liste de paramètres et assigne les valeurs une à une dans le message SOAP. Par exemple, un appelle à la méthode getQuote() définie ci-dessus qui passe les valeurs 'IBM' et 'USD' ressemble à ceci :

<?php
  $quote 
$remote_service->getQuote('IBM','USD');
?>

Elle produira un message SOAP qui contient ce code XML :

<getQuote>
  <ticker>IBM</ticker>
  <currency>USD</currency>
</getQuote>

Dans le composant de réception, l'exécutable SCA prend les paramètres dans le même ordre, et forme une liste de paramètres positionnés, en reformant la liste des arguments ('IBM','USD').

Attention

Dans les deux cas, l'exécutable SCA s'appuie sur l'ordre dans lequel les arguments sont placés dans le message SOAP : cet ordre doit correspondre à l'ordre d'appel des paramètres dans la fonction. Cet ordre est finalement défini par l'ordre des annotations @param : il déterminent l'ordre dans lequel les paramètres apparaissent dans le fichier WSDL, et dans le message SOAP. Par conséquent, il est essentiel que cet ordre d'annotations @param correspondent aux paramètres de la méthode publique.