Results 1 to 4 of 4

Thread: WSDL Versioning

  1. #1
    Join Date
    Nov 2009
    Posts
    3

    Default 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. #2
    Join Date
    Nov 2009
    Posts
    3

    Default Found an existing thread on Web service versioning

    Found an existing thread that clarifies my query:

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

    thanks

  3. #3
    Join Date
    Dec 2008
    Location
    Dallas
    Posts
    13

    Default

    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

  4. #4
    Join Date
    Nov 2009
    Posts
    3

    Default 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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •