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.
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…)
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…)
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!
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.