Skip to Content.
Sympa Menu

grouper-dev - web service versioning strategy

Subject: Grouper Developers Forum

List archive

web service versioning strategy

Chronological Thread 
  • From: Chris Hyzer <>
  • To: "" <>
  • Subject: web service versioning strategy
  • Date: Thu, 20 Aug 2009 10:38:25 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US


I think 1.5 might have a WSDL change that will make existing SOAP (and
*maybe* REST) clients not work... unless we do something about versioning.

I have been thinking about this a lot, and I think our best strategy is to
basically make a service for each version, running in the same WS webapp
(perhaps optionally, not sure). I will make a separate package or source
folder [might be preferable] for all beans in the service (but not the
logic). Then for SOAP I will hook up each set of beans to the central logic
package, and run the AXIS code generation routine. This does mean that the
new versions will have a different URL than the old version, but *nothing*
will change in the service contract of the old versions.

.e.g the SOAP URL for 1.4 is: /grouperWs/services/GrouperService
The SOAP URL for 1.5 is: /grouperWs/services/GrouperService_v1_5

I don't think there is any easy way to do this, so what I am trying to
optimize is:

1. No changes for existing clients
2. One webapp to deploy
3. Still use code generation
4. Have a WSDL for each version

We can monitor the size of the generated code (it will get larger and
larger), and I think we should have some end of life on old versions if the
code gets too large, or have a way to optionally enable past versions (I
think we can do this).

Anyways, I don't even have a proof of concept of this, but it is what I will

If anyone has experience with versioning Axis automatically generated web
services, and has ideas or suggestions, please let me know. I asked the Axis
mail list a while back and didn't hear anything back.

On the REST side, there is no WSDL, and we have more control, so Im not sure
we need to take the same approach, I might just be able to code it so that it
is backwards compatible. We will see what changes exactly, maybe the same
approach is safest...


  • web service versioning strategy, Chris Hyzer, 08/20/2009

Archive powered by MHonArc 2.6.16.

Top of Page