Grouper Developers Forum

[Chris Hyzer <>]

Hey,

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 
try.

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...

Thanks!
Chris