Thinking inside a bigger box - Latest Comments in Fire påstander om SOA

Re: Fire påstander om SOA

jhannes — Sat, 01 Nov 2008 10:28:08 -0000

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.

Re: Fire påstander om SOA

rolf — Sat, 01 Nov 2008 06:56:52 -0000

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.

Re: Fire påstander om SOA

jhannes — Mon, 25 Aug 2008 11:41:04 -0000

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.

Re: Fire påstander om SOA

rolf — Mon, 25 Aug 2008 08:11:28 -0000

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.

Re: Fire påstander om SOA

Johannes Brodwall — Tue, 12 Aug 2008 18:08:08 -0000

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.

Re: Fire påstander om SOA

Rolf — Tue, 12 Aug 2008 14:23:17 -0000

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.

Re: Fire påstander om SOA

Johannes Brodwall — Sun, 22 Jun 2008 15:38:25 -0000

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!

Re: Fire påstander om SOA

Lars Arne Skår — Sun, 22 Jun 2008 08:20:31 -0000

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