Stellan recently wrote
an excellent article about dealing with the versioning of service interfaces. I thought I'd chip in with a slick way of dealing with the versioning of the service implementations themselves.
To summarise his approach, Stellan talked about including versioning information in the namespace of your service interfaces, which as he says:
- Means that clients already using the interface won't 'break' the service interface.
- Allows service implementations (and clients, potentially) to dynamically determine the service version based on a message.
One further advantage that Stellan doesn't directly allude to is the co-existence of multiple versions of the same interface in the same runtime environment, which can be exceedingly useful, as I'm about to explain.
Stellan explains in his article that the namespaced interfaces can be used on the server to route the message to either the latest and greatest or original versions of the service. Unfortunately, the side effect of that is that you have to keep
maintaining two versions of the service, which is made even worse when you have some kind of underlying data store which has to be shared by both versions, because any structural change to that database will require you to modify the data access layer of every version of the service you currently have deployed.
A little while ago, I came up with what I think is a nifty solution to this issue, which I called the Service Interface Version Adapter pattern. The pattern allows you to maintain total backward compatibility with clients, while only keeping one version of the service live. I'm sure I'm not the only one to arrive at the same answer, but I've never seen it documented anywhere.
Basically, the pattern makes the assumption that version N+1 of your service is backward compatible
from a functional point of view with version N. The interface can have changed beyond all recognition, providing it still possible to achieve the same result. Instead of keeping the old version of the service around, we introduce a
transformation between the old version of the service and the new.
If the transformation is simple, it could be implemented as an XSLT stylesheet, for more complex cases, bespoke Java/.NET/Python might be required, but it's complexity will be far simpler than the original service in the vast majority of cases. What's more, since there's now only one implementation of the service, clients calling the old version of the service will
automatically benefit from bug fixes with no extra effort.
Okay, so we now have one service implementation, but two working interfaces. What happens when we need to release version N+2? Easy: We add another interface version adapter which converts between version N+1 and version N+2.
We could have achieved the same result by modifying the original transform to target version N+2, and introducing a new one between N+1, but if we
had done that, we'd have to maintain an ever increasing list of transformations - back to square one.
By just adding one new transform, the effort for each new version is the same: one new transformation. Clients of version N and version N+1 can continue to benefit from bug fixes, no matter how long they take to upgrade.
Obviously, it'd be right to consider the performance implications of this. In reality however, most of the transformations involved will be so simple (add a default value here, move an attribute there) that even an XSLT based implementation will be fast (as long as you don't use DOM based transforms), so unless you're supporting 100s of versions, I don't believe it'll be a problem, and consider the alternative: 100s of fully fledged service implementations to maintain.
If you're really worried about performance, and your budget can stretch to it, you could even consider implementing the whole pattern using an XML appliance like the 1U
IBM DataPower which will do most of the heavy lifting in hardware. I have it on good authority that they are faster than an a flock of exceptionally fast things.
A little while ago, I came up with what I think is a nifty solution to this issue, which I called the Service Interface Version Adapter pattern. The pattern allows you to maintain total backward compatibility with clients, while only keeping one version of the service live. I'm sure I'm not the only one to arrive at the same answer, but I've never seen it documented anywhere.
Basically, the pattern makes the assumption that version N+1 of your service is backward compatible from a functional point of view with version N. The interface can have changed beyond all recognition, providing it still possible to achieve the same result. Instead of keeping the old version of the service around, we introduce a transformation between the old version of the service and the new.
If the transformation is simple, it could be implemented as an XSLT stylesheet, for more complex cases, bespoke Java/.NET/Python might be required, but it's complexity will be far simpler than the original service in the vast majority of cases. What's more, since there's now only one implementation of the service, clients calling the old version of the service will automatically benefit from bug fixes with no extra effort.
Okay, so we now have one service implementation, but two working interfaces. What happens when we need to release version N+2? Easy: We add another interface version adapter which converts between version N+1 and version N+2.
We could have achieved the same result by modifying the original transform to target version N+2, and introducing a new one between N+1, but if we had done that, we'd have to maintain an ever increasing list of transformations - back to square one.
By just adding one new transform, the effort for each new version is the same: one new transformation. Clients of version N and version N+1 can continue to benefit from bug fixes, no matter how long they take to upgrade.
Obviously, it'd be right to consider the performance implications of this. In reality however, most of the transformations involved will be so simple (add a default value here, move an attribute there) that even an XSLT based implementation will be fast (as long as you don't use DOM based transforms), so unless you're supporting 100s of versions, I don't believe it'll be a problem, and consider the alternative: 100s of fully fledged service implementations to maintain.
If you're really worried about performance, and your budget can stretch to it, you could even consider implementing the whole pattern using an XML appliance like the 1U IBM DataPower which will do most of the heavy lifting in hardware. I have it on good authority that they are faster than an a flock of exceptionally fast things.
No comments:
Post a Comment