Servicebeskrivelse som kontrakt og hvornår laver vi så indmaden?
- Oprettet Fredag, 27 april 2012 14:01
Serviceorienteret arkitektur har nogle gode principper.
Jeg og mine kolleger kan rigtigt gode lide kontrakt-aspektet af det. Ikke den juridiske kontrakt, men mere i betydningen tydelig dokumentation af hvordan vores aftaleforhold er; mellem udbyderen og brugeren af en Web Service.
Når vi selv eller vores samarbejdspartnere udbyder en service og leverer dokumentation - typisk WSDL og noget uddybende dokumentation - så giver det et godt grundlag at stå på for begge ender af samarbejdsforholdet.
Den ene ende ved hvad der skal leveres, og den anden ende ved hvad der skal forventes. Der er ikke så meget gætteri. Og der er ikke så meget med at ting ændres; ihverttilfælde ikke uden at begge parter er klar over det.
Men så er der noget sjovt omkring forholdet mellem "kontrakten" (dokumentationen og WSDLen) og så den indmad der skal levere det der er beskrevet i kontrakten. Hvad kommer først? Skal vi kode først og så dokumentere eller skal vi udfærdige kontrakten først og kode bagefter?
Der er fordele og ulemper ved begge modeller, og når vi selv skal levere servicen så er modellen typisk at vi er et sted midt imellem: Vi starter på at kode servicen, og når samarbejdspartneren ikke kan holde ventetiden ud længere leverer vi en "kontrakt" i en version 0.8.
Hvis kontrakten lægges fast tidligt så er der ikke så meget elastik til at lave ændringer smidigt.
Hvis kontrakten lægges fast sent så kan samarbejdspartneren ikke så let få ændringsønsker ind.
Når vi er service-brugeren oplever vi hele spektret af modeller. Dokumentation før kode og dokumentation efter kode, men den typiske er nu nok den samme som vi selv leverer: Samarbejdspartneren leverer dokumentation i næsten færdig version når servicen nærmer sig at være færdig.
Det sker så også at vi får udleveret "kontrakter" som ikke får den fulde indmad før lang tid efter at servicen er taget i drift. Det har vi for nyligt set i en service som har været i drift i over et år, men nu fik vi så brug for et hjørne af servicen som vi ikke havde haft brug for tidligere. Det førte til en periode med tavshed, lidt sjove emails og så dukkede indholdet pludselig op. Pudsigt.