In our Community of Practice's Open Forum, Brenda Michelson shared some comments from CIOs and CTOs on managing SOA environments:
During our February Executive Summits, the CIOs and CTOs expressed concern that there aren't ITIL-like practices and guidelines for managing a SOA based environment.
A specific question was "How many versions of a service should be in production at once?" The group stated that "It was naive to believe only one version of a service would be live". But, how many is too many?
Brenda then asked our COP:
What are SOA-C members doing in their organizations? How many versions are active? How many versions are manageable? What are your version limits and practices?
I agree that service versioning is inevitable and must be managed. In this post I'd like to share my response to Brenda's question. I focused on "when and why" to version. At the end, I have some questions for the broader SOA community.
Before I continue, I should introduce myself. I am Surekha Durvasula, Enterprise Architecture Manager for Kohl's and the Leader of the SOA-C's Executing Business-Driven SOA Strategy.
My Service Versioning Perspective
In the broadest sense, there may be two key reasons to support business service versioning.
A) Consumer SLA/ QoS driven
B) Business functionality or business policy driven
Consumer SLA driven service versioning could be supported by just altering the values on the envelope. The envelope level metadata can be used to direct a call from the mediation layer (read ESB) to the appropriate service provider end point. Here the consumer can provide the values for the SLA metadata or a metadata lookup activity for the service consumer can be performed by the mediation layer.
Examples of the Consumer SLAs could be greater audit, more stringent response times, tighter security needs etc. Here the service interface layer may not have to be altered and so the consumer may not be affected. However, the service provider implementation layer may have to support multiple service implementation end points that are in keeping with the QoS requirements.
Business Functionality driven service versions are typically impacted by service interface and/ or the payload level changes.
Here the consumer has to "know" how to construct the new payload and may need to "indicate" to the mediation layer the right business service to invoke. Given this behavior change on the consumer side, service versioning becomes a necessity to insulate existing consumers. One way of limiting the number of service versions being supported may be to leverage the service mediation layer to populate default values on newer payload parameters or to perform payload transformation. The mediation layer can invoke utilities/interceptors on behalf of the service consumer to absorb the impact of changes to the interface or the payload. However, in scenarios where no valid default values are available or else if new consumer context information is required on the payload then a new version of the service would need to be published, thus requiring the enterprise to have to support multiple service versions.
Other considerations for supporting service versioning include management and monitoring costs, efficient use of IT resources, regulatory and central governance policies and the stringency of the contract agreements with the consumers.
Service Versioning Discussion Questions
1. How many versions of a service should be "live" at any given time? How many versions are too many?
2. Do you use the service mediation layer to achieve backward compatibility?
3. Where do you determine the service version - the mediation layer, the service consumer or a service provider?
4. Do you have governance models and policies around transitioning existing consumers to new versions? Who is responsible for executing that transition?
5. What is the most graceful way of "retiring" or "decommissioning" a service?
Please share your comments on this post, your own blog with a trackback, or via email to blog at soa-consortium dot org
Surekha, I posted answers to your service versioning questions on my blog. -tb
Posted by: Todd Biske | August 11, 2007 at 11:43 AM