How to model this?

Jan 18, 2008 at 4:06 PM
Hi, I need to create a WCF service that matches an existing .asmx service in terms of interface. The WSDL for the existing service contains an operation response as such:

Method Signature:

CreateUserResponseStructure CreateUser(CreateUserRequestStructure)

Where the object CreateUserResponseStructure has one member 'Item' that is defined as type 'object' but a couple of Serialisation decorations declare that the object type returned should be either CreateUserResponseErrorStructure or CreateUserResponseResultsStructure.

eg:

public partial class CreateNewUserResponseStructure
{

private object itemField;

/// <remarks/>
System.Xml.Serialization.XmlElementAttribute("Error", typeof(CreateNewUserErrorStructure))
System.Xml.Serialization.XmlElementAttribute("Results", typeof(CreateNewUserResultsStructure))
public object Item
{
get
{
return this.itemField;
}
set
{
this.itemField = value;
}
}
}

Now in the WSDL, this comes out as:

<s:complexType name="CreateNewUserResponseStructure">
<s:sequence>
<s:choice minOccurs="1" maxOccurs="1">
<s:element minOccurs="0" maxOccurs="1" name="Error" type="s0:CreateNewUserErrorStructure" />
<s:element minOccurs="0" maxOccurs="1" name="Results" type="s0:CreateNewUserResultsStructure" />
</s:choice>
</s:sequence>
</s:complexType>

What I need to do is to model my new interface as closely as possible to this, in order to minimise the impact on the numerous existing service subscribers.

Any ideas?

Carl
Developer
Jan 18, 2008 at 5:57 PM
Since you already have a WSDL defined, then you may reuse it by adding the wsdl file in a solution folder like the "Schemas" folder created in a blank solution and then reference the types in a n XsdMessage element.
As a side comment, the typical recommendation regarding types and contract is to be explicit in your contract definition about types, and in this case, having an object type as a return value may lead to some kind of usability issues on the consumer side. On the other hand, you have a backward compatibility trade off so you may not have enough margin for contract updates (in that case, the trivial change might be having a property "Results" of type "CreateNewUserResultsStructure" and Error of type "CreateNewUserErrorStructure").
Jan 21, 2008 at 10:21 AM
Thanks Charlie, I'd already considered this approach after going through the hands on labs but unfortunately, no elements can be found in the wsdl when I add it and try to reference it from teh xsd message. I thougth perhaps I could not use a wsdl...

Any ideas?
Developer
Jan 22, 2008 at 3:32 PM
Make sure that your WSDL definition file has the types defined in a <types> element or in case you have external references (includes) make sure you have access to the files/links in these references. The xsd type picker is capable of reading the types in a WSDL file so you should be able to do that.
Jan 25, 2008 at 10:00 AM
Hi Charly, I've solved that particular problem now, and my current sticking point is the following section of WSDL, which does not comply with the DataContractSerialiser:

<s:complexType name="CreateNewUserResponseStructure">
<s:sequence>
<s:choice minOccurs="1" maxOccurs="1">
<s:element minOccurs="0" maxOccurs="1" name="Error" type="s0:CreateNewUserErrorStructure" />
<s:element minOccurs="0" maxOccurs="1" name="Results" type="s0:CreateNewUserResultsStructure" />
</s:choice>
</s:sequence>
</s:complexType>

I'm not sure how I can change the WSDL so that I can use the DataContractSerialiser without compromising the interface?
Developer
Jan 25, 2008 at 3:57 PM
As far as I see, the 'choice' element might not be compatible the DC serializer. or actually not able to be code gen as a public type.