Skip to main content

Details of the Generated WSDLs

For reference, this topic shows the parts of a sample WSDL document for an InterSystems IRIS® data platform web service, along with information about how keywords and parameters affect these parts.

The signatures of your web methods also affect the WSDL, but this topic does not discuss the details.

The WSDL is also affected by the XML projections of all XML-enabled classes used by the web service. See Projecting Objects to XML.

Note:

If the web service has a compiled policy configuration class, the <binding> section also includes elements of the form <wsp:Policy>. This documentation does not discuss how policies affect the WSDL, because the effects are determined by the WS-SecurityPolicy and other specifications.

For information on policy configurations, see Securing Web Services.

The system generates WSDL documents for convenience, but this is not required by the W3C specifications. For important notes on this topic, see Viewing the WSDL.

Overview of WSDL Documents

A web service has a WSDL document, a machine-readable interface definition. A WSDL document is written in XML, following the standard for the Web Services Description Language. It defines the contract for how the web service and its clients interact.

A WSDL has a root <definitions> element that contains additional elements that define the following:

  • Definition of any XML types or elements needed for inputs or outputs of the web service, defined in terms of base XML types. The <types> element includes one or more <schema> elements, which define the XML types, elements, or both as needed.

  • Definition of messages used by the web service. Each web method requires one or two messages: a request message to call the web method, and a response message to use in reply. Each message is defined in terms of XML types or elements.

  • Definition of port types used by the web service. Each port defines one or more operations. An operation corresponds to a web method and uses the corresponding message or messages.

    In general, a WSDL can contain multiple <portType> elements, but the WSDL for an InterSystems IRIS web service contains only one.

  • The bindings of the web service, which defines the message format and protocol details for operations and messages defined by a particular port type.

    In general, a WSDL can contain multiple <binding> elements, but the WSDL for an InterSystems IRIS web service contains only one.

  • Formal definition of the web service, in terms of the preceding components. This includes a URL for invoking the web service.

The service, any schemas, and the messages are all associated with XML namespaces; these can all be in a single namespace or can be in different namespaces. Note that InterSystems IRIS support for SOAP does not support all possible variations. See Standards Supported by InterSystems IRIS.

Sample Web Service

This topic shows parts of the WSDL of the following sample web service:

Class WSDLSamples.BasicWS Extends %SOAP.WebService
{

Parameter SERVICENAME = "MyServiceName";

Parameter NAMESPACE = "https://www.mynamespace.org";

Parameter USECLASSNAMESPACES = 1;

///  adds two complex numbers
Method Add(a As ComplexNumber, b As ComplexNumber) As ComplexNumber [ WebMethod ]
{
    Set sum = ##class(ComplexNumber).%New()
    Set sum.Real = a.Real + b.Real
    Set sum.Imaginary = a.Imaginary + b.Imaginary

    Quit sum
}
}

This web service refers to the following class:

///  A complex number
Class WSDLSamples.ComplexNumber Extends (%RegisteredObject, %XML.Adaptor)
{

/// real part of the complex number
Property Real As %Double;

/// imaginary part of the complex number
Property Imaginary As %Double;

}

Except where noted, the topic shows parts of the WSDL for this web service. (In some cases, the topic uses variations of this web service.)

Namespace Declarations

Before we examine the rest of the WSDL in detail, it is useful to see the namespace declarations used by the rest of the WSDL. The <definitions> element contains one namespace declaration for each namespace used in the WSDL. For the sample web service shown earlier in this topic, these declarations are as follows:

<definitions xmlns="https://schemas.xmlsoap.org/wsdl/" 
xmlns:SOAP-ENC="https://schemas.xmlsoap.org/soap/encoding/" 
xmlns:mime="https://schemas.xmlsoap.org/wsdl/mime/" 
xmlns:s="https://www.w3.org/2001/XMLSchema" 
xmlns:s0="https://www.mynamespace.org" 
xmlns:soap="https://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:wsdl="https://schemas.xmlsoap.org/wsdl/" 
xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" 
targetNamespace="https://www.mynamespace.org">

The following parameters affect the namespace declarations:

  • The NAMESPACE parameter in the web service.

    This parameter is used for the targetNamespace attribute, which indicates the target namespace of the web service.

    If the NAMESPACE parameter is not specified, targetNamespace is "https://tempuri.org"

  • The SOAPVERSION parameter in the web service.

    This affects the SOAP namespaces that are automatically included.

    By default, SOAPVERSION is 1.1.

    For SOAPVERSION equal to 1.2, the WSDL would instead include the following:

    <definitions ...
    xmlns:soap12="https://schemas.xmlsoap.org/wsdl/soap12/" 
    ...
    

    For SOAPVERSION equal to "", the WSDL would instead include the following:

    <definitions 
    xmlns:soap="https://schemas.xmlsoap.org/wsdl/soap/" 
    xmlns:soap12="https://schemas.xmlsoap.org/wsdl/soap12/" 
    ...
    
  • Other namespace keywords and parameters in the web service and in any XML-enabled classes used by the web service.

    These items are discussed in the following sections.

    These namespaces are declared as needed, for consistency with the rest of the WSDL.

Also, other namespaces (such as https://schemas.xmlsoap.org/wsdl/soap/) are included automatically as appropriate.

The namespace prefixes are all chosen automatically and cannot be customized.

<service>

When you examine a WSDL, it is useful to read it from the end to the beginning.

The final element within a WSDL is the <service> element, which defines the web service. For the sample web service shown earlier in this topic, this element is as follows:

<service name="MyServiceName">
    <port name="MyServiceNameSoap" binding="s0:MyServiceNameSoap">
        <soap:address location="https://devsys/csp/mysamples/WSDLSamples.BasicWS.cls"/>
    </port>
</service>

This element is specified as follows:

  • The SERVICENAME parameter of the web service is used as the name attribute of the <service> element. See Specifying the Service Name and Namespaces of the Web Service.

    This parameter also affects the name and binding attributes of the <port> element; no separate control is provided.

  • The binding attribute refers to a binding in the s0 namespace, which is listed in the namespace declarations. This namespace is specified by the NAMESPACE parameter of the web service.

  • The URL of the web service class controls the location attribute of the <soap:address> element.

<binding>

Before the <service> element, the WSDL contains <binding> elements, each of which defines message format and protocol details for operations and messages defined by a particular <portType> element.

In general, a WSDL can contain multiple <binding> elements, but the WSDL for an InterSystems IRIS web service contains only one.

For the sample web service shown earlier in this topic, this element is as follows:

<binding name="MyServiceNameSoap" type="s0:MyServiceNameSoap">
    <soap:binding transport="https://schemas.xmlsoap.org/soap/http" 
                  style="document"/>
    <operation name="Add">
        <soap:operation soapAction="https://www.mynamespace.org/WSDLSamples.BasicWS.Add" 
                        style="document"/>
        <input>
            <soap:body use="literal"/>
        </input>
        <output>
            <soap:body use="literal"/>
        </output>
    </operation>
</binding>

This element is specified as follows:

  • The name attribute of the <binding> element is automatically kept consistent with the <service> element (and would not be meaningful to change).

    <binding name="MyServiceNameSoap"  ...
    
  • The type attribute of the <binding> element refers to a <portType> element in the s0 namespace, which is listed in the namespace declarations. This namespace is specified by the NAMESPACE parameter of the web service.

  • The name attribute of each <operation> element is based on the name of the web method (and would not be meaningful to change).

    <operation name="Add"> ...
    
  • If you specify the SoapAction keyword for the web method, that value is used for the soapAction attribute of the operation. For example:

    ...
    <operation name="Add">
        <soap:operation soapAction="mysoapaction" style="document"/>
    ...
    
    
  • If the return type of a method is defined as %SOAP.OneWayOpens in a new tab, the affects this element as described in WSDL Differences for One-Way Web Methods.

  • If the SOAPBINARY parameter is 1 for the web service, that affects this element as described in WSDL Differences for InterSystems IRIS Binary SOAP Format.

  • If the SOAPSESSION parameter is 1 for the web service, that affects this element as described in WSDL Differences for InterSystems IRIS SOAP Sessions.

    The SoapBindingStyle class keyword, SoapBindingStyle method keyword, and SoapBindingStyle query keyword affect the <binding> element as described in the Class Definition Reference. These keywords can have the values document and rpc.

  • The SoapBodyUse class keyword, SoapBodyUse method keyword, and SoapBodyUse query keyword affect the <binding> element as described in the Class Definition Reference. These keywords can have the values literal and encoded.

Note:

If the web service has a compiled policy configuration class, the <binding> section also includes elements of the form <wsp:Policy>. This documentation does not discuss how policies affect the WSDL, because the effects are determined by the WS-SecurityPolicy and other specifications.

For information on policy configurations, see Securing Web Services.

<portType>

Before the <binding> section, a WSDL contains <portType> elements, each of which defines an individual endpoint by specifying a single address for a <binding> element. A <portType> element is a named set of abstract operations and the abstract messages involved.

In general, a WSDL can contain multiple <portType> elements, but the WSDL for an InterSystems IRIS web service contains only one.

For the sample web service shown earlier in this topic, the <portType> element is as follows:

<portType name="MyServiceNameSoap">
    <operation name="Add">
        <input message="s0:AddSoapIn"/>
        <output message="s0:AddSoapOut"/>
    </operation>
</portType>

All aspects of this element are automatically kept consistent with other parts of the WSDL; there is no independent control of it.

<message>

Before the <portType> element, the <message> elements define the messages used in the operations. The WSDL typically contains two <message> elements for each web method. For the sample web service shown earlier in this topic, these elements are as follows:

<message name="AddSoapIn">
    <part name="parameters" element="s0:Add"/>
</message>
<message name="AddSoapOut">
    <part name="parameters" element="s0:AddResponse"/>
</message>

This element is specified as follows:

  • The name attribute of a <message> element is based on the name of the web method.

  • The binding style of a method is determined by the <binding> element shown previously. This determines whether a message can have multiple parts:

    • If the binding style is "document", the message has only one part by default. For example:

      <message name="AddSoapIn">
          <part name="parameters" .../>
      </message>
      

      If the ARGUMENTSTYLE parameter is "message", then the message can have multiple parts. For example:

      <message name="AddSoapIn">
         <part name="a" .../>
         <part name="b" .../>
      </message>
      
      
    • If the binding style is "rpc", the message can have multiple parts. For example:

      <message name="AddSoapIn">
          <part name="a" .../>
          <part name="b" .../>
      </message>
      
  • The use attribute of the <soap:body> element, as specified in the <binding> element shown previously, determines the contents of a message <part> element:

    • If the use attribute is "literal", the <part> element includes an element attribute. For example:

      <part name="parameters" element="s0:Add"/>
      

      For another example:

      <part name="b" element="s0:b"/>
      
    • If the use attribute is "encoded", the <part> element includes a type attribute rather than an element attribute. For example:

      <part name="a" type="s0:ComplexNumber"/>
      
  • The names of the elements or types to which the messages refer are determined as described in the next section.

  • The namespaces to which those elements and types belong are determined as described in the next section.

  • Also see WSDL Differences for One-Way Web Methods.

  • If the SOAPSESSION parameter is 1 for the web service, that affects this element as described in WSDL Differences for InterSystems IRIS SOAP Sessions.

<types>

Before the <message> elements, the WSDL includes a <types> element, which defines the schema or schemas used by the messages. The <types> element includes one or more <schema> elements, and these define the elements, types, or both used by the web service and its clients. For the sample web service shown earlier in this topic, this element is as follows:

<types>
    <s:schema elementFormDefault="qualified" targetNamespace="https://www.mynamespace.org">
        <s:element name="Add">
            <s:complexType>
                <s:sequence>
                    <s:element minOccurs="0" name="a" type="s0:ComplexNumber"/>
                    <s:element minOccurs="0" name="b" type="s0:ComplexNumber"/>
                </s:sequence>
            </s:complexType>
        </s:element>
        <s:complexType name="ComplexNumber">
            <s:sequence>
                <s:element minOccurs="0" name="Real" type="s:double"/>
                <s:element minOccurs="0" name="Imaginary" type="s:double"/>
            </s:sequence>
        </s:complexType>
        <s:element name="AddResponse">
            <s:complexType>
                <s:sequence>
                    <s:element name="AddResult" type="s0:ComplexNumber"/>
                </s:sequence>
            </s:complexType>
        </s:element>
    </s:schema>
</types>

The following subsections discuss the primary variations:

Note:

The <types> section is also influenced by the XML projections defined for all XML-enabled classes used by the web service. The XML projections determine issues such as namespace use, null handling, and handling of special characters. See Projecting Objects to XML.

The SoapBindingStyle and SoapBodyUse keywords affect other parts of the WSDL, which in turn determine the structure of the <types> section.

Name Attributes

Each <schema> element can consist of elements, types, or both, depending on the message style. Each of element or type has a name attribute, which is specified as follows:

  • If the item corresponds to the web method, its name attribute equals the name of that web method (for example, Add) and cannot be changed.

  • If the item corresponds to an XML-enabled class used as an argument or return value, its name attribute is determined by the XML projection of that class. For details, see Projecting Objects to XML.

  • If the item corresponds to the response message, by default its name attribute has the form method_nameResponse (for example, AddResponse).

    For web methods that use document-style binding, you can override this by specifying the SoapMessageName keyword of the web method.

  • For lower-level items within <schema>, the name attributes are set automatically and cannot be independently controlled.

For example, suppose that we edited the sample web method as follows:

Method Add(a As ComplexNumber, b As ComplexNumber) 
As ComplexNumber [ WebMethod, SoapMessageName = MyResponseMessage]
{
    Set sum = ##class(ComplexNumber).%New()
    Set sum.Real = a.Real + b.Real
    Set sum.Imaginary = a.Imaginary + b.Imaginary

    Quit sum
}

In this case, the <types> section would be as follows:

<types>
    <s:schema elementFormDefault="qualified" targetNamespace="https://www.mynamespace.org">
        <s:element name="Add">
            <s:complexType>
                <s:sequence>
                    <s:element minOccurs="0" name="a" type="s0:ComplexNumber"/>
                    <s:element minOccurs="0" name="b" type="s0:ComplexNumber"/>
                </s:sequence>
            </s:complexType>
        </s:element>
        <s:complexType name="ComplexNumber">
            <s:sequence>
                <s:element minOccurs="0" name="Real" type="s:double"/>
                <s:element minOccurs="0" name="Imaginary" type="s:double"/>
            </s:sequence>
        </s:complexType>
        <s:element name="MyResponseMessage">
            <s:complexType>
                <s:sequence>
                    <s:element name="AddResult" type="s0:ComplexNumber"/>
                </s:sequence>
            </s:complexType>
        </s:element>
    </s:schema>
</types>

For more information, see Controlling the Message Name of the SOAP Response. Also see Projecting Objects to XML.

Namespaces in <types>

The following parameters of the web service affect the use of namespaces within the <types> section:

  • If it is specified, TYPENAMESPACE controls the targetNamespace attribute of the <schema> element.

  • If TYPENAMESPACE is not specified, the targetNamespace attribute is specified by the NAMESPACE parameter.

  • RESPONSETYPENAMESPACE controls the targetNamespace attribute of the type used by the response.

  • USECLASSNAMESPACES controls whether <types> also uses the namespaces specified in the supporting type classes.

The NAMESPACE parameter of each XML-enabled class also affects the <types> element of the WSDL.

Consider the following variation of the web service shown earlier:

Class WSDLSamples.Namespaces Extends %SOAP.WebService
{

Parameter SERVICENAME = "MyServiceName";

Parameter NAMESPACE = "https://www.mynamespace.org";

Parameter RESPONSENAMESPACE = "https://www.myresponsenamespace.org";

Parameter TYPENAMESPACE = "https://www.mytypes.org";

Parameter RESPONSETYPENAMESPACE = "https://www.myresponsetypes.org";

Parameter USECLASSNAMESPACES = 1;

///  adds two complex numbers
Method Add(a As ComplexNumberNS, b As ComplexNumberNS) As ComplexNumberNS [ WebMethod ]
{
    Set sum = ##class(ComplexNumberNS).%New()
    Set sum.Real = a.Real + b.Real
    Set sum.Imaginary = a.Imaginary + b.Imaginary

    Quit sum
}

}

The class WSDLSamples.ComplexNumberNS is as follows:

///  A complex number
Class WSDLSamples.ComplexNumberNS Extends (%RegisteredObject, %XML.Adaptor)
{

Parameter NAMESPACE = "https://www.complexnumbers.org";

Property Real As %Double;

Property Imaginary As %Double;

}

For the WSDL of this web service, the <types> part is as follows:

<types>
    <s:schema elementFormDefault="qualified" targetNamespace="https://www.mytypes.org">
        <s:import namespace="https://www.complexnumbers.org"/>
        <s:element name="Add">
            <s:complexType>
                <s:sequence>
                    <s:element minOccurs="0" name="a" type="ns2:ComplexNumberNS"/>
                    <s:element minOccurs="0" name="b" type="ns2:ComplexNumberNS"/>
                </s:sequence>
            </s:complexType>
        </s:element>
    </s:schema>
    <s:schema elementFormDefault="qualified" targetNamespace="https://www.complexnumbers.org">
        <s:complexType name="ComplexNumberNS">
            <s:sequence>
                <s:element minOccurs="0" name="Real" type="s:double"/>
                <s:element minOccurs="0" name="Imaginary" type="s:double"/>
            </s:sequence>
        </s:complexType>
    </s:schema>
    <s:schema elementFormDefault="qualified" targetNamespace="https://www.myresponsetypes.org">
        <s:import namespace="https://www.complexnumbers.org"/>
        <s:element name="AddResponse">
            <s:complexType>
                <s:sequence>
                    <s:element name="AddResult" type="ns2:ComplexNumberNS"/>
                </s:sequence>
            </s:complexType>
        </s:element>
    </s:schema>
</types>

Other Possible Variations

The following additional parameters also affect the <types> element:

  • If the INCLUDEDOCUMENTATION parameter is 1 in the web service. the <types> section includes <annotation> elements that contain any comments that you include in the type classes. (These comments must be preceded by three slashes.)

    By default, INCLUDEDOCUMENTATION is 0.

    For example, suppose that we edit the sample web service to add the following:

    Parameter INCLUDEDOCUMENTATION = 1;
    

    In this case, the <types> section includes the following:

    ...
    <s:complexType name="ComplexNumber">
        <s:annotation>
            <s:documentation>A complex number</s:documentation>
        </s:annotation>
        <s:sequence>
            <s:element minOccurs="0" name="Real" type="s:double">
                <s:annotation>
                    <s:documentation>real part of the complex number</s:documentation>
                </s:annotation>
            </s:element>
            <s:element minOccurs="0" name="Imaginary" type="s:double">
                <s:annotation>
                    <s:documentation>imaginary part of the complex number</s:documentation>
                </s:annotation>
            </s:element>
        </s:sequence>
    </s:complexType>
    ...
    
  • If the SOAPBINARY parameter is 1 for the web service, that affects the <types> element as described in WSDL Differences for InterSystems IRIS Binary SOAP Format.

  • If the SOAPSESSION parameter is 1 for the web service, that affects this element as described in WSDL Differences for InterSystems IRIS SOAP Sessions.

  • If specified, the SoapTypeNameSpace keyword affects this part of the WSDL. See the Class Definition Reference.

  • If the REQUIRED parameter is 1 for an argument, the WSDL includes minOccurs=1 for that argument. For information on this parameter, see Basic Requirements.

  • If the SoapRequestMessage keyword is specified for a method, the name of the corresponding element is the value of the SoapRequestMessage keyword, rather than the name of the method.

  • For information on the effect of the ALLOWREDUNDANTARRAYNAME parameter, see Projection of Collection Properties to XML Schemas in Controlling the Projection to XML Schemas.

WSDL Variations Due to Method Signature Variations

This section shows some WSDL variations caused by variations in the method signature.

Returning Values by Reference or as Output Parameters

To return values by reference or as output parameters, use the ByRef or Output keyword, as appropriate, within the signature of the web method. This change affects the schema and the SOAP response message.

For example, consider the following web method signatures, from methods in two different web services:

//from web service 1
Method HelloWorld() As %String [ WebMethod ]

//from web service 2
Method HelloWorld(ByRef myarg As %String) [ WebMethod ]

For the first web service, the <types> section is as follows:

<types>
    <s:schema elementFormDefault="qualified" targetNamespace="https://www.helloworld.org">
        <s:element name="HelloWorld1">
            <s:complexType>
                <s:sequence/>
            </s:complexType>
        </s:element>
        <s:element name="HelloWorld1Response">
            <s:complexType>
                <s:sequence>
                    <s:element name="HelloWorld1Result" type="s:string"/>
                </s:sequence>
            </s:complexType>
        </s:element>
    </s:schema>
</types>

For the second web service, which returns the value by reference, the <types> section has a variation for the type that corresponds to the response message:

<types>
...
        <s:element name="HelloWorld2Response">
            <s:complexType>
                <s:sequence>
                    <s:element minOccurs="0" name="myarg" type="s:string"/>
...

This indicates that the element contained in the <HelloWorld2Response> message is <myarg>, which corresponds to the name of the argument in the message signature. In contrast, this element is usually <methodnameResult>.

If you use the ByRef keyword instead of Output, that has the same effect on the WSDL.

For information on these keywords, see Methods.

Other WSDL Variations for InterSystems IRIS Web Services

This section discusses other possible variations for WSDLs for InterSystems IRIS web services.

WSDL Differences for InterSystems IRIS SOAP Sessions

If the SOAPSESSION parameter is 1 for the web service, that affects the WSDL as follows:

  • Within the <binding> element, the <input> and <output> elements of each <operation> include the following additional subelement:

    <soap:header message="s0:IRISSessionHeader" part="CSPCHD" use="literal"/>
    

    For example:

    <operation name="Add">
        <soap:operation soapAction="https://www.mynamespace.org/WSDLSamples.BasicWS.Add" style="document"/>
        <input>
            <soap:body use="literal"/>
            <soap:header message="s0:IRISSessionHeader" part="CSPCHD" use="literal"/>
        </input>
        <output>
            <soap:body use="literal"/>
            <soap:header message="s0:IRISSessionHeader" part="CSPCHD" use="literal"/>
        </output>
    </operation>
    
  • The WSDL includes the following additional <message> element:

    <message name="IRISSessionHeader">
        <part name="CSPCHD" element="chead:CSPCHD"/>
    </message>
    
  • The <types> element includes the following additional item:

    <s:schema elementFormDefault="qualified" targetNamespace="https://www.intersystems.com/SOAPheaders">
        <s:element name="CSPCHD">
            <s:complexType>
                <s:sequence>
                    <s:element name="id" type="s:string"/>
                </s:sequence>
            </s:complexType>
        </s:element>
    </s:schema>
    
  • The namespace declarations include the following additional item:

    xmlns:chead="https://www.intersystems.com/SOAPheaders"
    

WSDL Differences for InterSystems IRIS Binary SOAP Format

For an InterSystems IRIS web service that has the SOAPBINARY parameter specified as 1, the WSDL is enhanced as follows:

  • The <binding> element includes an extension child element that indicates SOAP binary support:

    <isc:binding charset="isc_charset"> 
    

    Where isc_charset is the InterSystems IRIS character set (for example: Unicode, Latin1) of the InterSystems IRIS namespace for the web service.

    For example:

    <isc:binding charset="Unicode"> 
    
  • Within the <types> section of the WSDL, each <complexType> element includes an extension attribute as follows:

    <complexType isc:classname="service_name:class_name" ...>
    

    Where service_name is the web service name and class_name is the InterSystems IRIS class name that corresponds to this complex type. For example:

    <s:complexType isc:classname="AddComplex:GSOAP.ComplexNumber" name="ComplexNumber">
      <s:sequence>
        <s:element minOccurs="0" name="Real" type="s:double"/>
        <s:element minOccurs="0" name="Imaginary" type="s:double"/>
      </s:sequence>
    </s:complexType>
    
    
  • Also within the <types> section, the <element> and <simpleContent> elements include an extension attribute of the following form (as needed):

    <element isc:property="property_name" ....>  
    <simpleContent isc:property="property_name" ....>
    

    Where property_name is the name of the InterSystems IRIS property that maps to that element. (Note that the WSDL includes a <simpleContent> element for a property with XMLPROJECTION equal to "content".)

    For example:

    <s:element minOccurs="0" name="RealType" isc:property="Real" type="s:double"/>
    
    

    This attribute is set only when the property uses the XMLNAME property parameter, which enables the XML name to be different from the property name. The preceding example is taken from a WSDL for a web service that uses a class that contains the following property:

    Property Real As %Double (XMLNAME = "RealType");
    
    

    The isc:property attribute allows the property names to be the same in the generated client classes as in the service classes. Current exceptions are any choice or substitutionGroup usage or wrapped elements where the type class has an XMLNAME parameter.

  • The namespace declarations include the following additional item:

    xmlns:isc="https://www.intersystems.com/soap/"
    

These WSDL extensions are valid according to the XML Schema, WSDL, and WS-I Basic Profile specifications and are expected to be ignored by all conforming web client toolkits.

Note:

If an InterSystems IRIS web service or web client uses the InterSystems IRIS binary SOAP format, you cannot use WS-Security or WS-Policy features with this web service or client. See Securing Web Services.

WSDL Differences for One-Way Web Methods

If the return type of a method is defined as %SOAP.OneWayOpens in a new tab, the WSDL is different from the default in the following ways:

  • Within the <binding> element, the <operation> element for that method does not include an <output> element.

  • Within the <portType> element, the <operation> element for that method does not include an <output> element.

  • The WSDL does not include a <message> element for the response message.

FeedbackOpens in a new tab