God SOA

Det har været en mærkelig uge. Jeg har læst to artikler om SOA, som fik mig til at tænke.

Den første artikel, var Computerworld's (ja, ja, og jeg læser også Jumbobøger - og hva' så?) artikel om, hvordan PFA selv mente at SOA havde gjort det muligt for dem at skifte leverandør med meget mindre smerte end ellers (jeg kender ikke CW's holdning til dybe link, så find den selv - den er fra 26. febr. og hedder "PFA-direktør: SOA sikrer nem fyring af mægtige CSC").

Artiklen beskriver, hvordan det at man har kunnet opbygge et grundlæggende antal services for forretningen, og så lade applikationerne tilpasse sig forretningen, fremfor som det klassisk set sker, nemlig at forretningen tilpasser sig applikationerne.

Og som så ofte, så er det mest interessante det, som ikke står der. Der står ikke et ord om teknik. Ingen "Enterprise Service Bus", ingen "WSDL", ingen "UDDI", ingen "MOM". Intet af alt det, som man ellers altid hører soft- og hardwaresælgere fra det store firmaer sige, er den magiske ingrediens i sovsen, som uden hvilken succes ikke vil være muligt.

Den anden var en knapt så konkret blog fra Kaare Kjelstrøm om spader og skovle, hvor han beskriver behovet for en fælles forståelse af domænet som forudsætning for kunne implementere fælles services. "Nåe ja", fristes man til at sige, "det vidste vi da egentlig godt (det havde vi bare lige glemt...)". Eller som Peter Nørregaard siger i en af kommentarerne til Kaares blog: "Hvis ikke det fungerer på papir, så kommer til heller til at fungere elektronisk."

Det fik mig også til at tænke over en af de overvejelser, som jeg i sin tid gjorde mig i min hovedopgave. Den handlede om objekt-orienterede databaser, som lige var ved at blive stort dengang, og der filosoferede jeg over sammenhængen imellem programmer og data:

Mit postulat var dengang, at vi var i den anden af 3 faser (og - mente jeg - lige ved at komme over i den tredje):

Første fase var dengang, hvor programmer og data havde været rodet ubehjælpeligt sammen, så hver program havde sine egne data, og kun programmet selv kunne forstå dem.

Anden fase var, at databaser havde gjort det muligt for data at blive frigjort fra programmerne og blive delt på en abstrakt og generelt tilgængelig form.

Til gengæld, så savnede jeg dengang, at det som jeg kaldte "viden om data" blev frigjort fra programmerne - at vi kom ind i det, som jeg så som den tredje fase. Dvs. at de datanære forretningsregler - som f.eks. at debet og kredit skal stemme i en postering - kom til at følge data. For nok var data delt, men forståelse og håndhævelse af forretningsreglerne lå stadig spredt ud over de forskellige programmer, med alle ulemperne ved redundans. Men data og forretningsregler kunne jo kombineres i forretningsobjekter. Tanken var så, at applikationerne ikke skulle operere direkte på data, men i stedet på forretningsobjekter.

Nu vil jeg ikke påstå, at jeg forudså SOA dengang, for det var jeg slet ikke fremsynet nok til - faktisk så mente jeg dengang i høj grad, at det var de objekt-orienterede databaser, som var det der skulle redde os. Historien har alt for tydeligt vist, at det var forkert - det er alt for detajlenært og slet ikke omfattende nok. Man genbruger ikke objekter - næ, vi skal helt op på service eller komponent niveau, før genbrug virkelig kan give mening.

Så måske er SOA løsningen? Det har i hvert fald større potentiale end objekt-orienterede databaser...

Hybrid versionsstyring

Jeg har før blogget lidt om distribueret versionsstyring (DVCS), og her kommer lidt mere.

En af de store fordele ved at have en decentraliseret opfattelse af versionshistorikken er, at man ikke har alle sine æg i en kurv. Et centralt repository kan være mere eller mindre utilgængeligt, og har man prøvet det, så ved man hvor fortabt man føler sig. Det kan være så alvorligt, at man skal til at have fat i backuppen, selvom det heldigvis er yderst sjældent. Men det kan såmænd også være noget så simpelt, som at man er udenfor rækkevidde (ja, det kommer nok som et chok, men det er faktisk stadigt muligt at finde steder, hvor der ikke er nogen form for netadgang!).

Skulle man så være helt uden mulighed for at kigge i historikken - eller for at kunne checkpointe udviklingen undervejs med velplacerede commits? Nej vel. Og her kommer distribueret versionsstyring virkelig til sin ret. Og der er jo ikke noget som forhindrer en decentraliseret struktur i netop at have struktur, og derfor i at have et repository, som er mere lige end alle de andre.

Men hvad nu, hvis der allerede er truffet en klog og velovervejet beslutning om at bruge f.eks. Subversion? Er man så tvunget til hele tiden at være online for at få det fulde udbytte?

Ja, i princippet, og så alligevel ikke. For der er jo som udgangspunkt ikke noget som forhindrer en i at versionsstyre de samme filer i to forskellige versionsstyringssystemer, som f.eks. Subversion og Git. Så ville man kunne have en offline historik, offline commits og alligevel kunne koeksistere fredeligt med de andre brugere af det centrale repository.

Dvs. ikke ud over, at det bliver et koordineringsmæssigt mareridt. F.eks. skal ændringer fra det ene skal committes manuelt i det andet.

Men heldigvis er der andre, som har fået samme tanke. Det er f.eks. lavet en integration imellem Git og Subversion med titlen git-svn. Er man mere til Mercurial, så bør man nok holde øje med hgsvn, selvom der vist stadig er plads til forbedring der.

Hvis man kaster sig ud i hybrid versionsstyring af denne slags, så husk at det ikke skal være for at kunne styre at lave sjældne monster-commits - der skal stadig committes de samme sammenhængende klumper af funktionalitet så ofte som praktisk muligt. Når det er interessant, så er det for at dels at kunne arbejde offline, og dels for at kunne lave lokale commits - commits, som ikke behøver være så afrundede eller komplette som ellers - ja, faktisk behøver de slet ikke kunne compilere, og som derfor kan ske undervejs - og ikke først når man er helt sikker på at være færdig.

Giv mig en anden virkelighed

To history, choices are merely directions. The Trouser of Time opened up and Vimes began to hurtle down one leg of them. And, somewhere else, the Vimes who made a different choice began to drop into a different future.

Terry Pratchett: Jingo

Jeg har før skrevet om versionsstyring, og dengang forholdt jeg mig mest til det paradoks, der er i, at en merge-strategi som oftest er en låsestrategi overlegen - også selvom det umiddelbart føles forkert. Denne gang vil jeg dykke lidt mere ned i branching, som mange har et had-kærlighedsforhold til (de fleste endda uden ret megen kærlighed...). Og det er egentlig både synd og uforståeligt.

Lad os starte med at slå fast, at vi gør det hele tiden:

Branching er det, hvor man fastfryser virkeligheden, og arbejder sig ud i en alternativ retning.

Når vi tager en fil ind i en editor, så gør vi det samme - vi skaber en lille alternativ virkelighed, som kun eksisterer i vores editor. Gode editorer lader os måske endda sammenligne med det, som var vores udgangspunkt, nemlig det som stadig ligger på det eksterne lager. Avancerede brugere vil endda kunne editere flere filer på en gang. Denne lille "branch" består indtil vi vælger at gemme vores ændringer - indtil det punkt har vi faktisk en reelt mulighed for at fortryde.

En anden almindelige måde at lave en lille "branch" på, er at tage en kopi fra et fælles netværkdrev, og så arbejde på kopien et stykke tid. Herefter kan man vælge at lægge kopien tilbage igen (eller lade være).

I de fleste versionsstyringsværktøjer har hver bruger sin egen arbejdskopi, og vælger selv hvor tit denne arbejdskopi skal bringes i sync med repository. Samtidig kan brugeren have sine egne ændringer, og dermed sin egen virkelighed, indtil det tidspunkt, hvor brugeren beslutter sig for at flette ændringen ind i den egentlige version i repository. Her er også en lille tidslomme.

Vi har hele tiden brug for at lukke døren til virkeligheden - at melde os ud for en kort bemærkning - imens vi laver vores arbejde uden at blive forstyrret af den flux, der er omkring os. Og også brug for at kunne eksperimentere uden at forstyrre vores omverden. Varer det længe nok, så bliver vi nødt til at en gang imellem at åbne døren og bringe os selv up-to-date med, hvad der er sket omkring os. Når det har stået på længe nok, så vil vi på et tidspunkt åbne døren igen og åbenbare vores resultatet af vores omverden.

Sådan er det også med branches. Bare i en større målestok, og noget mere formaliseret. Men rationalet, udfordringerne og effekten er den samme.

Der er to store beslutninger, som følger med beslutningen om at branche.

Når man brancher, så skal man gøre sig klart dels, om man vil vende tilbage, og i givet fald, hvordan og hvornår.

Selvom man godt kan forestille sig, at man laver en branch, for at gå i en helt anden retning uden noget behov for nogensinde at kigge sig tilbage igen, så er det som oftest ikke tilfældet. Som oftest, så er det man laver, en ændring, som giver god mening - man skal bare lige have fred til at gennemføre den. Og i så fald skal man overveje, hvordan man kommer tilbage.

Den første overvejelse er, hvordan man kan skal håndtere, at andre kan have ladet udviklingen gå i en anden retning imens. Versionsstyringsværktøjer vil hjælpe os med dette i en vis udstrækning, men specielt i de to første eksempler, hvor vi bare havde en lokal kopi som vi kopierede tilbage igen, vil der klart kunne opstå en konflikt, hvis ikke man er omhyggelig.

Risikoen for konflikter stiger med tiden, så en god strategi er oplagt ikke at bruge for lang tid inden afslutter sin branch.

Overvej, hvordan man kan holde sig opdateret undervejs.

Det er klart, at jo længere man har været væk, jo sværere bliver det at komme tilbage. Modtrækket imod dette er at lægge en strategi for, hvordan man løbende holder sig opdateret.

Det koster helt klart tid og kræfter, så det er ikke noget, som skal gøres for tit. På den anden side, så skal man heller ikke vente for længe, for så stiger prisen ved at være ude af sync for meget.

_________

Her burde et være klart, at branching dels ikke er noget magisk, men derimod noget som vi helt naturligt foretager os, og dels at det først for alvor bliver besværligt, når vi lader det løbe for længe. Der er tre altså store udfordringer i det: At starte det, at håndtere det undervejs, og at afslutte det (doh!).

Opstarten vil jeg ikke sige så vanvittigt meget om. Der er flere former for best practice for det - for en grundig oversigt se f.eks. denne Branching and Merging Primer, som oplister ti typer af branches, fem strategier for branching og en pæn mængde antipatterns.

Selv har jeg med rimelig succes talt for en kombinationsløsning imellem clean og dirty trunk. Som udgangspunkt sker udviklingen på trunk, men ikke andet end hvad der stadig med rimelighed kan nå at komme med i næste release. Når denne nærmer sig, så branches der ud i en releasespecifik branch, som så får lov at stabilisere sig. Tilsvarende vil aktiviteter, som rækker længere ud end næste release blive sendt ud på featurebranches. Man vil kunne se, at dette er meget stærk inspireret af afsnitttet Common branching patterns i online bogen Versioncontrol with Subversion.

Afslutning vil jeg her faktisk slet ikke sige noget om, udover det lidt som allerede er sagt. Så resten af dette indlæg går med at snakke om det "ind imellem".

Det burde nu være klart, at det vigtigste ved det "ind imellem" er, på en kontrolleret måde at holde sig opdateret med det, som sker omkring en. I eksemplet med en lokal arbejdskopi af et fælles repository er det rimeligt simpelt, i det at værktøjet går langt for at hjælpe en. Man skal bare finde en passende rytme for at holde sig opdateret, så skal det nok holde styr på, hvilke opdateringer man har brug for, og om de evt. skulle konflikte med det, som man nu har gang i.

For de mere manuelle eksempler er der ikke andet at sige, end at man må håbe på det bedste, og så ellers holde tungen lige i munden.

For "rigtige" branches i versionsstyringsværktøjer, findes der fine beskrivelser af best practice for håndtering af, hvordan bogholderiet ifm. f.eks. succesive opdateringer skal håndteres. Det lyder besværligt og bureaukratisk, og det er det faktisk også. Se f.eks. ovenstående bog om Subversion - der er der fint beskrevet. Og mon ikke at det er dette bogholderi, som er pæn del af grunden til at branches er blevet lagt sådan for had?

Men der er i hvertfald to ting, som for nyligt at kommet til min opmærksomhed, som vil lette denne byrde mærkbart:

Den ene af disse er, at der i næste version af Subversion kommer noget som de kalder "merge tracking" (det er scheduleret til version 1.5, og i skrivende stund er den aktuelle version 1.4.6). Her lover subversionfolkene, at de vil hjælpe os med bogholderiet vha. snedige markeringer i metadata, så alt hvad vi skal gøre er, med jævne mellemrum at skrive "svn merge". Se f.eks. Subversion: Merge Tracking og Merging og branching in Subversion. Udover problemstillingen med succesive merges, så skulle det kunne håndtere "cherry picking" (dvs. merging af udvalgte ændringer alene) og tilbagerulning at merges uden at blive forvirret. Se det er efter min mening grund nok til at skifte til Subversion, hvis man ikke allerede har gjort det! At have branches og at holde dem opdateret, burde da ikke blive mere omstændeligt end at have lokale arbejdskopier og holde dem opdateret i forhold til det fælles repository - og dermed er en stor administrativ byrde fjernet.

Den anden ting er et markant brud med det grundlæggende vilkår ved branches, at man skilles på et bestemt punkt, og at dette punkt som udgangpunkt ligger fast. I værktøjet AccuRev erstatter man begrebet branches med et andet begreb kaldet streams. Tanken er, at man baserer streams på andre stream - det som vi vil opfatte en som branch, vil være en stream baseret på trunk. Men en stream ligger ikke fast - den er så at sige transparent alle de steder, hvor der ikke er lokale ændringer. Det betyder, at sker der ændringer i de stream, som en given stream baserer sig på, så vil man få disse ændringer med næste gang man opdaterer. Når man er klar, så kan man sende sine ændringer op til den overliggende stream, og så fremdeles, hvis der er tale om flere niveauer af streams. Se evt. mere i Streambased architecture for SCM.

Det er efter min mening et yderst interessant alternativ, da det umiddelbart ser ud til, at man her helt kan undvære at skulle merge imellem branches undervejs. Om man kan håndtere den "støj", som det vil være altid at få alting med, kan jeg ikke overskue - og det betyder i hvertfald at der er en lang række af vores etablerede mønstre for brug af versionsstyringsværktøjer, som skal gentænkes.

Jeg håber at jeg her har fået afdramatiseret brug af branches lidt, så flere nu tør give sig ud i at branche, hvor det giver mening. Vedr. citatet i indledningen, så kan jeg fortælle at de to Com. Samuel Vimes formår at få fat i den andens "disorganiser" (en "disorganiser" svarer nogenlunde til vore dages PDAere). Resultatet er ganske mange forviklinger, bl.a. at "vores" Vimes på et tidspunkt får reminders om sit alternative jegs begravelse. Parallelle virkeligheder er forvirrende - hold jer fra det i større målestok!

Pinligt

Her den anden morgen holdt jeg for rødt i et stort vejkryds, hvor jeg skulle til højre. Fra den modsatte retning kommer der en ambulance med fuld udrykning. Da den nærmer sig krydset, så skifter det til grønt.

Jeg bliver selvfølgelig holdende for lige at afvente, hvad han vil - man giver vel plads til udrykningskøretøjer, ikk'? Men der går ikke engang tre sekunder, så begynder ham omme bagved gud-hjælpe-mig at dytte af mig!

Pinligt! Mon ikke han har siddet tilbage med noget temmeligt røde ører, da han endelig opdager ambulancen?

I øvrigt skulle ambulancen selv til højre, så vi kom hurtigt videre - tabet var nok alt i alt på 10 sekunder for vores vedkommende.

Vinterpause?

Jeg har før sagt, at nu er vinteren kommet, men min have er ikke enig med mig. Den er begyndt at tage forskud på foråret, og det pibler op med forårsblomster overalt.

Udover de blomster, som er der billeder af her, så er vi begyndt at se liljer og tulipaner skyde, selvom de selvfølgelig ikke er kommet så langt. Bare det nu går godt.

I sidste weekend var vi selv i haven med beskæresaksen. En vittig nabo ville vide om det var en meget sen efterårsklargøring eller en meget tidlig forårsklargøring? Der var nok mest gået forår i os lige som med haven, men det var nu mest hverken eller. Det er sandt, at vinteren i høj grad er hviletid for haven, og specielt græsplanen skal have ro (det også bare noget værre sump, når man har lerjord som her).

Men derfor er der nu stadig noget at lave. Beskæring kan i princippet ske året rundt, bare man holder sig fra perioden, hvor alt vågner om foråret (det er klart at et saftspændt træ er meget sårbart), og tilsvarende holder sig fra perioden om efteråret, hvor alt forbereder sig på vinterpausen (beskæring stimulerer nyvækst, og sker det for sent, så kan det ikke nå at etablere sig inden vinteren).

Vinen fik derfor sin vinterbeskæring, og frugttræerne har også fået en tur (minus stenfrugterne, som min havebog anbefaler at man sommerbeskærer aht. faren for svampeangreb). Den sene et-årige hindbær blev skåret helt ned (det var vist det med den sene efterårsklargøring, som nok ikke helt nåede ud i krogene), og jeg fik skåret sommerfuglebusk og lavendel ned (og så er vi mere ovre i den alt for tidlige forårsklargøring, men der var markeringer til knopper, så jeg vil mene at der er gode chancer for at jeg har ramt rigtigt med saksen).

Vildnisset ud imod den store vej skar vi ned i et par meters højde for en tre års tid siden - det er nu nået op i noget der ligner fire meter, og derfor skal det have en tur mere. Det sker også nu, dels pga. at der er hvileperiode, så træer og buske har bedst af at der sker nu, men også af hensyn til de dyr og fugle som ellers har det som fristed om sommeren. For taler også, at det er meget nemmere at se, hvor man skal save og skære, når der ikke er nogen blade på træerne - jeg skal dog hilse og fortælle, at torne fungerer glimrende som forsvar hele året rundt.

Men når dagene er korte og vejret omskifteligt, som det er nu, så når man ikke så meget. Og det egentlig ikke så skidt...