Consider this: if you're designing a service right now, there's a chance that you want this service to be successful, and reused in production for a long while to come. With success (and reuse) comes evolutionary change to the WSDL contract: new users will typically demand more functionality, or use your service in ways you didn't originally anticipate. You need to be able to cater for this change, allowing your contract to be improved over time without breaking existing service consumers.
I've put together some thoughts on how to support minor and major releases of WSDL contracts, where a "minor" point release of the contract maintains on-the-wire compatibility with existing service consumers. The technique involves a scheme for embedding major- and minor-version information in WSDL namespaces; the approach is described in more detail in the attached PDF paper.
Would be interested to hear if anyone out there has some improvements on the scheme, or alternatively, has a more elegant approach to the problem of WSDL versioning? In the meantime, if you're designing for success, then do think about versioning - the sooner the better.
Comments (1)
Hi Adrian
"if you're designing for success, then do think about versioning" Big +++1
general comment is that this interesting paper concentrates on the "big-bang" style of versioning. This is valid style and apparently some vendors like it.
WSDL is the XML language and when versioning XML Vocabularies there's another style of versioning : compatible evolution.
Please have a look at this section in the WSDL2 Primer :
http://www.w3.org/TR/wsdl20-primer/#adv-versioning.
Both styles are mentioned there. The combined approach is also mentioned. Compatible evolution approach is typically preferred.
Another thing WSDL can also describe RESTful services, the only methods there are POST/GET/UPDATE/DELETE.
Versioning of such WSDLs is really about versioning the input/output XML vocabularies.
I'd personally like to see this paper evolve to describe the compatible evolution too. Describe pros and cons of both approaches. Recommend the best approach depending on the environment, etc...
Posted by Sergey Beryozkin | April 25, 2007 11:45 AM
Posted on April 25, 2007 11:45