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

  • WSDL Versioning

    Hi,

    As WSDL is generated based on XSD definition, I wanted to know what is the best practise suggested for extending the base vocubalory so that new attributes can be accomodated?

    For this, if one goes ahead and extend base vocubalory by using xs:extension, he ends up creating new Java classes for new extended XSD elements. And, of course, a new version of WSDL.

    Is it advisable to extend the base vocubalory in XSD leading to a new XSD with xs:extension?

    OR,

    one could go ahead add addtional attributes in the same XSD. But that might impact backward compatibility aspect?

    Pl advice!

  • #2
    Found an existing thread on Web service versioning

    Found an existing thread that clarifies my query:

    http://forum.springsource.org/showth...hlight=version

    thanks

    Comment


    • #3
      I struggled with this for a little bit... here is what I ended up doing.

      1) Create V2 of my xsd with the changes and a different namespace.
      2) In my web.xml I created a new servlet that maps to ws-2.0 (the original mapped to ws-1.0)
      3) Each servlet specifies a different web-context.xml (web-context1.0.xml and web-context2.0.xml)
      4) Created a new Endpoint WebServiceV2 (original was WebServiceV1)
      5) Mapped the schema's to the right endpoints in the associated web-context file.
      6) Used axis to generate new version of my schema to com.orangeleap.ws.schema.v2 (original was in com.orangeleap.ws.schema.v1)

      Those are the basics... I would be happy to share all of this code/config to anyone interested as our product is open source.

      As I see it the only thing I don't like about this approach is because I am using the OXM/JAXB integration and I changed namespaces of the xsd I can't subclass the original implementation in the 2.0 implementation. Also it creates and extra set of classes for every version you support. Other than this drawback it's easy to maintain and seems to work well.

      Hope this helps someone....

      -LeoD

      Comment


      • #4
        Use of PayloadTransaformingInterceptor

        Thanks LeoD for answering. Would be helpful if you can share the source code.

        I have been doing research and found that use of PayloadTransformingInterceptor has been recommended if it has been about addition of new attributes.

        Following link presented a clear idea on how to go about using PayloadTranfromingInterceptor for Web service versioning.

        http://www.cafebabe.me/2007/03/migra...ncoded-to.html

        Comment

        Working...
        X