2009-02-26 11 views
4

Nous avons quelques XSD dans notre projet qui définissent les types qui utilisent les attributs, ainsi que des éléments, pour spécifier les valeurs de propriété, par exemple:Soutenir XSD avec des attributs dans WCF

<Instrument name="blah"> 
</Instrument> 

-je utiliser ces XSD pour définir un schéma utilisé par un WSDL, mais lorsque je l'exécute via schemagen, le code généré est déballé. Par exemple:

public interface InstrumentService 
{  
    // CODEGEN: Parameter 'GetInstrumentResponse' requires additional schema information that cannot be captured using the parameter mode. The specific attribute is 'System.Xml.Serialization.XmlElementAttribute'. 
    GetInstrumentResponse GetInstrument(GetInstrumentRequest request); 
} 

(le GetInstrumentRequest et GetInstrumentResponse doivent être déballés aux paramètres et valeur de retour uniquement). La raison en est que le sérialiseur de contrat de données ne supporte pas les types complexes avec attributs, mais j'ai lu quelque part que si vous utilisez document/literal, plutôt que document/literal enveloppé pour définir le WSDL, schemagen tombera Retour à une implémentation XmlSerializer, qui supporte les attributs. Jusqu'à présent, mes tentatives pour que cela fonctionne échouent: // CODEGEN: Générer un contrat de message depuis l'opération GetInstrument n'est ni RPC ni document encapsulé.

Donc, est-ce que cette supposition concernant le document/littéral est erronée? Est-il possible de générer du code d'interface non déplié à partir d'un WSDL qui définit des types complexes avec des attributs?

est ici le document modifié/WSDL littéral J'utilise:

<?xml version="1.0" encoding="UTF-8"?> 
<wsdl:definitions 
    targetNamespace="http://tempuri.org/" 
    xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" 
    xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" 
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
    xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" 
    xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
    xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" 
    xmlns:tns="http://tempuri.org/" 
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
    <wsdl:types> 
     <xs:schema targetNamespace="http://tempuri.org/"> 
      <xs:complexType name="testComplexType"> 
       <xs:sequence/> 
       <xs:attribute name="name" type="xs:string"/> 
      </xs:complexType> 
      <xs:element name="input" type="tns:testComplexType"/> 
     </xs:schema> 
    </wsdl:types> 
    <wsdl:message name="GetInstrumentIn"> 
     <wsdl:part element="tns:input" name="input"/> 
    </wsdl:message> 
    <wsdl:message name="GetInstrumentOut"/> 
    <wsdl:portType name="InstrumentService"> 
     <wsdl:operation name="GetInstrument"> 
      <wsdl:input message="tns:GetInstrumentIn"/> 
      <wsdl:output message="tns:GetInstrumentOut"/> 
     </wsdl:operation> 
    </wsdl:portType> 
    <wsdl:binding name="InstrumentService" type="tns:InstrumentService"> 
     <soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/> 
     <wsdl:operation name="GetInstrument"> 
      <soap:operation soapAction="GetInstrument" style="document"/> 
      <wsdl:input> 
       <soap:body use="literal"/> 
      </wsdl:input> 
      <wsdl:output> 
       <soap:body use="literal"/> 
      </wsdl:output> 
     </wsdl:operation> 
    </wsdl:binding> 
    <wsdl:service name="InstrumentService"> 
     <wsdl:port binding="tns:InstrumentService" name="InstrumentService"/> 
    </wsdl:service> 
</wsdl:definitions> 

Répondre

3

excuses pour répondre à ma propre question. Il semble que la simple suppression de l'instruction nillable = "true" du type de réponse d'opération, dans le schéma de type WSDL de document/literal/wrapped, fait l'affaire - pas besoin de passer à document/literal.

<wsdl:types> 
    <xs:schema elementFormDefault="qualified" targetNamespace="http://com.barcap.cbts.core.messaging.rpc/"> 
     <xs:element name="GetInstrument"> 
      <xs:complexType/> 
     </xs:element> 
     <xs:element name="GetInstrumentResponse"> 
      <xs:complexType> 
       <xs:sequence> 
        <!-- nillable="true" removed --> 
        <xs:element maxOccurs="1" minOccurs="0" 
         name="GetInstrumentResponse" type="tns:Instrument"/> 
       </xs:sequence> 
      </xs:complexType> 
     </xs:element> 
     <xs:complexType name="Instrument"> 
      <xs:sequence/> 
      <xs:attribute name="name" type="xs:string"/> 
     </xs:complexType> 
    </xs:schema> 
</wsdl:types> 
+0

L'attribut nillable n'a jamais été utilisé dans votre exemple précédent. – D3vtr0n

+1

Excuses, doit avoir jeté le mauvais wsdl. En règle générale, j'ai trouvé que nillable = true cause des problèmes avec la génération .net wsdl (par exemple dans le cas ci-dessus quand il est présent, ou lorsque nillable = true est -non-appliqué aux types de paramètres/retours string). D'autres problèmes semblent être des conventions de nommage, qui sont plus strictes que les frameworks de génération de code java-side wsdl-> équivalents comme axis ou cxf. – Andy

Questions connexes