• Examples
  • Understanding how the WSDL is generated

  • Understanding how the WSDL is generated
  • Understanding how the WSDL is generated

    Understanding how the WSDL is generated

    SCA for PHP generates WSDL for components which
    contain an @binding.soap annotation after the @service annotation.
    To generate WSDL, the SCA runtime reflects on the component and
    examines the @param and @return annotations for each public method,
    as well as any @types annotations within the component. The
    information from the @param and @return annotations is used to
    build the <types> section of the WSDL. Any @types annotations
    which specify a separate schema file will result in an
    <import> element for that schema within the WSDL.

    Location attribute of the <service>

    At the bottom of the WSDL is the <service>
    element which uses the location attribute to identify the URL of
    the service. For example this might look as follows:

    Example #1 location attribute

    <service name="ConvertedStockQuote"

    Note that this location is relative to the document
    root of the web server, and cannot be worked out in advance. It can
    only be worked out once the component is in its proper place under
    a running web server, when the hostname and port can be known and
    placed in the WSDL. Detail from the URL that requests the WSDL is
    used, so for example if the WSDL is generated in response to a
    request to,
    a location of
    is what will be inserted into the location attribute in the

    Document/literal wrapped WSDL and positional

    SCA for PHP generates WSDL in the document/literal
    wrapped style. This style encloses the parameters and return types
    of a method in ‘wrappers’ which are named after the corresponding
    method. The <types> element at the top of the WSDL defines
    each of these wrappers. If we consider the getQuote() method of the
    ConvertedStockQuote example:

    Example #2 method with two arguments

         * Get a stock quote for a given ticker symbol in a given currency.
         * @param string $ticker The ticker symbol.
         * @param string $currency What currency to convert the value to.
         * @return float The stock value is the target currency.
    function getQuote($ticker$currency)
    $quote  $this->stock_quote->getQuote($ticker);
    $rate   $this->exchange_rate->getRate($currency);
    $rate $quote;

    The WSDL generated to define this method will name
    both the method and the parameters, and give an XML schema type for
    the parameters. The types section of the WSDL looks like this:

    Example #3 types section illustrating named

        <xs:schema xmlns:xs=""
          <xs:element name="getQuote">
                <xs:element name="ticker" type="xs:string"/>
                <xs:element name="currency" type="xs:string"/>
          <xs:element name="getQuoteResponse">
                <xs:element name="getQuoteReturn" type="xs:float"/>

    The SCA run-time has special processing to handle
    how positional parameter lists in the interface are converted to
    XML containing named parameters in the soap request, and then back
    to positional parameter lists again. To see why this matters,
    consider how a PHP script which used a different interface to make
    a SOAP call would need to construct the parameter list. A PHP
    script using the PHP SoapClient, for example, would need to pass
    the SoapClient a single parameter giving the values for “ticker”
    and “currency”, perhaps as an associative array. To insist that SCA
    components construct parameter lists to make Web service calls in
    this way would be to make local and remote calls look different, so
    a different approach is needed.

    When SCA generates WSDL for an SCA component it
    includes a comment in the WSDL which marks that WSDL as being the
    interface for an SCA component. In this case, when one SCA
    component calls another through a Web service, the SCA runtime on
    the calling end takes the positional parameter list from the call
    and assigns the values one by one to the named elements in the soap
    message. For example a call to the getQuote() method defined above
    that passes the values ‘IBM’ and ‘USD’ and looks like this:


    will result in a soap message containing the


    On the service-providing end, the SCA run-time
    takes the parameters one by one from the soap message and forms a
    positional parameter list from them, re-forming the argument list


    At both ends the SCA runtime relies on the order in
    which the parameters appear in the soap message being the same as
    that in the target method’s parameter list. This is ultimately
    determined by the order of the @param annotations: this determines
    the order in which the parameters appear in the WSDL and thereby
    the order in which they appear in the soap message. Therefore it is
    essential that the order of the @param annotations matches that of
    the parameters in the method’s parameter list.