Search code examples
xsdwsdl

Backward compatibility of Webservice operation output messages in case of a xsd choice extension

I have a question about backward compatibility of a Webservice interface in context of choices in output message. Couldn't really find an answer to that.

Let's assume I have a Webservice with an operation "getData" which has the following response message (this is V1 of the Webservice). The response message includes a choice element which gives back either the payload of "Instruction" or "KeyTranslation". This V1 WSDL is used by various consumer which are generating the java bindings and rolling out the application in production.

<xsd:complexType name="GetInstructionListResponse">
    <xsd:sequence>
        <xsd:element name="ContinueInfo" type="tns:ContinueInfo" form="qualified" />
        <xsd:element name="ResultLength" type="xsd:integer" form="qualified" />
        <xsd:element name="Payload">
          <xsd:complexType>
            <xsd:choice>
                <xsd:element name="DataObjectList1" type="tns:Instruction" form="qualified" minOccurs="1" maxOccurs="50" />
                <xsd:element name="DataObjectList2" type="tns:KeyTranslation" form="qualified" minOccurs="1" maxOccurs="50" />
            </xsd:choice>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="ReturnCodeList" type="tns:ReturnCodeList" form="qualified" minOccurs="0">
            <xsd:annotation>
                <xsd:documentation>Description: List of error descriptions</xsd:documentation>
            </xsd:annotation>
        </xsd:element>
    </xsd:sequence>
</xsd:complexType>

As a provider of this interface we would introduce now a third choice element "Advise" after the rollout of V1.

    <xsd:complexType name="GetInstructionListResponse">
    <xsd:sequence>
        <xsd:element name="ContinueInfo" type="tns:ContinueInfo" form="qualified" />
        <xsd:element name="ResultLength" type="xsd:integer" form="qualified" />
        <xsd:element name="Payload">
          <xsd:complexType>
            <xsd:choice>
                <xsd:element name="DataObjectList1" type="tns:Instruction" form="qualified" minOccurs="1" maxOccurs="50" />
                <xsd:element name="DataObjectList2" type="tns:KeyTranslation" form="qualified" minOccurs="1" maxOccurs="50" />
                <xsd:element name="DataObjectList2" type="tns:Advice" form="qualified" minOccurs="1" maxOccurs="50" />
            </xsd:choice>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="ReturnCodeList" type="tns:ReturnCodeList" form="qualified" minOccurs="0">
            <xsd:annotation>
                <xsd:documentation>Description: List of error descriptions</xsd:documentation>
            </xsd:annotation>
        </xsd:element>
    </xsd:sequence>
</xsd:complexType>

Question is now, is this change in the output message a breaking change, i.e does an existing consumer (working with V1 which doesn't require the new choice element) has to do anything (e.g. to regenerate the java bindings, any marshalling problems?) in case we would replace as a provider the V1 WSDL provider interface with this extended response structure or would that be transparent for him as long he doesn't require the third choice element in its processing?

Solution

  • In the meantime I was setting up a test bed (Eclipse, ApacheV6, Axis2) and was running a test:

    • Having a client which was using WSDL java bindings of V1 of the server (two choice elements)
    • Having a server running with WSDL V2 implementation having three choices.
    • Result: Java client could still connect and getting correct results for the two choice elements back from the V2 server (no marshalling problem, no recompile necessary).