When a method is created for an XML Web service, Visual Studio/ .NET will automatically generate code capable of handling requests from multiple types of HTTP protocols. The WSDL document generated for the service defines the ports on which these various protocols may contact the service. In WSDL, a port is defined as follows:
<portType name="nmtoken"> * <-- extensibility element --> </portType>
In the above definition, name represents a unique name among the ports being defined. The extensibility element represents a list of operation elements, one for every method exposed by the service. The port defined in Listing 3.3 defines a service, DataTypes, exposing its functionality via SOAP. The service contains one operation, or method, called StringReturn.
Listing 3.3 A SOAP portTypes in WSDL
1: <portType name="DataTypesSoap"> 2: <operation name="StringReturn"> 3: <documentation>This function returns a simple string. I am writing 4: this text as an example of using the description 5: Metadata.</documentation> 6: <input message="s0:StringReturnSoapIn" /> 7: <output message="s0:StringReturnSoapOut" /> 8: </operation> 9: </portType>
The code in Listing 3.4 shows the same service exposing its functionality via HttpGet.
Listing 3.4 An HttpGet portType
1: <portType name="DataTypesHttpGet"> 2: <operation name="StringReturn"> 3: <documentation>This function returns a simple string. I am writing 4: this text as an example of using the description 5: Metadata.</documentation> 6: <input message="s0:StringReturnHttpGetIn" /> 7: <output message="s0:StringReturnHttpGetOut" /> 8: </operation> 9: </portType>
As you have already seen, operations represent the various methods being exposed by the service. A typical operation contains two elements, input and output, but may also contain documentation and fault.
The input and output elements of an operation basically link the services method, StringReturn in the case of Listing 3.4, to SOAP messages that will provide the transport for input parameters and output results. Line 6 of Listing 3.4 lets you know that the StringReturn method will be called using the message StringReturnHttpGetIn and will return its results using StringReturnHttpGetOut. A little later in this hour you will see how to define the messages themselves.
Like the input and output elements, fault defines the message that will be used to transport error messages should errors be encountered. In addition, the documentation element, lines 3 through 5 of Listing 3.4, provides a method for attaching comments to a service's methods.