Effect of Soap message in Adding a new member in Data Contract - wcf

Adding new members in the Data contract are harmless for all versions of clients. Its a known fact.
I wanted to test this.
I created a Book Data Contract. Its first version had the following members.
public class Book
{
[DataMember(IsRequired = false)]
public long BookID;
[DataMember(IsRequired = true)]
public string Title;
[DataMember(IsRequired = false)]
public string Author;
}
The client was created for this version of Contract.
Then I added another member "Edition" to the Book and the new version of the Book is
public class Book
{
[DataMember(IsRequired = false)]
public long BookID;
[DataMember(IsRequired = true)]
public string Title;
[DataMember(IsRequired = false)]
public string Author;
[DataMember(IsRequired = false)]
public string Edition;
}
The newer version of the contract works flawlessly with the older vesion of client.
I wanted to Physically see the on wire soap message. I have enabled the client and server side message logging.
I understand that new member "Edition" would be taken as Nil and would be while serializing.
But on the client side message, I saw something strange, the following.
The soap envelop looks like this
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://www.8fingergenie.com/BookShop/CheckAvailability</Action>
<ActivityId CorrelationId="631f540a-915b-4203-8fd8-e251da2fab85" xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">68a15797-124d-47f7-a85a-cf5c661e8011</ActivityId>
</s:Header>
<s:Body>
<CheckAvailability xmlns="http://www.8fingergenie.com/">
<book xmlns:d4p1="http://8fingergenie.com" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<d4p1:Author>Spensor Johnson</d4p1:Author>
<d4p1:BookID>1</d4p1:BookID>
<d4p1:Edition i:nil="true"></d4p1:Edition>
<d4p1:Title>Who Moved My Cheese</d4p1:Title>
</book>
</CheckAvailability>
</s:Body>
My question is how did the client with older version of Data contract know about edition while making communication? or am I missing something here.
Following is the structure of the client side Book's schema.
<xs:schema xmlns:tns="http://8fingergenie.com" elementFormDefault="qualified" targetNamespace="http://8fingergenie.com" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="Book">
<xs:sequence>
<xs:element minOccurs="0" name="Author" nillable="true" type="xs:string" />
<xs:element minOccurs="0" name="BookID" type="xs:long" />
<xs:element name="Title" nillable="true" type="xs:string" />
</xs:sequence>
</xs:complexType>
<xs:element name="Book" nillable="true" type="tns:Book" />

It is not harmless for all clients. You could write a client that would fail if any members were added, deleted, or changed.
The fact that a client could be deliberately written to fail in that situation implies that it's possible to write a client which would inadvertently fail in the same situation.

On Further research I have found the following.
I was using Service reference in the client. The service reference by default creates the Data contract as type derived from IExtensibleDataObject. I didn't notice this would be the default.
So since the type is derived from IExtensibleDataObject, the new members from the other end is wraped inside the ExtensionDataObject. This is how the client was aware of the datacontract's new member.
Thank you for everyone who tried to help me.

Related

Why is my WCF web service presenting this object in a different namespace with different field names?

The Context: I'm trying to integrate with DocuSign's Connect notification service. I've set up a WCF service with a method called DocuSignConnectUpdate which takes a DocuSignEnvelopeInformation as its only parameter, as specified by DocuSign. This DocuSignEnvelopeInformation object comes from a reference to their API, so that they can pass this object to my web service, and I know exactly what to expect. DocuSign asks for my service address and the namespace, which I have configured on their site.
The Problem: The XML that DocuSign sends is what I would expect. The DocuSignEnvelopeInformation and its children are in the namespace "http://www.docusign.net/API/3.0" and the element names match the object names:
<DocuSignEnvelopeInformation xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.docusign.net/API/3.0">
<EnvelopeStatus>...</EnvelopeStatus>
</DocuSignEnvelopeInformation>
But my web service is expecting something different, in the wrong namespace, and with modified element names. This is how the DocuSignConnectUpdate method is defined in my WSDL:
<xs:element name="DocuSignConnectUpdate">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="DocuSignEnvelopeInformation" nillable="true" type="tns:DocuSignEnvelopeInformation"/>
</xs:sequence>
</xs:complexType>
</xs:element>
And this is how this is how the DocuSignEnvelopeInformation type is defined in my WSDL:
<xs:complexType name="DocuSignEnvelopeInformation">
<xs:sequence>
<xs:element xmlns:q1="http://schemas.datacontract.org/2004/07/System.ComponentModel" name="PropertyChanged" nillable="true" type="q1:PropertyChangedEventHandler"/>
<xs:element name="documentPDFsField" nillable="true" type="tns:ArrayOfDocumentPDF"/>
<xs:element name="envelopeStatusField" nillable="true" type="tns:EnvelopeStatus"/>
<xs:element name="timeZoneField" nillable="true" type="xs:string"/>
<xs:element name="timeZoneOffsetField" type="xs:int"/>
<xs:element name="timeZoneOffsetFieldSpecified" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
Element names like envelopeStatusField are the names of the private variables used in the auto-generated code. The public property names match the xml that DocuSign sends. The auto-generated code also tags each object with the correct docusign namespace using XmlTypeAttribute. So from looking at the auto-generated code, I would expect my service to be happy with the input, but the WSDL generated is different, as shown above, and my service fails to deserialize the xml.
Some Code:
The auto-generated declaration of DocuSignEnvelopeInformation:
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Xml", "4.0.30319.17929")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://www.docusign.net/API/3.0")]
public partial class DocuSignEnvelopeInformation : object, System.ComponentModel.INotifyPropertyChanged {
private EnvelopeStatus envelopeStatusField;
private DocumentPDF[] documentPDFsField;
private string timeZoneField;
private int timeZoneOffsetField;
private bool timeZoneOffsetFieldSpecified;
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Order=0)]
public EnvelopeStatus EnvelopeStatus {
...
...
The OperationContract for the only method:
[SoapHeaders]
[ServiceContract(Namespace = "http:/MyNameSpace")]
public interface IDocusignEventListener
{
[OperationContract]
[FaultContract(typeof(ErrorMessageCollection), Action = Constants.FaultAction)]
string DocuSignConnectUpdate(DocuSignEnvelopeInformation DocuSignEnvelopeInformation);
}
The method that DocuSign calls
[ServiceBehavior(Namespace = "http:/MyNameSpace", ConfigurationName = "DocusignEventListener")]
public class DocusignEventListener : IDocusignEventListener
{
public string DocuSignConnectUpdate(DocuSignEnvelopeInformation DocuSignEnvelopeInformation)
{
...
return DocuSignEnvelopeInformation.EnvelopeStatus.EnvelopeID;
}
}
So, again, the question is why is the wsdl showing up this way? Why is the object different from the reference I pulled it from? And more importantly, can I fix it?
It is stunning how many hours I've spent on this, how many solutions I've tried, how many links I've followed, and how many SO answers I've read that did not answer my question before finally finding that the answer was sitting right here on SO for more than 2 years!
The root problem is that the DocuSignEnvelopeInformation object is being serialized and deserialized by DataContractSerializer by default. This essentially serializes the private member variables that make up the object in their local namespace instead of the public properties. Infuriatingly, this is the default serializer for WCF services. If the auto-generated code of the service application at least marked the sample methods with [DataContractFormat] explicitly, we would have a clue to follow, but it is just an invisible default that you have to divine somehow.
The solution is to mark each method with [XmlSerializerFormat] in the interface. This replaces DataContractSerializer with XmlSerializer as the serializer for the method parameters:
[SoapHeaders]
[ServiceContract(Namespace = "http://www.docusign.net/API/3.0")]
public interface IDocusignEventListener
{
[OperationContract]
[XmlSerializerFormat]
[FaultContract(typeof(ErrorMessageCollection), Action = Constants.FaultAction)]
string DocuSignConnectUpdate(DocuSignEnvelopeInformation DocuSignEnvelopeInformation);
}
And just like that, the public properties, with their declared namespaces and everything I need, are now serialized instead of the private data!
For my specific concern, to receive calls from DocuSign's Connect notification service, I still had one small namespace problem. The root level parameter, the DocuSignEnvelopeInformation, was still in the namespace of the method call. I’m not sure why. For now, I'm just putting the method call itself in the DocuSign API namespace (as you can see in the code sample above). The service now deserializes these calls correctly.

HTTPClient.PostAsync<T> with XmlMediaTypeFormatter serialization attributes being ignored

I'm working with an existing xsd which looks something like this (shortened for brevity):
<?xml version="1.0" encoding="utf-8"?>
<xs:schema targetNamespace="http://www.mycompany.com/Widgets"
xmlns="http://www.mycompany.com/Widgets"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:element name="Widget" type="WidgetDefinition" />
<xs:complexType name="WidgetDefinition">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
When you run this through xsd.exe, you get a class definition like:
[System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.3038")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://www.mycompany.com/Widgets")]
[System.Xml.Serialization.XmlRootAttribute("Widget", Namespace="http://www.mycompany.com/Widgets", IsNullable=false)]
public partial class WidgetDefinition {
private string nameField;
public string Name {
get {
return this.nameField;
}
set {
this.nameField = value;
}
}
}
Fast forward ... I'm using HTTPClient to POST to a REST service. The code here is pretty straightforward.
var widget = new WidgetDefinition();
// do something here to hydrate widget
var httpClient = new HttpClient();
return httpClient.PostAsync<WidgetDefinition>(
uri, terminatedCall, new XmlMediaTypeFormatter());
On the receiving end, I want to take the request payload and convert it back to a WidgetDefinition object. If you examine the request content using:
request.Content.ReadAsStringAsync().Result
The xml looks like:
<WidgetDefinition xmlns:i=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns=\"http://schemas.datacontract.org/2004/07/\">
...
Based on the XmlTypeAttribute and XmlRootAttribute attributes on the generated WidgetDefinition class, I expect this to look like:
<Widget xmlns:i=\"http://www.mycompany.com/Widgets\">
...
It appears that the XmlTypeAttribute and XmlRootAttribute attributes are ignored when the serialization is happening on the sending side.
Any clue what could be causing this?
EDIT: If I serialize this manually using XmlSerializer, it obeys the serialization attributes on the WidgetDefinition class. I think my issue has to do with the formatter being passed to the PostAsync call.
From this xmlns=\"http://schemas.datacontract.org/2004/07/\" it appears that your REST service is configured to use DataContractSerializer (the default in a WCF service) and not XmlSerializer.
You can configure your service to use XmlSerializer instead which should at least get you further along:
http://msdn.microsoft.com/en-us/library/ms733901.aspx

svcutil generated code missing parts

I have this:
"%PROGRAMFILES%\Microsoft SDKs\Windows\v7.0A\bin\svcutil.exe" ^
/noLogo /t:code /l:cs /mc /tcv:Version35 /ct:System.Collections.Generic.List`1 /n:*,MYNS ^
/config:MyServiceProxy.config ^
/out:ServiceProxy.cs ^
https://remote-service/ServiceA?wsdl
It generates classes, types and endpoint configurations as I expect.
When I add multiple endpoints ex:
"%PROGRAMFILES%\Microsoft SDKs\Windows\v7.0A\bin\svcutil.exe" ^
/noLogo /t:code /l:cs /mc /tcv:Version35 /ct:System.Collections.Generic.List`1 /n:*,MYNS ^
/config:MyServiceProxy.config ^
/out:ServiceProxy.cs ^
https://remote-service/ServiceA?wsdl https://remote-service/ServiceB?wsdl https://remote-service/ServiceC?wsdl
no endpoints in MyServiceProxy.config, and all the ServiceAWsClient() methods are missing from ServiceProxy.cs.
UPDATE: I removed the /i option, bec it made the classes internal.
UPDATE: I can now generate two .cs files, if I use the /serializer:DataContractSerializer option, I got the ServiceAWsClient() classes and without it I got the shared types.
Is there a way to get both the same time?
UPDATE: The file containing the ServiceAWsClient() classes still not good. Methods are missing paramteres. Why?
WSDL contains:
<xs:element name="service" type="tns:service"/>
<xs:element name="serviceResponse" type="tns:serviceResponse"/>
<xs:complexType name="service">
<xs:sequence>
<xs:element name="context" type="ns1:GenericContext" minOccurs="0"/>
<xs:element name="userData" type="ns2:UserData" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="serviceResponse">
<xs:sequence>
<xs:element name="resultContext" type="ns1:GenericResponseContext" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
svcutil generates:
public void service()
{
base.Channel.service();
}
when it should be:
public MYNS.GenericResultContext service(MYNS.GenericContext context, MYNS.ServiceA userData)
{
MYNS.service inValue = new MYNS.service();
inValue.context = context;
inValue.userData = userData;
MYNS.serviceResponse retVal = ((MYNS.ServiceA)(this)).service(inValue);
return retVal.resultContext;
}
ty!
The generation failed. svcutil does not support multi-targeting.
Infact the ClientBase (the proxy which is generated base class) can only access one endpoint.
You unfortunatly have to generate 3 diffrent proxies. In fact, theses proxies are encapsulating the actual channel (socket) which communicates with the service. So it seems that one proxy can handle only one endpoint

WCF: Element has already been exported error

I've acquired more information since the original post and have been able to recreate the problem in a very simple File > New Project > WCF Service Application solution. As a result I'm heavily editing the original content of this post to get rid of some of the superfluous information and simplify the examples:
We have a message contract defined as follows.
[MessageContract( WrapperName = "SingleTypeResponse", WrapperNamespace = "urn:WcfService1" )]
public class SingleTypeResponse<T>
{
[MessageBodyMember( Name = "ReturnValue" )]
public T ReturnValue { get; set; }
}
The service interface has the following:
[OperationContract]
SingleTypeResponse<string> GetStringData();
[OperationContract]
SingleTypeResponse<int> GetIntData();
When I run the project and navigate to the .svc file I get the following:
An exception was thrown in a call to a WSDL export extension: System.ServiceModel.Description.DataContractSerializerOperationBehavior
contract: http://tempuri.org/:IService1 ----> System.InvalidOperationException: The WcfService1.IService1.GetIntData operation references a message element [urn:WcfService1:SingleTypeResponse] that has already been exported from the WcfService1.IService1.GetStringData operation. You can change the name of one of the operations by changing the method name or using the Name property of OperationContractAttribute. Alternatively, you can control the element name in greater detail using the MessageContract programming model.
If I comment out GetIntData on the interface and test the service using the WCF Test Client, with the WrapperName property set, I get the following response XML:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header />
<s:Body>
<SingleTypeResponse xmlns="urn:WcfService1">
<ReturnValue xmlns="http://tempuri.org/">foo</ReturnValue>
</SingleTypeResponse>
</s:Body>
</s:Envelope>
I'm guessing that element is the source of the problem, it sees two versions of the same element, one with a string and one with an int.
I then uncommented the GetIntData and removed the WrapperName property from the MessageContract:
[MessageContract( WrapperNamespace = "urn:WcfService1" )]
public class SingleTypeResponse<T>
{
[MessageBodyMember( Name = "ReturnValue" )]
public T ReturnValue { get; set; }
}
I get the same error message with the exception that the message element it's complaining about is the ReturnValue property of the contract rather than the message contract name.
Once again commenting out GetIntData and testing with WCF Test Client I get:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header />
<s:Body>
<SingleTypeResponseOf_String xmlns="urn:WcfService1">
<ReturnValue xmlns="http://tempuri.org/">foo</ReturnValue>
</SingleTypeResponseOf_String>
</s:Body>
</s:Envelope>
So I'm able to get it to create a unique name for the wrapper, but the fact that SingleTypeResponseOf_String and SingleTypeResponseOf_Int32 both have a ReturnValue property continues to cause it to blow its brains out.
I've never thought about it before but it makes sense that generic types need to be defined as concrete types for a WSDL. Coming from that perspective, it appears that yes - you are defining two 'types' of SingleTypeResponse in your service. WSDL does not allow two element definitions of the same name & namespace to coexist (for obvious reasons - they need to be uniquely identifiable).
There are a couple of potential conflicts here. I think you've identified the first one - an element named SingleTypeResponse within the urn:WcfService1 namespace. When you turn off the naming of the message contract (allowing it to be named by the serializer) you see the below:
<!-- Setting wrapper name & wrapper namespace -->
<wsdl:message name="SingleTypeResponseOf_String">
<wsdl:part name="parameters" element="q1:SingleTypeResponse"
xmlns:q1="urn:WcfService1" />
</wsdl:message>
<!-- Setting wrapper namespace only -->
<wsdl:message name="SingleTypeResponseOf_String">
<wsdl:part name="parameters" element="q1:SingleTypeResponseOf_String"
xmlns:q1="urn:WcfService1" />
</wsdl:message>
This should avoid the first conflict, because running your two operations means that you'll be able to have two types of element (SingleTypeResponseOf_String and SingleTypeResponseOf_Int).
I believe your second conflict comes from the MessageBodyMember attribute. Because both the operations define messages in the same namespace, and both return types contain an element ReturnValue, you will get a conflict where the urn:ReturnValue element is defined twice, once as an int and once as a string.
To demonstrate see the following, with the GetIntData operation comment out, see the ReturnValue element defined:
<!-- from the XSD http://localhost/Service1.svc?xsd=xsd0 -->
<xs:element name="SingleTypeResponseOf_String">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" ref="q1:ReturnValue"
xmlns:q1="http://tempuri.org/" />
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- from the XSD http://localhost/Service1.svc?xsd=xsd2 -->
<xs:schema elementFormDefault="qualified"
targetNamespace="http://tempuri.org/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://tempuri.org/">
<xs:element name="ReturnValue"
nillable="true"
type="xs:string" />
</xs:schema>
How can you allow the MessageContract to rename the ReturnValue property? I don't think you can with DataContractSerializer.
What's the solution? Well, I don't think there is a solution using [MessageBodyMember]. If you use [DataMember] it will work fine. You mentioned before that you're using net.tcp, so I assume your .NET to .NET. Do you need to exercise that level of control of the SOAP envelopes?
Normally I use DataContract as much as possible, and only venture into MessageContract when necessary - interfacing with older SOAP style platforms.

Why does the XmlRoot attribute gets ignored in WCF and how to overcome this

We've observed that when we expose a WCF service which uses classes decorated with various xml serialisation attributes, despite the fact that we use the XmlSerializerFormat attribute on the interface any XmlRoot attribute on any of the operation's parameters gets completely ignored.
The namespace of the parameters is always that of the service and not what we specify.
This is causing us problems as it does not seem to be backwards compatible with ASMX and also because we're using BizTalk, and need to have tighter control over the shape of the XML's exchanged.
A few questions then -
Anybody knows what is the rationale
behind this decision?
Anybody knows
how this is happening? I was under
the impressions that WCF, with the
XmlSerializerFormat attribute, uses
the XmlSerialiser to serialise the
types, which would suggest XmlRoot
should be taken into account, how
come this is not the case? (is it
only due to the fact that, taking
the SOAP envelope into account, the
parameter is not root?)
Most
importantly - anybody knows if
there's a way to 'force the issue' -
i.e. get the parameters to be of the
namespace of our choosing?
I've seen this post, but I don't believe it is relevant to my question -
As per Wagner Silveira's request - the contracts I used to test this are -
[ServiceContract(Namespace = "http://servicecontract"),
XmlSerializerFormat(Style = OperationFormatStyle.Document)]
public interface ITestService
{
[OperationContract]
MyOtherType MyTestMethod(MyType obj);
}
// Composite class for DCS and XMLS
[Serializable, XmlType, XmlRoot(Namespace = "http://datacontract")]
public class MyType
{
[XmlAttribute]
public string StringValue { get; set; }
}
// Composite class for DCS and XMLS
[Serializable, XmlType, XmlRoot(Namespace = "http://datacontract")]
public class MyOtherType
{
[XmlAttribute]
public string OtherStringValue { get; set; }
}
I assume you're using SOAP as the message format. In this case, the object you're serializing is not the root of the XML, the soap envelope is. So it makes sense that the XmlRoot would be ignored. By default WCF will create a message contract for you and name the response and it has the namespace of the service. What you can do is create your own message contract to have full control over SOAP.
Create the following two classes:
[MessageContract]
public class MyTestMethodRequest
{
[MessageBodyMember( Namespace = "http://datacontract" )]
public MyType MyType;
}
[MessageContract]
public class MyTestMethodResponse
{
[MessageBodyMember( Namespace = "http://datacontract" )]
public MyOtherType MyOtherType;
}
Then change the signature of your service operation to the following.
[OperationContract]
public MyTestMethodResponse MyTestMethod( MyTestMethodRequest request )
{
return new MyTestMethodResponse {
MyOtherType = new MyOtherType {
OtherStringValue = "bar"
}
};
}
Now if you example the SOAP messages you should see the following:
Request
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none"
s:mustUnderstand="1">http://servicecontract/TestService/MyTestMethod</Action>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<MyTestMethodRequest xmlns="http://servicecontract">
<MyType StringValue="foo" xmlns="http://datacontract" />
</MyTestMethodRequest>
</s:Body>
</s:Envelope>
Response
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header />
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<MyTestMethodResponse xmlns="http://servicecontract">
<MyOtherType OtherStringValue="bar" xmlns="http://datacontract" />
</MyTestMethodResponse>
</s:Body>
</s:Envelope>
I don't know why WCF ignores XmlRoot, so I can't answer that part of your question. But I do have a couple ways to solve the problem.
start with WSDL first.
If you have a particular set of XML namespaces you would like to apply to the messages that get sent and receieved, use WSDL and XML Schema to explicitly specify them.
Then, generate the Server-side stub code, or the client-side proxy code, directly from that WSDL via the svcutil.exe tool.
use a custom ServiceHost
The other option open to you, described at this link, is to use a custom ServiceHost that overrides WCF's decision to disregard the XmlRoot or XmlType attributes on message types.
If you choose to go for the WSDL-First approach, the WSDL should look like this:
<?xml version="1.0" encoding="utf-8" ?>
<definitions
xmlns="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="urn:The-Service-namespace"
xmlns:tns="urn:The-Service-namespace"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:n0="urn:The-Request-namespace"
xmlns:n1="urn:The-Response-namespace"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
elementFormDefault= "unqualified"
>
<types>
<s:schema targetNamespace="urn:The-Request-namespace" >
<s:complexType name="Type1">
<s:sequence>
<s:element name="x" minOccurs="1" maxOccurs="1" type="s:string"/>
</s:sequence>
</s:complexType>
<s:element name="Type1" type="n0:Type1" />
</s:schema>
<s:schema targetNamespace="urn:The-Response-namespace" >
<s:complexType name="Type2">
<s:sequence>
<s:element name="x" minOccurs="1" maxOccurs="1" nillable="false" type="s:string"/>
<s:element name="y" minOccurs="1" maxOccurs="1" nillable="false" type="s:int"/>
<s:element name="z" minOccurs="1" maxOccurs="1" nillable="false" type="s:boolean" />
</s:sequence>
</s:complexType>
<s:element name="Type2" type="n1:Type2" />
</s:schema>
</types>
<message name="RequestMessage">
<part name="inPart1" element="n0:Type1" />
</message>
<message name="ResponseMessage">
<part name="outPart1" element="n1:Type2" />
</message>
<portType name="PortTypeName">
<operation name="Method1">
<input message="tns:RequestMessage" />
<output message="tns:ResponseMessage" />
</operation>
</portType>
<binding name="InterfaceName" type="tns:PortTypeName">
<soap:binding
transport="http://schemas.xmlsoap.org/soap/http"
style="rpc" />
<operation name="Method1">
<soap:operation soapAction="" style="document" />
<input> <soap:body use="literal" /> </input>
<output> <soap:body use="literal" /> </output>
</operation>
</binding>
</definitions>
This WSDL is very simple - it defines a single operation, with a single request message and a single response message.
Notice there are three xml namespaces:
urn:The-Service-namespace
used for the element that wraps the request and response - the first element inside the <SOAP:body>
urn:The-Request-namespace
used for the element wrapped inside that request wrapper, which gets deserialized into an instance of Type1.
urn:The-Response-namespace
used for the element wrapped inside that response wrapper, which gets deserialized into an instance of Type2.
If your web services interface is more complicated, has more operations and consequently more request and response message types, you can add more namespaces, if you like, for all those additional types.