Gestern habe ich im ersten Teil ein Problem geschildert, das auftritt, wenn man versucht Polymorphismus im Zusammenhang mit WCF-Services einzusetzen. Dabei ging es konkret darum Interfaces oder abstrakte Klassen als Parameter an Service-Methoden zu übergeben.
Die vorgestellte Lösung für das Problem mittels des ServiceKnownType-Attributs hatte den Nachteil, dass "echter" Polymorphismus nicht unterstützt wurde und somit ein weiteres Problem geschaffen war bzw. das eigentlich Problem nicht richtig gelöst war.
Um in unserem Beispiel "echten" Polymorphismus zu unterstützen, muss es möglich sein, beliebige Instanzen von Klassen an den Service zu übermitteln, die entweder das Interface ICustomer implementieren oder von der abstrakten Klasse CustomerBase abgeleitet sind. Möglich ist dies durch den Einsatz des NetDataContractSerializers. Wie das im Detail funktioniert beschreibt Aaron Skonnard in seinem Blogeintrag WCF's NetDataContractSerializer.
Mit Hilfe des dort vorgestellten NetDataContractFormat-Attributs sieht die Beschreibung unseres Service somit folgendermaßen aus:
-
[ServiceContract]
-
public interface ICustomerService
-
{
-
[OperationContract]
-
[NetDataContractFormat]
-
void AddCustomerInterface(ICustomer customer);
-
-
[OperationContract]
-
[NetDataContractFormat]
-
void AddCustomerBase(CustomerBase customer);
-
}
OK, alles ist super. Polymorphismus wird unterstützt und wir sind glücklich.
Naja, leider nicht wirklich ...
Wer den Beitrag von Aaron Skonnard aufmerksam gelesen hat, dem sollte klar sein, dass dieser Ansatz dem Grundsatz der Serviceorientierung widerspricht. Ein Java-Client wird beispielsweise mit diesem Service nicht mehr kommunizieren können. Ihm fehlen schlichtweg die Informationen über Typen (genauer die XML Schema Definitionen), die bei der Methode mittels ServiceKnownType-Attribut bereits gestellt wurden.
Wenn wir für unseren Services die ServiceMetadataBehaviour-Eigenschaft HttpGetEnabled aktivieren, bestätigt ein Blick in die automatisch generierte WSDL diesen Umstand. Die nachfolgend dargestellten komplexen Typen SimpleCustomer und ExtendedCustomer werden nämlich nicht mehr generiert.
-
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" ...>
-
<xs:complexType name="SimpleCustomer">
-
<xs:complexContent mixed="false">
-
<xs:extension base="tns:CustomerBase">
-
<xs:sequence />
-
</xs:extension>
-
</xs:complexContent>
-
</xs:complexType>
-
<xs:element name="SimpleCustomer" nillable="true"
-
type="tns:SimpleCustomer" />
-
<xs:complexType name="CustomerBase">
-
<xs:sequence>
-
<xs:element minOccurs="0" name="name"
-
nillable="true" type="xs:string" />
-
</xs:sequence>
-
</xs:complexType>
-
<xs:element name="CustomerBase" nillable="true"
-
type="tns:CustomerBase" />
-
<xs:complexType name="ExtendedCustomer">
-
<xs:complexContent mixed="false">
-
<xs:extension base="tns:CustomerBase">
-
<xs:sequence>
-
<xs:element minOccurs="0"
-
name="customerID"
-
nillable="true"
-
type="xs:string" />
-
</xs:sequence>
-
</xs:extension>
-
</xs:complexContent>
-
</xs:complexType>
-
<xs:element name="ExtendedCustomer"
-
nillable="true" type="tns:ExtendedCustomer" />
-
</xs:schema>
Aber keine Sorge, auch für dieses Problem gibt es eine Lösung in Teil 3.
Nachtrag: Nicholas Allen gibt in seinem Blog einen wichtigen Hinweis, warum das NetDataContractFormat-Attribut nicht angewendet werden sollte. Der Grund ist, dass die Beschreibung des Services verändert wird, was laut diesem MSDN Eintrag zu unbestimmten Verhalten führt.
[...] Das Spiel lässt sich nahezu unendlich so weiter spielen. Eine Lösung dafür gibt es in Teil 2. [...]
[...] Lösung für ein Problem bin ich noch schuldig geblieben. Die beim letzten mal vorgestellte Lösung hatte den Nachteil, dass ein wichtiges Prinzip der Serviceorientierung [...]