Har du helt styr på protokolhåndteringen, når du udvikler services?
Når man udvikler services, sker det desværre alt for ofte, at man uforvarende får syet jakken fast i huden.
En gammel talemåde, der jo illustrerer, at protokolhåndtering skal varetages i et tyndt lag. Og hvad vil det så sige?
Dine services skal gøres tilgængelige
Udvikling af services skal altid tage udgangspunkt i det forretningsmæssige behov (det har vi tidligere underholdt lidt om i det her indlæg) – og så skal dine services selvfølgelig gøres tilgængelige på en eller anden måde. Det sker i reglen med dagens mainstream protokol; i forgårs var det CORBA, i går SOAP services, i dag REST, lige om lidt måske gRPC – og i morgen er det nok noget, vi ikke kender endnu.
Men uanset hvilken protokol, der giver mest street credit hos de yngre kolleger og hitter på StackOverflow, så skal man holde sig for øje, at substansen – det forretningsmæssige – ikke ændres bare fordi, der kommer en ny måde at snakke med servicen på. Og nu kommer vi til det med jakken…
Protokolhåndteringen skal varetages i et tyndt lag
Den forretningsmæssige service skal ikke ændres, bare fordi man skifter protokol. Derfor skal protokolhåndteringen varetages i et tyndt lag, der let kan udskiftes eller suppleres uden behov for at ændre på implementeringen af forretningslogikken.
Det er et fint eksempel på Single Responsibility Principle, der lidt forenklet siger, at der kun må være én årsag til at ændre i en komponent: Skal servicen udstilles med en ny protokol, skal der ikke ændres i forretningslaget – og en ændret implementering i forretningslaget skal ikke ændre på, hvordan data transporteres.
Lidt på samme måde som, at behovet for at skifte jakke eller tage en ekstra trøje på helst ikke skal give bekymringer om, hvorvidt huden nu kan holde… ?