IT-prosjekter handler ofte om å flytte og konvertere data mellom IT-systemer, i forskjellige presentasjonsformer og koble data fra flere datakilder.
Når man kjører flere slike prosjekter samtidig og over lengre tid med betydelig antall ressurser blir det aktuelt å tenke litt større og legge en strategi for hvordan informasjon skal flyte og behandles på tvers av organisasjonen.
Med modulbasert utvikling kan man utføre prosjekter med mange personer, gjerne delt i flere grupper. Det kan gjerne sees på som et bestiller- og leverandør-forhold, eller “klient og tjener”, hvor klienten definerer hva som forventes av den andre modulen å ta i mot og returnere av data og på hvilke formater utvekslingen skal foregå.
Moduler kan integreres i systemer via kompilatorlenking mot definerte grensesnitt, som funksjonssignaturer i et “interface” fra objektorientert programmering eller en “header”-fil, eller med meldinger som sendes på en meldingsbuss. Å binde seg til et definert grensesnitt har fordeler med at man kan få en kompilator til å sjekke gyldigheten av kontrakten, at man snakkes felles språk, men det gjør det vanskeligere dersom en av partene har andre behov og trenger å endre en funksjonssignatur.
Meldingsbasert integrasjon defineres på et høyere nivå enn ved funksjonssignaturer, for eksempel at grensesnittet bare definerer hvordan meldingen kan sendes og hvordan svaret kan mottas. Ulempen med meldingsbasert kommunikasjon er at det stiller høyere krav til validering, versjonering og bakoverkompatiblitet, siden en av partene kan oppgraderes til nyere versjon mens det finnes andre systemer som fremdeles snakker det gamle språket. Ved meldingsbasert kommunikasjon bør det skrives en spesifikasjon for formatet på meldingene, for eksempel i form av et XSD-skjemadokument dersom kommunikasjonen pakkes som XML-meldinger, eller Protocol Buffers hvis meldingene er mindre og tydelig definerte.
For enklere systemer holder det kanskje med et format på forespørsler ala: customer search 'ola normann' hvor “customer” kan være navnet på modulen, “search” kan være funksjonen i modulens grensesnitt og “ola normann” er parameteren til funksjonen. Responsen kan for eksempel være kolonne- og radbasert, som et regneark.
Mange muligheter!
Internett kan sees på som et modulbasert system. Veldig forenklet så kan nettleseren, altså klienten i vårt tilfelle, sende en forespørsel mot en adresse eller filsti til en webserver, altså tjeneren, som kan svare med et HTML-dokument. Det ligger en kontrakt til grunn om et felles grensesnitt som gjør at denne kommunikasjonen fungerer, og en slik kontrakt er HTTP-spesifikasjonen. Det er mulig å basere internkommunikasjon i sitt modulbaserte system over HTTP med for eksempel SOAP, Corba, REST, Thrift, for å nevne noen teknikker. Denne type meldingsbasert kommunikasjon har noen svakheter, blant annet krever det ekstra dataprosessering for å oversette objekter og datastrukturer til og fra meldinger som kan sendes over HTTP. Dette er også dens store fordel, da modulene kan lager i forskjellige programmeringsspråk og kjøre på forskjellige plattformer.
For å oppnå en smidig integrasjon mellom modulene trengs det presis og hyppig koordinering på tvers av utviklingsgruppene. Man må ta et steg tilbake for å få et overblikk over systemet som helhet.
Dette er i hovedsak en liten rant jeg skrev i 2011, og jeg mener den fortsatt holder vann – men ta den gjerne med en klype salt…