DISQUS

Hei igjen,
Det er disse "mange måtene å gjøre ting på" som jeg i bunn og grunn vil til livs. Har man en tjeneste utviklet av en organisasenhet som er eksperter på området og driftet og satt opp på passelig vis (teknologi X, runtimemiljø Y) og sagt at man garanterer at denne kan nås på 10 forskjellige vis (fra det som var "in" i 1997 til den metoden det blogges mest på og om i nov 2008) - og hver av disse 10 måtene kan på klientsiden implementeres på 10 vis (versjoner av xsd->java biblioteker nevnt, ingen andre glemt) da har man som tjenesteleverandør gitt seg selv et større problem enn om man går for en standard man kan anta de fleste er i stand til å forholde seg til. Man må gjøre noen valg.

SOA *mellom* applikasjoner og SOA *inni* applikasjoner: hva menes egentlig her? Har sett en del prosjekter opp gjennom som har vanskelig for å se verdien av å dra businesslogikken sin ut av klienten og ned i en tjeneste og behandle disse som helt adskilt. Man deler gjerne opp i ulike moduler/prosjekter/jarfiler - man ser at klient og tung forretning er to forskjellige ting - men man kvier seg for å ta det "store spranget" : se på dem som to helt adskilte "ting". Grensesnittet blir gjerne deretter - og ikke bare-bare og gjøre om til rene tjenester på et senere tidspunkt. Om man ikke har en klient 2,3,4,5,10 eller 20 i pipelinen som trenger tilgang til logikken i forretningsmodulen (og da gjerne også fra en annen teknologi) så er dette, som tidligere nevnt, ikke et problem. Det er der man har eller kan forventes å ha et mer komplekst bilde som er caset.

Man kan sikkert løse dette på mange vis. Og komme innenfor en SOA-definisjon. Men dette er etter mitt syn det minst viktige. Det er når man konkretiserer SOA - hvordan har vi i praksis tenkt å løse dette her oss oss (hvilke metoder, hvilke verktøy, hvilke teknologier, hvilke standarder, hvilke rammeverk, hvilke måter å kommunisere på, hvordan setter du opp en klient korrekt, hvordan lager du en tjeneste som er interop, ...) - arbeidet og valgene ligger.

Å "gå for alt" eller la være å bli konkret (som i praksis vel gir det samme resultat) vil så vidt jeg kan forstå skape mer teknokos enn forretningsnytte. Og endeløse kriger om hva som til enhver tid er best og mest framtidsrettet.

Det koker kanskje ned til å hindre at det utvikles 10 tykke klienter av den teknologiuavhengige typen: de på 100 mb med 20 forretningskomponenter som kontakter 40 systemer rundt om kring i organisasjonen. At hver av disse klientene heller er 5 Mb tynne og kontakter 20 tykke tjenester for å oppnå det samme (eller er det her vi er uenige?). Og at måten man velger for å oppnå dette bankes og settes ut i live - og det krever konkretisering, spesielt i utviklingsmiljøer med større kompetanse på fag enn teknologi.

Om "SOA = SOAP + en del passende teknologier"? Liker ikke å banke noe i stein og si at slik må det være de neste 10 år - mitt krav er enkelhet på klientsiden og det *soleklare* skillet mellom klient og tjeneste. Per aug 2008 fungerer de delene av WS* stacken vi har forsøkt oss på over den protokollen vi har forsøkt oss på (HTTP) - men desto mindre homogent vi gjør det desto mer trøbbel får vi. Jeg trodde en gang at vi så langt inn på 2000-tallet som vi faktisk er kunne velge et gitt open source WS-rammeverk og da automatisk vite at alle varianter av klienter umiddelbart ville kunne ta i bruk denne tjenesten uten noe mer hassle. Men vi er ikke der, så vidt jeg kan se, og må være ganske så bevisste hva vi tillater både på klient- og tjenerside: utviklerne har ikke frie tøyler til å laste ned det til enhver tid mest bloggede produktet.

Plain HTTP og XML har jeg ikke så mye i mot - det fungerer. Men man mister jo noe: soap-header/sikkerhetsstandardisering og verktøystøtte (klientgenerering, soap-ui) og for alt jeg vet også andre ting vi ikke vet at vi trenger enda. Å lage sitt eget opplegg er sikkert greit så lenge man er in-house, men om man vet at man før eller senere skal "snakke med" partnere så kan man ikke legge fram sin egen greie og forvente særlig gehør.

Man kan altså fint klare å skjelle ut SOA om man legger fram et case der man aldeles ikke trenger å skille klart mellom klienter og tjenester eller der man definerer SOA som "webservices" med tilhørende tung ws*stack og egentlig aldeles ikke trenger noe mer avansert enn XML/HTTP.

SOA som "konsept" koker for meg ned til enkelhet på klientsiden og et klart skille mellom enkle klienter og tunge/komplekse forretningstjenester. Akkurat hva man bruker for å la disse to snakke sammen vil det sikkert være en annen best practise på om fem år enn i dag - uten at det etter min mening undergraver SOA som sådan.

SOA kan sikkert lett angripes om man googler seg fram til de mest vidløftige vyene av folk som aldri har programmert - og så tar for seg disse personenes utsagn.

Men om man koker det ned til slik en utvikler opplever det - de å enkelt (ja, enkelt) kunne kommunisere med et hvilket som helst system uten å i det hele tatt tenke på hvordan det systemet "ser ut" arkitekturmessig / infrastrukturmessig / produktvalg / innkjøpt eller hjemmesnekret / agile eller fossfall / Per eller Kari / gammelt eller nytt er *veldig* behagelig når man får muligheten.

Og fungerer ikke tjenesten da er det ikke min feil - det er vedkommende som laget tjenesten og har lovt at den skal se slik og sånn ut og har lovt oppetid på X.

Så da ender man opp med at klientutviklere kan konsentere seg om klientting - samt få til det å sende inn og motta/forstå en retur. Og tjenesteutviklere kan konsentere seg om å få tjenesten til å snurre så godt som nødvendig - med den arkitektur og maskin- og programvare som måtte være best egnet til det.

WS* eller ikke WS*? Er skuffet over utviklingen og manglende interoperabilitet - man må kjempe. Men dette virker mer å være en bransjesykdom - hver mann sitt produkt eller rammeverk - og da blir det så som så med hensynet til helheten: ikke noe veldig spesielt for SOA. Men å hoppe bukk over standardene som finnes og lage "mitt eget" ville jeg ikke vurdert - det får da være måte på til magemål.

Så: SOA for meg er først og fremst forenklet infrastruktur og det å gjøre livet enklere både for tjeneste- og klientutviklere: man har sin greie og slipper å tenke på og bli belemret med alle andre sine greier. Men om man i sin IT-hverdan sysler med ett produkt og har kontroll fra øverst-til-nederst og alt kjører/kan kjøre på samme boks da er det jo ingen grunn til SOA så vidt jeg kan forstå. Erfaringnene ovenfor er gjort med utgangspunkt i en organisasjon med en del ulike teknologivalg gjort gjennom flere år og der man ikke ser seg tjent med å fase ut noen av dem - heller putte inn enda flere.

Og da er det synd på klientene som får i oppgave å kommunisere med alt og alle.