Revisiting Service Versioning

A fellow member of the SOA Consortium, Surekha Durvasula, EA Manager for Kohl’s, recently posted her perspective on service versioning on the SOA Consortium’s blog. At the end, she asked five questions, to which I thought I’d respond.

  1. How many versions of a service should be “live” at any given time? How many versions are too many?
    I’ve actually blogged on this one, so make sure you read this entry before reading the rest of my answer. I’ve yet to see this put into practice, however, for two reasons. First, many organizations are still focused on getting version one out the door, so the pressure isn’t on to solve this problem. Second, organizations are still learning how to manage the service consumer and service provider relationship. The approach I outline requires significant maturity in managing consumers and product lifecycles. In the typical project-based culture in IT, this level of maturity is hard to find. In the absence of maturity, I typically see an arbitrary number set (usually 3). Setting a limit certainly recognizes that versioning must be dealt with, but only time will tell whether that number is right or not.
  2. Do you use the service mediation layer to achieve backward compatibility?
    I’ve certainly advised companies that this can be done, but again, haven’t seen it put into practice yet. If we have a policy that says two or more versions must be able to co-exist in production, that implies that we have the ability to route to either of them. If we can do this, there shouldn’t be a need to leverage a mediation layer unless some consumer can’t change in time. This is why I think lots of companies are picking 3 as the “right” number of versions to support. It assumes that when version 2 comes out, consumers should be able to move to v2 by the time v3 is ready. If you choose to only have one version running in production (the latest), and leverage the mediation layer, you may eventually run into a type of change that isn’t easily mediated at which point you need to fall back to having multiple versions running at once. Knowing this, I’d make sure I knew how to run multiple versions at the same time first, and then try to leverage mediation where it makes sense.
  3. Where do you determine the service version – the mediation layer, the service consumer, or a service provider?
    Let’s handle the easy one. If you handle it at the service consumer side, you’re effectively saying that consumers must explicitly specify a version somehow. If this is the case, versioning effectively goes away, the explicit specification would treat a different version as if it were a different service. You could certain leverage a mediation layer and apply some transformations to send a V1 request to V2, but eventually you won’t be able to mediate for backward compatibility. If the version desired is not explicit, now we have to handle it through a mediation layer or at the service provider. My personal preference is to leverage the mediation layer for this routing. Otherwise, your service implementation will now be littered with logic to determine what version the request represents, map that to the appropriate implementation, etc. I just don’t think that belongs in code. That belongs in a policy repository. If you externalize this, the service developer can just focus on building services.
  4. Do you have governance models and policies around transitioning existing consumers to new versions? Who is responsible for executing that transition?
    Again, I’ve yet to personally see this in practice from an SOA standpoint. I have seen it put into practice from a shared infrastructure standpoint, however, such as rolling out a new version of an app server. Governance is critical. When the governance processes did not allow appropriate priority for these versioning efforts, it was a nightmare. It’s not just about funding for the upgrade, but it’s also about funding the impacted consumers and ensuring they have the resources to do their part. Second, the service provider must make it a consumer-friendly process as possible. Before that new version is ever put into production, the service team should have figured out exactly how their consumers will be impacted. In the infrastructure example, the team responsible for the app server worked with every single application hosted on the platform to make the process as painless as possible. They presented this approach when they requested funding for the effort, and the IT governance process made sure the impacted teams were onboard before it was approved. As a result, it went very, very smoothly. Planning these upgrades is tricky however, as unless things are properly coordinated and bundled, the entire IT project portfolio can get bogged on with independent versioning efforts. There does need to be some master planning over the whole portfolio.
  5. What is the most graceful way of “retiring” or “decommissioning” a service?
    If you’ve tackled the first question of how many versions, this shouldn’t be an issue. If you’re enforcing your policy, all consumers of V1 will have migrated to V2 or V3 before V4 goes in. V4 goes live, V1 is shut down. Of course, this is where management must come into play. Whether you perform authorization or not, all service requests must have identity attached to them. If you don’t, you’ll never know whether all the known consumers have migrated. There shouldn’t be any unknown consumers, and if there are, some process wasn’t followed long before this decommissioning effort. In addition to identity, you also need to know the usage profile. I had one consumer of a service that was only run once a quarter, as it was part of quarterly financial processing. If I relied on daily usage counts of 0 to judge when to decommission, this could be devastating for a consumer that is run once every 90 days.

I look forward to the day where these conversations are applicable to the mainstream. Clearly, there are thought leaders and some companies that are already facing these issues. The majority will be following in the future, so now is the time to start thinking about this.

2 Responses to “Revisiting Service Versioning”

  • Surekha Durvasula:

    Thank you Todd for sharing your insight on this topic of “service versioning”.

    I have a follow up question to the your comments on the topic of “the most graceful way of “retiring� or “decommissioning� a service?�

    You are right in suggesting that in a mature SOA environment which has the right type of governance policies and the right level of enforcement the topic of “graceful retiring of services� would be a non-issue. However, most of us enterprise architects find governance is a non-existant concept and enforcement a distant dream. So my questions relates to how we deal with “service versioning and decommisioning of services� in the mean time.

    I am wondering if the architecture concepts of Adapters and Interceptors could offer a possible solution to this problem. My hope is that these architecture constructs could be leveraged for transitioning “service consumer calls� with minimal intervention on the part of the service provider and without having to sacrifice the principle of loose-coupling by insulating the service consumer.

    An adapter could be created by the service provider or as an add-on to the service consumer architecture components and can be deployed on the service consumer address space to help overlay the service consumer message and to on-ramp the call to the most compatible version of the service provider without impacting the service consumer.

    On the other hand, an Interceptor can be deployed as a step in the service mediation flow to intercept non-compliant service consumer calls. The interceptor can transform the message payload or route the call to the appropriate service provider.

    In both these cases, and in keeping with the best practices mentioned by you in your comments, the use of these adapter/ interceptor components work if and only if the service consumer is not hard wired to the service provider version. The service consumer is best served if it is only responsible for creating a “proper message payload� that specifies a generic business function call and it encapsulates the right business context. In this type of a payload design the service mediator or other intermidiaries can map the business call and the message payload to the right service version.

    The limitation of this architecture pattern is that it assumes no addtional consumer related business context information is needed by the service provider in order to honor the call.

    Do you see any major issues with using this type of architectural intervention to overcome the lack of having the support of governance?

    Are there other integration and mediation patterns that help promote the concept of SOA?

    Thank you.
    surekha –

  • Personally, I don’t have any issues with the using mediation for this. There are some that may feel that you’re simply shifting the integration complexity into the mediation layer, and the management of it may be no better than if you had maintained many versions of the actual service itself. The vendors are well aware of this need and are continuing tuning their products to support this case better and better, so I believe it will be a viable option.

    The key factor to being successful with this, however, is going to be the team providing the service. This mediation layer is an extension of their service. If they change the underlying implementation and leverage mediation to achieve backward compatibility, the burden is on them to sufficiently test and prove it to their existing consumers. Nothing kills trust more than to tell that no changes are required, only to find out that’s not the case. I would encourage the service team, where possible, to be transparent about the change, and to do everything in their power to work with their consumers during the regression tests to show that they are on top of any problems that may arise, long before it ever reaches production.

Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.