Comprender cómo se genera el WSDL
SCA para PHP genera WSDL para componentes que contienen una anotación @binding.soap después de la anotación @service. Para generar WSDL, el tiempo de ejecución de SCA reflexiona sobre el componente y examina las anotaciones @param y @return para cada método público, así como también cualquier anotación @types dentro del componente. La información desde las anotaciones @param y @return se usa para construir la sección <types> del WSDL. Cualquier anotación @types que especifique un fichero de esquema distinto resultará en un elemento <import> para tal esquema dentro del WSDL.
El atributo 'location' del elemento <service>
Al final del WSDL se encuentra el elmento <service>, que usa el atributo de ubicación 'location' para identificar la URL del servicio. Por ejemplo, esto podría ser como sigue:
Ejemplo #1 El atrubuto 'location'
<service name="ConvertedStockQuote" ... location="http://localhost/ConvertedStockQuote/ConvertedStockQuote.php"/>
Observe que esta ubicación es relaitva a la raíz de documentos del servidor web, y no puede ser resuelta de antemano. Solamente puede hacerse una vez que el componente esté en su propio lugar bajo un servidor web en ejecución, cuando el nombre de host y el puerto puedan ser conocidos y colocados en el WSDL. Se usan los detalles de la URL que solicita el WSDL, por lo que, por ejemplo, si el WSDL es generado en respuesta a una petición a http://www.example.com:1111/ConvertedStockQuote/ConvertedStockQuote.php?wsdl, se insertará la ubicación http://www.example.com:1111/ConvertedStockQuote/ConvertedStockQuote.php en el atributo 'location' del WSDL.
WSDL document/literal envuelto y parámetros posicionales
SCA para PHP genera WSDL al estilo document/literal envuelto. Este estilo encierra los parámetros y devuelve los tipo de un método en "envolturas" que son nombradas después des método correspondiente. El elemento <types> al incio del WSDL define cada envoltura. Si se considera el método getQuote() del ejemplo ConvertedStockQuote:
Ejemplo #2 Método con dos arguentos
<?php
/**
* Obtener la contización de la acción para una clave de pizarra dada en una moneda dada.
*
* @param string $ticker La clave de pizarra.
* @param string $currency A qué moneda convertir el valor.
* @return float El valor de la acción es la moneda objetivo.
*/
function getQuote($ticker, $currency)
{
$quote = $this->stock_quote->getQuote($ticker);
$rate = $this->exchange_rate->getRate($currency);
return $rate * $quote;
}
?>
El WSDL generado para definir este método nombrará a los métodos y a los parámetros, y proporcionará un tipo de esquema XML para los parámetros. La sección de tipos del WSDL se parecería a esto:
Ejemplo #3 La sección de tipos ilustrando parámetros con nombre
<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>
El tiempo de ejecución de SCA procesa de manera especial la conversión de las listas de parámetros posicionales de la interfaz a XML que contiene parámetros con nombre en la solicitud soap, y luego vueltas a convertir a listas de parámetros posicionales. Para ver por qué importa esto, considere cómo un script de PHP que usó una interfaz diferente para hace una llamada SOAP necesitaría construir la lista de parámetros. Un script de PHP que use un SoapClient de PHP, por ejemplo, necesitaría pasar al SoapClient un único parámetro proporcionando los valores para "ticker" y "currency", quizás como un array asociativo. Para insistir que los componentes SCA construyen listas de parámetros para hacer llamadas a servicios web de esta manera, sería hacer que las llamadas locales y remotas fueran diferentes, por lo que sería necesario un enfoque diferente.
Cuando SCA genera WSDL para un componente SCA, incluye un comentario en el WSDL que marca dicho WSDL como la interfaz para un componente SCA. En este caso, cuando un componente SCA invoca a otro a través de un servicio web, el tiempo de ejecución de SCA al finalizar la llamada toma la lista de parámetros posicionales desde la llamada y asigna los valores uno a uno a los elementos con nombre del mensaje soap. Por ejemplo, una llamada al método getQuote() definido arriba que pasa los valores 'IBM' y 'USD' podría ser así:
<?php
$quote = $remote_service->getQuote('IBM','USD');
?>
lo que resultará en un mensaje soap que coteiene los siguiente:
<getQuote> <ticker>IBM</ticker> <currency>USD</currency> </getQuote>
Al final de proporcionar el servicio, el tiempo de ejecución de SCA toma los parámetros una a uno desde el mensaje soap y forma una lista de parámetros posicionales a partir de ellos, reformando la lista de argumentos ('IBM','USD').
Al finalizar ambos, el tiempo de ejecución de SCA cuenta con que el orden en que aparecen los parámetros en el mensaje soap sea el mismo que el de la lista de parámetros de los métodos objetivo. Esto se determina básicamente por el orden de las anotaciones @param: determina el orden en el que aparacen los parámetros en el WSDL y por lo tanto el orden en que aparacen el el mensaje soap. Así, es esencial que el orden de las anotaciones @param coincida con el de los parámetros de la lista de parámetros del método.
add a note
