Several times clients have asked how to govern a minor version of a service in WebSphere Service Registry and Repository. By minor they can mean one of several things. Firstly it could be that the messages their service sends back have changed in some compatible way, for example sending back an extra parameter element. Particularly if such a service is provided by a third party, the client has no choice but to accept the change and continue to use their old programs with this new version of the service. The service could have been updated in production but there is no change needed to its consumers. The version is going from 1.0 to 1.1
Secondly it could be that the new service has changed to be incompatible with the old service, but the change is still considered minor enough not to want to make a new major version. The client may want to use both versions in parallel and retire the old version when every user is on the new version.
There are then a few different approaches I've heard about to handling these situations in WebSphere Service Registry and Repository.
1. Replace the service documents (WSDL and XSD) directly to add new end points, or manually create a Soap endpoint. Then some of the end points registered in WSRR may be running the old service, and some running the new service. After clients of the service have swapped over to the new endpoint which runs the new service, change the interface documents to the new interface.
This approach is the simplest, but has issues with audit ability and controlling the change over. For example, the old interface is lost when you update it in WSRR to the new interface. You cannot control your service consumers swapping to use the new service end points because they appear as just more end points of the old service, until you update the interfaces. You would have to tell consumers some other way, via email perhaps. Or it might be that the old service is gone anyway.
So this approach is most suitable for run times doing lookups in WSRR, such as WebSphere DataPower or WebSphere Message Broker, and you are just using WSRR as a place to store wsdls for these runtimes to look up. When the service really has been updated already, you update WSRR to record the new service interfaces and end points and the run times start to use the new service. You are not really that interested in SOA governance or managing and recording the state of services.
2. For a new interface, or some non functional change which is incompatible, a second approach exists. For example, the service could be moved to some other transport which your client does not yet work with, for example a web service could be reimplemented as a REST service. This change suggests that a different Service Level Definition (SLD) might be appropriate, and indeed that is the second approach.
A new SLD is added to the service version, this SLD may have a new interface (say 1.1) or new end points of a different sort to the old SLD, say REST endpoints instead of SOAP endpoints. The clients then have to redo their Service Level Agreements (SLAs) to now point to this new SLD, and of course update their code if necessary to call the new endpoints.
However, the SLD can only be either not-for-use or subscribable, the service version it is attached to is still showing version 1.0 and is likely showing that this version is in production. If you wanted to actually put the new minor version of the service through test and staging, then you would need to do this outside of the control of WSRR.
Also the SLD is meant to represent non-functional aspects of a service, however the interface being different is really a new service, and is definitely a functional difference from the old service. So this approach could be considered a slight abuse of the SLD mechanism.
This approach has better governance, tracking and auditability. The new and old SLD can exist side by side, and the old SLD can be deprecated to indicate to clients to move over to the new one, then finally retired when there is no one using it. The old interface and endpoints can be left attached to the old SLD, so you can always see what the interface used to be. This approach has a good balance between SOA governance and speed and ease.
3. Finally you can follow the WSRR governance practices, and make the new service interface and/or endpoints a new Service Version at version 1.1. This means you have to re-make every artifact inside WSRR: the service version, the SLD, the interface, the endpoints, etc. You again need to get clients to make a new SLA to the new SLD on the new Service Version, but this time it is clear that this is a new version of the service and not just some different SLD which happens to have a different interface or endpoint type.
You can then deprecate the whole 1.0 service version, indicating to clients that they need to move off it. It is also possible in WSRR to link the old service version to the new service version to show that the new version is the one which should be migrated to.
This approach is clearer from an audit perspective and has the best governance. The old service details are preserved in WSRR as service version 1.0, and the new service details as service version 1.1. The 1.1 service version can be taken through the life cycle, from development to staging, test and then into production. The old 1.0 service version can be deprecated, then retired.
However of course this approach is the most heavyweight, as it requires the entire service version life cycle to be followed and all the related objects to be created again in WSRR.
So there are three alternatives, depending on how you use WSRR and how much governance, control and effort you want when recording minor service versions. In my opinion, approach 3 is of course what is always recommended and is definitely following how WSRR is meant to be used. In my opinion approach 2 is a useful short cut when you really do not want to make a new Service Version and associated objects inside WSRR. I wouldn't really recommend approach 1, unless you are just using WSRR for some runtime ESB to do look ups and do not care about service governance.