I\'ve been designing web services for quite a while now but never had to expose a \'complicated\' WCF service until recently. I was baffled at the apparent lack of \"proper
The premise of this question is that WCF should map an XSD complexType element with an abstract attribute set to true as a C# abstract class. If you look at the WSDL spec on future extensibility, you'll see an example of how the spec uses this XSD feature to allow the addition of "element items" without needing to modify the WSDL spec itself.
The purpose of the XSD abstract attribute is to allow other XSD "types" to inherit definitions from the base type. This may sound like what @dovholuk is looking for WCF to do, but in actually it is a device for XSD type definition. This XSD feature has no bearing on the serialization of XML into C# class constructs since it is intended to be use within XSD definitions. So summarizing both @blowdart & @JohnSaunders, WCF is an abstraction over message exchange of which XSD-based type definition is an implementation detail.
Use [XmlSerializerFormat] Attribute
"abstract" is an implementation detail. It has no place in a service contract. Naturally, as soon as you insist that your caller must be aware you are returning an abstract type, WCF must fall back on a serializer that can expose this fact: and you're back to being stuck with the XmlSerializer.
I suspect you're using abstract because that's the OO way to do things. But you're not doing OO, you're doing web services - SOA. There's a difference.
The attribute "abstract=true" on abstract types as well as a type's inheritance is preserved in the WSDL when you use Java EE. Any use of traditional Java keywords like "abstract" or "extends" in object models is preserved in the WSDL and the XSDs. No special attributes or mangling required.
WCF services fail to generate the abstract attribute in the WSDL. WCF also fails to traverse object model inheritance, requiring the KnownTypeAttribute to be used in order for the proper XSD inheritance to result in the WSDL.
WCF clients however will generate abstract types off the WSDL from a service that describes some types as abstract as well as preserve the inheritance for any type (using the "Service Reference" in Visual Studio to setup a client to a Java EE service for example).
So WCF honors abstract types defined in a WSDL for the client proxy but it does not create the abstract types in the service for WSDL creation (without some special attention perhaps, like the KnownTypeAttribute needed for inheritance).
Well it's because WCF doesn't pass objects, it passes messages. This isn't remoting, so the type end up with on the client is not the same type you have on the server - it's simply a holding class for various properties. Implementing "abstract="true" simply makes no sense. Messages are just data - how would the client know what concrete type to use, as you're not sharing classes, but simply a representation of the message.