I attended the 4th International Workshop on SOA & Web Services Best Practices workshop at OOPSLA today. The workshop brings together people with theoretical and practical background with the respect to SOA and Web Services.
One of the things that were discussed was the versioning of (web) services, i.e. how to handle web service upgrades and discontinuance. What we found, with good help from Nico Josuttis who attended the workshop, can be summarized into these three points:
- Each modified service is a new service
- Each modified data type is a new data type
- Don’t use service types in your application
Basically, this gives how you should handle creating new versions of a service while providing older versions of the service to “old” client. The thing is that when you create a new version of the service, that’s a new service that gets deployed aside the old service that clients that are aware of the new version can connect to. Old clients can still, at least for a certain period, connect to the old version. The same goes for data types, typically defined using XML Schema Definitions.
I think that versioning is a very important architectural decision that you need to make when you create services in a large organization, or between organizations, where services and clients have different owners, funding, and life-cycles.
Automated robustness testing
One of the interesting papers submitted to the workshop presented an approach for generated robustness tests for web services from the WSDL of the web service. Basically, the approach was that the WSDL was used to generate tests that could be run using a unit testin tool such as JUnit, and using a tool like JCrasher to generate different kinds of inputs to the web service in order to test that the service is able to handle these. I think this is a good idea that has a lot of potential in automatically assessing the robustness of the service.