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…

På den andre dagen, 9. september, lærte jeg litt om “Matching Engines”, om høye krav til ytelse og nøyaktighet og fikk virkelig innblikk i at tid koster penger, spesielt på nedetid.

Videre lærte jeg ikke så mye nytt om offentlige data. Synd at hele panelet utelukkende bestod av folk som ønsker fri tilgang til offentlige data, men ingen med myndighet til å kunne gjøre noe med det.

Så skulle jeg lære om hva jeg gjør feil med domenedrevet design (DDD), men foredragsholderen var forsinket, så jeg sneik meg inn på en sesjon om planlegging og å ta valg i utviklingsteam. Spesielt én ting fant jeg svært interessant, å premiere feiling for å oppmuntre til å ta sjanser og utfordre seg selv.

Videre lærte jeg hvordan man kan implementere Dungeon and Dragons i RESTful web services basert på prinsippene rundt HATEOAS, å bruke HTTP som motoren til å drive tilstand i applikasjoner.

Så lærte jeg at man må kjøpe Coherence for å bekjempe ytelsesproblemer i systemer. Et foredrag med stort preg av å selge inn Oracle-produktet, dessverre.

Så forvillet jeg meg inn på et foredrag om vedlikehold og utvikling av legacy-systemer.

Til slutt så fikk jeg med meg foredraget om domenedrevet design som ble satt opp. Greit å bli oppdatert på de mer vanskelige aspektene rundt denne teknikken, og selv om foredraget var kort så passet det egentlig bra som avslutning på JavaZone.

Nå er video av foredragene lagt ut på java.no. Har allerede sett noen lyntaler og lengre foredrag, og kan anbefale lyntalene om “97 things every programmer should know” og “Hjemmelaget er bedre enn takeout”, hvor begge lufter tanker om å kaste idéer og kode som blir for vanskelige å integrere eller som kommer i veien.

Selv så er jeg dårlig på å kaste kode, men jeg har i det siste kastet kode et par ganger, og selv om det gjør vondt der og da, så savner jeg ikke koden jeg skrev. Det er faktisk deilig å ikke ha uinnsjekket kode liggende over lengre tid.

Det jeg skal ta med videre fra JavaZone 2010 er idéene rundt HATEOAS og event drevet arkitektur. Sistnevnte har jeg allerede utforsket mye på fra før, og dette er motoren for å dytte data rundt i prosjektet jeg for tiden jobber på.

Jeg lærte i dag at hvis man plasserer en Map/Reduce-jobb hos Amazon, så tar det ca 30 ganger lenger tid å kjøre enn på en laptop.

Jeg lærte at hvis webappen din sliter under høy last mot eksterne ressurser, så legg inn sleep(1).

Jeg lærte at Collaborative Filtering kan være et spennende tiltak for å gi noe ekstra tilbake til brukerne.

Jeg lærte at det finnes mange tilnærminger til eventdrevet design.

Jeg lærte at Datalagringsdirektivet har forkjempere og motstandere som ikke alltid klarer å finne ut hvordan livets, trygghetens og frihetens vektskål skal balanseres.

Jeg lærte at RESTful ikke handler om XML og pene URL-er, men om å håndtere state mellom klient og tjener og at resten er bare hjelpemidler for å komme seg dit.

Jeg lærte at det finnes alltid et sikkerhetstiltak som man ikke har tenkt på eller ikke har forstått konsekvensene av.

Jeg lærte at Java har en tung vei å gå for å skape typeorienterte vaner.

Jeg lærte at man bør ha fulladet telefon før man drar på JavaZone.