Versionshantering av tjänster

När man börjar bygga upp SOA-arkitekturer är det vanligt att man inte tänker på versionshantering av tjänsterna. Och det fungerar ett tag. Sedan får man stora problem när de första tjänsterna behöver uppdateras eller bytas ut. Eller för att citera IBM:s Greg Flurry: "Change happens.", "Change is painful."

IBM har gjort ett arbete för att ta fram en fungerande modell för versionshantering. Den bygger dels på teori, dels på erfarenheter från några kunder. Modellen är uppbyggd kring begreppet servicespecifikation (service specification). Specifikationen är indelad i fyra delspecifikationer, beteende, interface, interaktion och drift.

Servicespecifikationen versionshanteras, delspecifikationerna versionshanteras inte separat, utan versionsnumreringen följer servicespecifikationen oavsett om en vis delspecifikation uppdaterats eller inte. Versionsnummer består av major.minor. Man börjar alltid på version 1.0, för varje bakåtkompatibel version ökas minor-komponenten (t ex 1.0 till 1.1), om bakåtkompatibiltet saknas för en uppdatering ökas major-komponenten (t ex 1.0 till 2.0).

För riktigt stora ändringar skapar man en helt ny service. Det är ett fall som IBM:s modell inte täcker. Den nya servicen har, versionsmässigt, inga band till den gamla.

Det finns ett betydligt större djup i modellen än vad jag kan ta upp här, men skriv gärna en kommentar om det verkar intresant, så ska jag se om jag kan leta upp några resurser i ämnet.