Fire påstander om SOA

June 14, 2008

This article is a Norwegian-language version of my article Four bold claims about SOA. Dette er et utkast til en artikkel jeg ønsker å få publisert. Jeg setter stor pris på tilbakemeldinger om uklare tanker og formuleringer.

To av de vanskeligste problemene vi møter innen programvareutvikling er integrasjon og det som gjerne kalles “business-IT alignment” eller forretningsorientering, altså: IT skal understøtte virksomhetens strategiske mål.

Tjenesteorientert arkitektur, eller Service Oriented Architecture (SOA), hevder å kunne løse begge disse problemene. I det siste har jeg forsøkt å lytte mer aktivt til påstander fra evangelister av SOA, og jeg begynner å få en forståelse for hva det er SOA foreslår som løsningen på problemene vi står overfor. Dette er min oppfatning av påstandene om hvordan SOA skal løse problemene med integrasjon og forretningsorientering:

Web service-standarder vil løse de tekniske integrasjonsproblemene (“WS-stjerne-påstanden”)
Å sentralisere integrasjon via ett knutepunkt vil løse de organisasjonsmessige utfordringene rundt integrasjon (“ESB-påstanden”)
Å modellere funksjonalitet som en arbeidsflyt mellom tjenester vil gi oss bedre forretningsorientering (“BPM-påstanden, del 1”)
Å kunne restrukturere arbeidsflyten mellom tjenestene vil gi oss en en smidig forretningslogikk (“BPM-påstanden, del 2”)

Jeg håper at SOA-evangelister kjenner seg igjen i disse påstandene og er enige i at disse påstandene er sentrale når det gjelder SOA. Men jeg tror evangelistene vil være uenige i min vurdering av påstandene om SOA. Forretningsorientering og integrasjon er svært viktige og vanskelige problemer. Dersom påstandene om SOA skal holde mål, betyr dette at problemene er unødvendige, at de er unngåelige eller at de tekniske og designmessige verktøyene SOA gir oss kan abstrahere vekk kompleksiteten. Dette er en uvanlig vågal påstand. Og etter min dømmekraft, en usann påstand. Min erfaring er ikke så bred som den til mange SOA-evangelister. Jeg har erfaring med et fåtall organisasjoner og et fåtall systemer. Men de systemene jeg kjenner, kjenner jeg svært godt, og

Systemer ser svært forskjellig ut på nært hold og når man ser dem fra 30 tusen fot.

Når jeg har jobbet med systemer som består av web services, er min erfaring at standardene på dette feltet har vært langt fra å løse de tekniske integrasjonsproblemene. Å splitte et system opp i distribuerte komponenter øker antall feil og kostnaden ved å utvikle systemet, selv i de tilfellene der de to tjenestene kjører på samme plattform. Dersom man ønsker å integrere Java-løsninger med .NET-løsninger, er ting mye verre. Kanskje utvikling og testing av distribuerte systemer ville vært enklere om vi bare hadde hatt de rette verktøyene? Eller kanskje ikke. Når vi integrerer to systemer, er de tekniske utfordringene små sammenlignet med de organisasjonsmessige utfordringene: “Når kan du utføre den endringen vi trenger?” Hvordan tester vi integrasjon mellom systemene? Hva er ytelsen, robustheten og påliteligheten til tjenesten jeg integrerer meg med? Slike spørsmål må besvares for hvert integrasjonspunkt. Når man ser på de organisasjonsmessige problemstillingene, er integrasjon alltid et bilateralt problem, selv når de tekniske problemstillingene er løst multilateralt. Kanskje problemene ville forsvinne dersom vi bare skjuler dem i en sentral komponent? Programvareutvikling er forskjellig fra en samlebånd på en fabrikk. I de systemene jeg kjenner, er 99 % av den funksjonaliteten man har utviklet kun brukt én gang. Enkeltsteg i use cases eller andre kravbeskrivelser er sjelden gjenbrukbare. De er altfor avhengige av konteksten de brukes i. Ettersom funksjonaliteten essensielt er avhengig av konteksten, vil en utvikler som befales å ignorere denne konteksten etter min erfaring gjøre en dårligere jobb, fordi utvikleren vil tolke kravene til det som skal lages for bredt. Kanskje vi bare trenger en bedre måte å uttrykke kontrakten til det som skal utvikles på? Fleksibilitet gjør en løsning mer kompleks. Aldri er dette så sant som når fleksibiliteten er oppnådd ved å distribuere delene av systemet. Personlig har jeg aldri vært flink til å vurdere hvilken fleksibilitet som er nødvendig, og hvilken fleksibilitet som jeg kun inkluderer for å tilfredsstille mitt tekniske ego. Men det jeg vet er at det er vanskeligere å teste fleksible, distribuerte systemer. Så feedback i prosessen blir blokkert av tekniske valg. Og min erfaring er at feedback er den eneste måten vi kan få en mer smidig forretning. Kanskje dersom verktøyene våre var bedre, så ville vi være i stand til å utvikle, teste, versjonshåndtere, driftsette og endre distribuerte systemer uten å sabotere feedback?

Kan grunnleggende kompleksitet abstraheres bort?

Til syvende og sist tror jeg svaret på alle disse spørsmålene blir “nei”. Å legge til teknologier og verktøy løser sjelden problemene våre. Mer avanserte programmeringsspråk lot oss løse vanskeligere problemer, fordi de lot oss abstrahere oss vekk fra teknisk, irrelevant kompleksitet. Nyere verktøy som for eksempel Object Relation Mapping som Hibernate gir oss en kraftig brekkstang til å løfte tunge løft, men vi kan ikke bruke denne type verktøy effektivt og trygt dersom vi ikke skjønner både databaser og selve verktøyet godt. Avanserte verktøy kan gi oss større effekt, men de er også vanskeligere å forstå. Vil WS-, ESB’er og BPM være verktøy som vil være i stand til å skjule kompleksiteten i problemene de forsøker å takle, eller vil de kun gi oss mer kraft når vi forsøker å løse disse problemene? Og hva vil være kostnaden av denne kraften når det gjelder ekstra kompleksitet? Og nøyaktig hvilke problemer er det SOA-verktøy og -tankesett retter seg mot? De fokuserer på problemer rundt å håndtere et stort økosystem av distribuerte tjenester som må integreres. Men dersom det er kostbart å utvikle en tjeneste som kan brukes utenfor sin opprinnelige sammenheng, dersom tjenester ikke er så gjenbrukbare som vi skulle likt å tro og dersom distribuert arkitektur er et hinder for en smidig forretning, er ikke da SOA en måte å skape unødvendig kompleksitet på? Hva om vi sparer komplekse problemstillinger som integrasjon til de tilfellene der det virkelig trengs? I slike situasjoner kan WS- og ESB spille en rolle. Ikke som en sølvkule som skal ta livet av kompleksitetsmonsteret, men som avanserte, komplekse verktøy som kan øke effekten av arbeidet vårt. Kanskje. Jeg er ikke sikker på hvor mye effekt disse verktøyene egentlig gir. Men jeg er ganske sikker på de øker kompleksiteten på oppgaven. Mange takk til Eivind Nordby, Hogne Kirkeby, min far Bjørn Brodwall, Anne Marie Baugstø-Hartvigsen, Geir Hedemark og Lars Arne Skår som har hjulpet meg med tilbakemeldinger på denne artikkelen.

Comments:

Johannes Brodwall - Aug 12, 2008

Hei, Rolf

Jeg er enig med deg i at noen av påstandene i artikkelen min kan virke som stråmenn. Men jeg har fortsatt til gode å få noen til å komme med en konkret påstand om “hvorfor SOA” som jeg kan forstå som noe annet enn en av disse fire.

Din holdning til at det hele dreier seg om forenklet infrastruktur virker pragmatisk. Betyr dette at du grunnleggende sett sier at “SOA = SOAP + en del andre passende teknologier”?

Dette er det mange SOA-evangelister som er uenige i.

Jeg er selv uenig i at SOAP + venner har tilbudt en pragmatisk teknologistack. Jeg ønsker ikke å “hoppe bukk” over disse standardene, men i stedet stanse før dem: Ved HTTP og XML.

[Rolf] - Aug 12, 2008

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.

Johannes Brodwall - Jun 22, 2008

Hei, Lars Arne

Takk for gode kommentarer.

Jeg tror vi er enige om at det er en utfordring å skulle bygge “systemer av systemer”, slik du beskriver. Jeg tror imidlertid at dette er en arkitekturmessig innfallsvinkel som ofte er feil.

For det første er ikke gevinstene av gjenbruk så store som folk forventer. For det andre er kostnaden ved å bygge distribuerte systemer mye høyere enn folk forventer.

Men dette har jeg tenkt å skrive mer om i fremtiden. :-)

Når det gjelder “å få integrasjon ut av applikasjonen” er dette også noe som må gjøres med forsiktighet. Jeg har sett mange middleware løsninger som får integrasjonen ut av løsningen, men på den bekostningen at man i stedet må foreta en kostbar integrasjon med middlewareplattformen. Ooops!

Lars Arne Skår - Jun 22, 2008

Bra du tok bryet med å skrive denne på norsk også - det er mer enn nok av folk her hjemme som også engasjerer seg i dette “fenomenet”, “problemet”, “løsningen” eller hva man ønsker å kalle det.

Har egentlig ikke så mange kommentarer, annet enn at jeg nok er mer optimistisk enn deg ift. at jeg regner det som sannsynlig at utviklingen på dette vil føre noe bra med seg.

Greit nok at WS-* greiene minner om Corba utviklingen, og dermed også har skapt tette bindinger i praksis, og dermed undergravet håpet/intensjonen med SOA og fokus på løse(re) koplinger.

Det med BPM kan jeg være med på er veldig oppskrytt - minner overraskende mye om håpet vi satte til case-verktøy på begynnelsen av 90-tallet som gjorde at vi måtte fjerne oss enda mer fra det vi egentlig skulle løse til vi endelig kunne løse det.

Men punkt 2 - det å samle integrasjonen til et knutepunkt for å gjøre sammensetning av systemer enklere tror jeg både er viktig og at vi begynner å få konsepter og teknologi som kan fungere. Det tar ikke nødvendigvis bort noe arbeid eller kompleksitet, men det samler det, slik at en kan rette fokus der. Mye tyder på at systemer av systemer blir en viktigere organisasjon av løsninger enn de enkeltvise løsningene osm skal løse sine egne behov. En viktig grunn til dette, er ønske om felles forretningsmessig oppførsel mot ulike typer av bruker, kanaler uavhengig av hvor de kom fra. Det vi tidligere kalte multi-kanal. For å få til det på en bra og riktig måte, så er det beste å faktisk knytte seg til de systemene denne oppførselen styres på framfor å duplisere det.

Greit nok at vi ikke har sett de beste eksempler på dette enda, men jeg mener å ha sett kimen til det der man fokuserer på å få det til. På slutten av 90-tallet var det hot å etablere en middleware man gikk mot - og det fikk man faktiskt til. Så ble det “ødelagt” når internett løsningene kom, og man reimplementerte nye spesifikke løsninger oppå dette igjen, som gjorde at man fikk ny fragmentert og duplisert forretningslogikk spredt over mange løsninger. Her vil jeg regne med og håper det vil skje en ny oppryddingsjobb, som gjør at vi igjen kan få renere løsninger som kjører den samme forretningslogikken et sted. Greit nok at man hevder en har unike behov i ulike kanaler og grensesnitt, men når en faktisk forventer like oppførsel i ulike kanaler, så vil det faktisk være det riktigste å sluse det til samme sted.

Der jeg tror mange SOA-prester har gjort feil og skuffet, er der de har presset på at WS-* er svaret, og brukt det som en intern applikasjonsarkitektur stil. Det er klart det ikke vil gi noen særlig fordeler. En for en særdeles kompleks SW stack å forholde seg til, som egentlig ikke løser noe som helst i en slik setting.

Derimot har jeg tro på at en bevisst segmenter system porteføljen sin til rene løsninger med veldefinerte oppgaver, som en gjerne kan kalle tjenester, og gjør det enkelt å bruke de. Da krever det forvaltning av disse tjenestene, og bevisst fokus på at de brukes konsistent i virksomheten. Med flere brukere av disse tjenestene kan det være behov for systemstøtte for å få rask tilgang til de, og transformasjon mellom ulike kontrakter for å få til fleksibilitet på dette området. Dette bør da ligge utenfor selve applikasjonen (tjenesten), slik at en kan rendyrke logikken der. Mao. helt vanlig abstraksjon, med fokus på å få integrasjon ut av applikasjonen.

Ble litt kommentarer allikevel - ikke til artikkelen i seg selv, den synes jeg er kjempebra. Kun en meningsytring fra en som fortsatt er optimistisk (men er enig med deg at vi har langt igjen…)

[rolf] - Nov 1, 2008

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.

[rolf] - Aug 25, 2008

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.

jhannes - Aug 25, 2008

Hei, Rolf

Når det gjelder integrasjonsteknologi, tror jeg vi er enige om at de som ignorerer standarder får store mengder hodepine. Dette er en påstand som ofte brukes til forsvar for WS-. Men SOAP og WS- har i det store og det hele ignorert en bedre standard enn seg selv, nemlig HTTP. HTTP standarden dekker autentisering (det går faktisk an å bruke Basic authentication for REST web services), sikkerhet (https) og mye annet SOAP har valgt å stappe i en egen “soap-header”. Å ignorere (bedre) arbeid gjort før er en av syndene SOAP begikk.

Klientgenerering er et ortogonalt problem, og hvis man ønsker det (ofte et stort “hvis”), så finnes det masse verktøy som genererer kode fra XSD. (Det er egentlig dette som skjer i WSDL -> kodetilfellene også).

Når det gjelder konseptet SOA er jeg ikke sikker på om du er i enig i det de fleste SOA-evangelister jeg har møtt kaller SOA. Det dreier seg ikke om klient-server integrasjon (noe som vi alltid har gjort mer eller mindre via kontrakter og standarder), men om intern struktur av “serveren” som en (gjerne verktøy-“støttet”) koordinert prosess av (gjerne distribuerte) tjenester med en kontrakt mellom seg.

Dersom SOA-forkjempere hadde snakket om SOA mellom applikasjoner hadde de hatt rett (og sagt noe trivielt), men i den grad de snakker om SOA inni applikasjoner tar de farlig feil.

jhannes - Nov 1, 2008

Jeg må innrømme jeg ikke skjønner alt du skriver, så jeg skal forsøke å relaterte dette til din siste påstand:

Jeg tror tykke klienter ikke er hensiktsmessige for informasjonsapplikasjoner. Når man ønsker dem, tror jeg man bør se på klienten som en utvidelse av én server, som for eksempel Java WebStart. Klienten bør kommunisere med én server, og dersom det faktisk er flere informasjonskilder inkludert, kan serveren være koordineringspunktet for disse. Spesielt når man tenker feilkilder er dette kritisk.

For å faktisk implementere det, vil jeg peke mot DDD-inspirerte innfallsvinkler som Qi4J sin UnitOfWork eller ObjectWare’s Entity Data Repository.

Når det gjelder adskillelse, for eksempel i en tynn-klient applikasjon, tror jeg vi er enige: Hold komplisert logikk ute av view-koden. Dette er trivielt og Web Services hjelper ikke her, snarere tvert imot. (Jeg lar denne påstanden henge i luften, jeg regner med at du skjønner hvorfor jeg mener dette)

Jeg velger å ikke ta opp det du sier om 10-20 klienter i pipelinen da jeg aldri har sett et faktisk eksempel på dette som ikke var konstruert. Dersom jeg kommer over en situasjon der dette er et reelt problem, og ikke bare et “accidential complexity” skapt av overivrige arkitekter, har jeg litt læring å gjøre.

Johannes Brodwall - Nov 1, 2008

Jeg må innrømme jeg ikke skjønner alt du skriver, så jeg skal forsøke å relaterte dette til din siste påstand:

For å faktisk implementere det, vil jeg peke mot DDD-inspirerte innfallsvinkler som Qi4J sin UnitOfWork eller ObjectWare’s Entity Data Repository.