Announcement Announcement Module
Collapse
No announcement yet.
Web service versioning Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Web service versioning

    Hi,

    I've searched carefully through the spring documentation and couldn't find an answser to my pb: I have two versions of a ws that differs only by the response payload and i wonder how i could handle both versions easily.

    Let's take an exaample with the function List<Message> getMessages(). When there's no messages:
    - in version 1, I return a "null" list
    - in version 2, I return an "empty" list

    In a xml style syntax, the response looks like:

    V1:
    <getMessageReponse xsi:nil="true"/>

    V2:
    <getMessageReponse/>

    My pb is: how can I handle nicely the two versions in Spring? I wanted to use xslt translation but this is not applicable since I can't know the version the client requested (since the two request are the same). I use a PayloadRootQNameEndpointMapping for routing and namespaces are the same in the two versions.

    I can't associate a given endpointMapping to a corresponding wsdl since endpointMapping are discovered automatically by the MessageDispatcherServlet. Shall I create a new servlet with a fresh new context and thus a new endpointMapping?

    Tutorials and examples didn't help me much on this subject.

    Has someone already faced this pb ?

    TIA,
    Regards

  • #2
    Hi
    I have the same problem.

    Another example :
    The method with the following prototype :
    Code:
    User getUser(int)
    The schema would be :
    Code:
    <xsd:complexType name="User">    
      <xsd:sequence>
        <xsd:element name="login" type="xsd:string" />
        <xsd:element name="password" type="xsd:string" />
      </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="GetUserRequest">
      <xsd:complexType>
        <xsd:sequence>
          <xsd:element name="id" type="xsd:int" />
        </xsd:sequence>
      </xsd:complexType>
    </xsd:element>
    <xsd:element name="GetUserResponse">
      <xsd:complexType>
        <xsd:sequence>
          <xsd:element name="user" type="tns:User" />
        </xsd:sequence>
      </xsd:complexType>
    </xsd:element>
    But I would like to add a new property in the "User" type. So I create the version 2.0 of my schema :
    Code:
    <xsd:complexType name="User">    
      <xsd:sequence>
        <xsd:element name="login" type="xsd:string" />
        <xsd:element name="password" type="xsd:string" />
        <xsd:element name="email" type="xsd:string" />
      </xsd:sequence>
    </xsd:complexType>
    <xsd:element name="GetUserRequest">
      <xsd:complexType>
        <xsd:sequence>
          <xsd:element name="id" type="xsd:int" />
        </xsd:sequence>
      </xsd:complexType>
    </xsd:element>
    <xsd:element name="GetUserResponse">
      <xsd:complexType>
        <xsd:sequence>
          <xsd:element name="user" type="tns:User" />
        </xsd:sequence>
      </xsd:complexType>
    </xsd:element>
    How to associate this new schema (2.0) with the endpoint and try to keep the compatibiliy with the previous version (1.0) with the help of an XSLT stylesheet ?

    In the reference documentation, chapter 2.3.4, you speak about versioning but there is no more explanations in the others chapters.

    Regards

    Comment


    • #3
      Well the question is whether version 1 messages can be transformed into version 2 messages, i.e. can you define a XSLT that transforms from version 1 to 2.

      If this is possible, you can create one endpoint that only handles version 2 messages, and create two endpoint mappings: one that matches version 1 messages, applies the stylesheet (using PayloadTransformingInterceptor), and executes the endpoint. Then you create a mapping that only matches version 2 messages, does not apply the stylesheet, and executes the same endpoint.

      Obviously, you will need some differentiating characteristic between version 1 and 2 of the contract. Typically, this is done by letting version 2 have a different namespace, but any way will do.

      Comment


      • #4
        Thanks Arjen

        I found two documentation about this subject :
        http://www.ibm.com/developerworks/we...ry/ws-version/
        http://blogs.iona.com/sos/2007/04/de...st_practi.html

        The second is very interesting. It's explain where to put the version in xsd, xsdl, service, port...
        How do you think about this "best practices" ?

        I try to experiment this best practices in a sample application but I get stuck in the WSDL generation with the XsdBasedSoap11Wsdl4jDefinitionBuilder because it can't have more than one port.
        I think it would be great to have the possibility to define several ports along with namespace.

        Thomas

        Comment


        • #5
          Really there's no need for a transform with the schema you've presented. Your change is backwards compatible if you add minOccurs="0" to your email definition.

          Version1 based requests just don't come with an email, so code that relies on version2 just needs to be aware that email is optional. At least until you get everyone off of version 1.

          Comment

          Working...
          X