Konferansen er et viktig møtepunkt for alle som er opptatt av hva som venter rundt neste hjørne på internett – samt en realitetssjekk på hva som fungerer (eller ikke fungerer) med dagens plattformer, løsninger og forretningskonsepter.

Vi har tatt med oss noen hovedtrender fra Web 2.0 Expo. Hver av dem en verdt en eller flere blogginnlegg, og vi vil komme nærmere tilbake til de enkelte trendene.

Here goes:

Trend #1 : Lokalisering er overalt

Utnyttelse av sosiale medier med lokaliseringstjenester er på alles lepper. De fremste tjenestene pr. nå er businessorienterte Foursquare og tamagotchi/pokemon-inspirerte Gowalla. Google og Facebook er på vei med sine konkurrerende tjenester, så dette skal bli et uoversiktlig landskap å orientere seg i. Det som dog er viktig å ta med seg er:

• Dialog mellom mennesker inneholder stedsinformasjon. Overhør en telefonsamtale på bussen og sjekk selv. Sosiale medier er fremfor alt om dialog, og disse mediene kommer følgelig til å oversvømmes av lokaliseringsinformasjon.
• Virksomheter ønsker å vite både hvem kundene er – og hvor de er. At man også kan bruke sosiale medier til å trekke kunder inn i de fysiske butikkene er ett av Foursquares verdiforslag.
• SFs svar på Ruter (BART) har brukt Foursquare for å øke antall reisende med offentlig kommunikasjon. I en kundeundersøkelse sier 19% av de spurte at de hadde reist med BART basert på en anbefaling fra en digital venn, og 38% syntes offentlig transport var “more fun” med mobile lokaliseringstjenester.

Lokaliseringstjenester kommer til å bli stort – og forhåpentligvis mer oversiktlig enn det er idag.

Trend #2 : HTML5 er den nye vinen

Hva skal man si? ALT kan gjøres i HTML5. Audio, video, skalerbar vektorgrafikk, 3D, SQL, webfonter etc. etc. Dette kan erstatte Flash, Silverlight og andre pluginbaserte utvidelser. De dårlige nyhetene er at implementeringen varierer kraftig fra nettleser til nettleser, og Microsoft er ikke på banen ennå. Vi står med andre ord foran flere år med browserkrig. Google har prøvd å imøtegå dette ved å lage en Chrome plugin til IE, noe som virker som et solid hopp tilbake til start.

En engstelig sjel i salen som prøvde å varsku om sikkerhets- og ytelsesproblemer fikk klar beskjed fra podiet: Toget har gått; standarden er vedtatt, framtiden er her og nå.

Så fikk vi se og høre Quake 2, spilt i nettleseren. Wow.

Trend #3 : Weboptimalisering

Ytelsesoptimalisering av websider gir høyere kundetilfredshet, økt konverteringsrate, mer aktive brukere – OG det er lønnsomt ift reduserte krav til infrastruktur og drift.

For å ta det siste først: Siden det å servere ut html-sider er noe av det tyngste infrastrukturen din gjør, har tjenester som Netflix og Shopster redusert henholdsvis antall servere og båndbredde til det HALVE ved å drive strukturert og helhetlig optimalisering av websidene. Sjekk ditt eget driftsbudsjett for å se hva gevinsten kunne vært? Forutsetningen for en slik kostnadsreduksjon er selvfølgelig at man har et stort antall brukere – og at man betaler for faktisk bruk av infrastrukturen (slik man gjør i skyen…).

Google og Yahoo! har foretatt undersøkelser med brukere som blir utsatt for dårlig ytelse. Begge undersøkelsene utsatte brukere for høyere og høyere forsinkelse i levering av websider. Undersøkelsene ble ikke framlagt, men en viktig lærdom fra Google sin undersøkelse er verdt å merke seg:

Google kjørte undersøkelsen med testgruppe og referansegruppe, der referansegruppen ikke ble utsatt for forsinkelser. Testgruppens adferd endret seg, i form av at brukerne ble mer passive, mindre villige til å fullføre oppgaver (=lavere konverteringsrate). Etter at forsinkelsen ble fjernet hadde gruppene fortsatt ulik adferd – i lang tid. Så lang tid at testgruppen ikke hadde fått gjenopprettet sitt aktivitetsnivå idet undersøkelsen ble avsluttet. Brukere som blir utsatt for forsinkelse blir passive, og det gir ingen umiddelbar effekt å rette feilen.

Ved dårlig servicenivå gjør man skade som varer lenge.

Virksomheter som har hatt suksess med weboptimalisering sier at verktøyene ikke trenger å være veldig sofistikerte. De trekker fram Yahoo! YSlow og Google Page Speed som gratiseksempler. Men et viktig suksesskriterie er at ytelsesparametrene ikke kan eies av IT alene: Alle de viktigste ytelsesparametrene må eies (og forstås) av forretningsenheter, markedsavdeling og ledelse. Først da kan man ta ut den forretningsmessige effekten.

Trend #4 : API’er på godt og vondt

Fra å snakke om mashups er dialogen og diskusjonen nå vendt til realitetene ved å eie, forvalte og bruke åpne API’er. Mantraet fra LinkedIn er: Planlegg godt, gjør ingen feil. Lett å si, men vanskelig å gjøre.

Twitter har hatt store problemer med sin autentiseringstjeneste, og har måttet tvinge brukerstedene av API’et over på ny løsning – rett og slett ved å skru av den gamle på et gitt tidspunkt. Resultatet ble at mange tjenester som baserte seg på twitter sluttet å virke, og feilsøking og feilretting rundt overgangen er fortsatt ikke avsluttet. Litt mer kundevennlige LinkedIn måtte ringe opp alle brukerstedene før de gjorde endringer. God service, men en så stor jobb at det nesten er vanskelig å forestille seg.

Lærdom1: Skal man etablere et åpent API må man betrakte brukerne av API’et som kunder, og behandle dem deretter. Å eie et API er å eie et produkt – lansering må planlegges nøye, og produktets livssyklus må analyseres før det settes ut i markedet.

Lærdom2: Skal man benytte et åpent API må man agere som kunde. Dette innebærer å registrere seg, og forholde seg til løpende dokumentasjons- og programendringer. Man må også ytelsesplanlegge og robustifisere sin egen løsning og kundedialog for situasjoner der API’et kan være utilgjengelig.

Trend #5 : Sosiale medier og CRM

Alle vil vite mer om hvorledes man kan benytte sosiale medier i aktiv bearbeiding av markedet og kundene – med økt salg som formål. Mange vil snakke om temaet, og har kloke ideer til hva man ikke bør gjøre. Nesten ingen har gode mønster/patterns for hvorledes gjøre dette i praksis.

Lærdom: Det er bedre å gjøre noe selv om man ikke ser en konkret og målbar positiv effekt, enn å gjøre ingenting og oppleve en konkret og målbar negativ effekt.

Trend #6 : Vi er alle (agile) webutviklere

Sett i lys av ovenstående trender blir webutvikling og kunnskap om tjenester og teknologier en felles møteplass for forretningsutviklere, systemeiere, markedsførere, designere og utviklere. Ingen kan melde seg ut av denne kunnskapssirkelen og fortsatt ha et realistisk håp om fantastiske resultater ved bruk av digital teknologi. Web 2.0 tilhører ingen rolle, avdeling eller virksomhet alene.

For å skape god effekt med mange involverte parter, satte konferansen søkelyset på hurtigd/agile/lean prosesser der man skaper verdi tidlig – og prioriterer hardt i forhold til egne krav. Levere lite & fort er bedre enn mye & sent.

Alt satt i system

I et forsøk på å sette disse trendene i en form for et system, skisset jeg raskt opp denne figuren på det man bare måtte ha med seg hjem fra San Francisco i mai i år: en iPad. Rundt en tredel av alle konferansedeltakerne hadde et brett, og på forespørsel fra plenumspodiet kom så godt som alle hender i været på spørsmålet: “Hvem har en iPhone?”. Tross denne Apple-dominansen var det slående at sympatien vektet tungt i favør av Adobe i spørsmålet rundt framtiden til Flash. Dette er kanskje også trender, men her har vi satt fokuset på forretningsutvikling på nett:

Kundeopplevelse og Web 2.0 trender

Illustrasjonene bør inneholde følgende informasjon:

• Hvilke data som flyter mellom systemene
• Hvilken teknologi som benyttes i integrasjonene
• Hvilket system som initierer koblingen

Tidligere har vi tegnet dette i forskjellige diagrammer, med og uten UML. Det har vært vanskelig å få nok informasjon inn i ett enkelt diagram uten å miste oversikten og lesbarheten. Flere diagrammer kan gi klarhet i hvert sitt perspektiv, men når det blir snakk om mange systemer og målbildet endrer seg ofte, kan det bli tidkrevende å holde de forskjellige diagrammene i samsvar med hverandre. Følgende notasjon gjør det mulig å tegne alle detaljene i ett enkelt diagram uten at det blir uoversiktlig.

Koblingstype	Illustrasjon	Initiativ	Dataflyt
Manuell overføring		manuelt
Batchoverføring
Web Service kall
Web Service pull
Direktekobling (API)
Datapull gjennom direktekobling (API)
Databasepopulering
Databasoppslag

Nedenfor er et enkelt, fiktivt eksempel på et integrasjonsdiagram med denne notasjonen. Det er noen få systemer inkludert, hvor en kundeadministrasjonsapplikasjon henter data fra en integrasjonsplattform, som igjen henter og sammenstiller kundedata fra to systemer. Applikasjonen kan oppdatere databasen, og kan overføre kundedata som en batchjobb til et datavarehus.

eksempel på integrasjonsdiagram

En interessant sak nå nylig er denne: Tilbyr SOA på tre måneder til fast pris Her er aktøren seriøs og godt kjent i markedet, men har jeg noen tro på SOA (tjenesteorientert arkitektur) på 3 måneder? Til fastpris?

For å si noe om det må vi først ha en liten definisjon av hva SOA er – og hvorfor vi ønsker oss en SOA. Det siste er viktig, hvis ikke er vi ikke i stand til å bedømme om vi oppnår det vi ønsker eller ikke.

Motivasjonen til å innføre en tjenesteorientert arkitektur (SOA) kan være forskjellige, men på mange måter koker det ned til å kunne få en IT-portefølje som er mer fleksibel og bedre tilpasset de forretningsprosessene de skal understøtte. I dette ligger større endringsdyktighet og høyere grad av gjenbruk, noe som vil kunne bidra til reduserte kostnader. Måten vi søker å oppnå dette på er gjennom å bygge systemene som en samling av tjenester, derav navnet tjenesteorientert arkitektur. Akkurat hvordan tjenestene skal utformes og settes sammen for å nå målene om fleksibilitet og gjenbruk kan man ha lange diskusjoner om, akkurat her skal jeg nøye meg med å mene at det ikke er tilfeldig hvordan tjenestene utformes – samt at såkalte “loosely coupled business services” er en riktig god start.

Tjenesteorientering er altså middelet vi bruker til å oppnå de ønskede effektene (endringsdyktighet, fleksiblitet…). Naturlig nok kommer da effektene vi ønsker gradvis etter hvert som vi etablerer flere og flere tjenester og blir flinkere og flinkere til å utforme de på rett måte.

Hva er det så “reklamen” sier at vi nå kan få etablert på tre måneder, og til fastpris? Såvidt jeg kan lese ut fra artikkelen er det snakk om å levere en teknisk plattform, arkitektur og malverk. Dette er sikkert en fin og nyttig verktøykasse for å begynne å realisere tjenester, men det er da tydeligvis ikke snakk om å gjennomføre en omfattende implementasjon av tjenester – det ville også vært en overraskelse om dette lot seg designe, utvikle, teste og produkssjonsette i noe særlig omfang i løpet av tre måneder (…til fastpris).

Det er fristende å bruke denne modellen: http://schneider.blogspot.com/2008/03/jbogs-and-pops.html og kalle dette JBoPS, dvs Just a Bunch of Platform Stuff. Herfra er det et godt stykke igjen til lykkelandet SOA…

Nå er selvfølgelig denne typen plattform-prosjekter veldig greie å håndtere, de er enkle å scope, oversiktelige, målbare og kommer i mål innenfor rimelige tidsfrister, og så kan de også kjøres uten at man trenger å gjøre gjennomgripende ting med hele organisasjonen. For meg er de imidlertid bare begynnelsen på å gjennomføre en tjenesteorientering; Og kanskje er det heller ikke nødvendig å investere tungt i plattform først?

Har også lyst til å legge til at selv om det kan ligge mye nyttig støtte i et godt malverk og i et arkitekturrammeverk, så betyr dette ikke at design og arkitekturvurderinger ikke er en utfordring lenger. Å velge rett granularitet på tjenestene og å klare å finne de rette generiske og gjenbrukbare grensesnittene viser seg å faktisk være ganske krevende, og må gjøres riktig i hvert enkelt tilfelle.

Så får du en SOA på tre måneder? Det er i stor grad en definisjonssak. Du kan sikkert få på plass en SOA-plattform og så kalle det SOA, men alle de gode effektene som SOA er ment å skulle gi oss får du ikke av en plattform-implementering alene. De kommer av å implementere og ta i bruk tjenester, noe du må regne med at tar langt mer enn tre måneder – og at du ikke får fastpris på den jobben.

Det er fristende å sammenligne med å gå til innkjøp av treningsapparat og instruksjonsvideo. Fin start, men du blir hverken sprek og/eller slank av å sette opp treningsapparatet i kjellerstua – du blir sprek av å begynne å trene på det og så fortsette å trene på det. I tillegg hadde du sikkert ett par joggesko eller noe annet som kunne brukes til å trene med liggende allerede

En del verktøy begynner imidlertid å få mange tilhengere og ganske entydige definisjoner, et av disse er den såkalte servicebussen, dvs en Enterprise Service Buss. En ESB altså. Som sagt er det ikke nødvendigvis enighet om nøyaktig hva en ESB skal omfatte, men her er ihvertfall en definisjon av hva en ESB skal bidra med:

• Ruting og formidling av tjenestekall
• Transformering og berikelse av meldinger
• Overvåkning og monitorering

En av de viktigste effektene av å ta i bruk slike mekanismer er å etablere en tjenesteproxy mellom tilbyder og konsument av tjenestene, dvs at tilbyder og konsument ikke snakker direkte med hverandre. Grunnen til at dette er bra er at det kan bidra til løsere sammenkobling i tjenestearkitekturen, noe som er sentralt for å oppnå den fleksibiliteten og endringsdyktigheten som SOA er ment å skulle gi.

Flere av disse egenskapene til en ESB er forøvrig godt kjent fra “hub-and-spoke” typen integrasjonsverktøy – mange av løftene om hva de skulle gi av fordeler var nok også de samme. For ikke alt for mange år siden ble det investert mye penger i denne typen verktøy (som f.eks SeeBeyond, WebMethods, Tibco), sannsynligvis uten at man oppnådde alt man ønsket. Systemene ble definitivt integrert med hverandre og dataene kom fra A til B, men over tid viste løsningene seg å være vanskelige og tidkrevende å endre på, samtidig som det var vanskelig å gjenbruke de integrasjonene som ble etablert.

Det kan selvfølgelig være mange grunner til dette, og den rent tekniske forskjellen på en ESB og et integrasjonsverktøy av denne typen kan også være rimelig subtile. En hovedårsak var imidlertid at man ikke fikk til løs kobling, dvs at integrasjonspunktene ble knyttet for tett til hverandre og det ble dermed vanskelig og kostbart å gjøre endringer.

Dette bringer oss fram til spørsmålet om SOA er en ESB. Svaret er egentlig nei – å etablere en SOA er (dessverre) langt mer komplisert enn å bare sette opp en ESB. Faren er at hovedfokus blir på å etablere alt som tjenester, noe en ESB forsåvidt kan hjelpe til med, men uten at man dermed oppnår det man egentlig ville med en tjenesteorientering. Jeg tror det er viktig at man holder fokus på at målet med SOA er økt fleksibilitet og endringsdyktighet. Løst koblede tjenester er middelet for å oppnå dette.

Når men jobber med SOA er det derfor viktig at man har et kontinuerlig fokus på hvordan oppnå fleksilitet og løs kobling, dette er nemlig ikke noe som kommer automatisk hverken av at man lager alt som tjenester eller om man bruker en ESB. Zapthink snakker til og med om sju nivåer av løs kobling “loose coupling”: http://www.zapthink.com/report.html?id=ZAPFLASH-20071128.

Tjenester og bruk av en ESB som et tjenesteproxy-lag i arkitekturen vil definitvt hjelpe deg på vei, men til slutt vil det være hvor godt tjenestene er utformet og hvordan de brukes som vil avgjøre graden av suksess. Regler for hvordan tjenestene skal utformes blir derfor viktig, dvs at man også må etablere en såkalt SOA Policy for å beskrive hvordan dette skal gjennomføres.
Og selv om det er vanskelig, så husk at suksess bør måles i hvor endringsdyktige man klarer å få IT-systemene til å bli og hvor stor grad av gjenbruk man klarer å oppnå, ikke i hvor mange tjenester man har etablert.

Det er også vel verdt å merke seg at bruken av en tjenesteproxy er et designpattern (dvs en god designide), og ikke noe som er uløselig knyttet til en ESB. Hvorvidt man velger å implementere dette pattern’et fra grunnen av selv eller kjøper inne en ESB, er en rent praktisk vurdering som bør gjøres ut fra hvilke krav man har, hvor mange tjenester det er snakk om og i hvilken grad man vil kunne nyttegjøre seg annen funksjonalitet (f.eks overvåkning og feilhåndtering) som kan finnes i en ESB.

Så hva kan Mule brukes til og hvordan funger det? Mule er en Enterprise Service Bus i forstand at den består av komponenter som kan motta data, transformere data, eksekvere kode, og sende data videre. Disse komponentene konfigureres via XML filer hvor prosessflyten og protokoller spesifiseres. Her er en figur som illustrerer et tenkt scenario hvor den første komponenten mottar data via en Web Service og legger dataene på en kø via JMS, og er ferdig. En annen komponent lytter på køen, transformerer dataene og splitter den til en komponent som lagrer dataene til en database og en annen komponent som sender dataene til et annet system via en Web Service.

Dette er et enkelt men veldig typisk scenario for integrasjon. Siden flyten og protokollene konfigureres via en XML fil er det en smal sak å endre det slik at dataen sendes til en tredje komponent, samt å legge på transaksjonsstøtte for garantert levering fra kø til destinasjon.

Mens flyten, protokoller, destinasjoner og transaksjons konfigureres via en XML fil, så består selve innholdet i hver komponent av en enkel java klasse. Å lage en web service kan være så enkelt som å lage en klasse med en metode String getName() og så spesifisere XML filen at det skal være en Web Service.

It’s free. There must be a catch? Vel, ja. Hovedproblemet med Mule er den teknologiske terskelen for å komme i gang. Mule består av så mange forskjellige teknologier, hvor mange av dem, blant annet Mule selv, er nokså dårlig dokumentert. Så foruten at man trenger en god forståelse av integrasjonsteori som synkron/asynkron kommunikasjon, normalisering, korrelasjoner, transaksjoner, xml og database, så er det underliggende teknologiene som er en utfordring. Teknologier som man bør kunne for å få gjort noe i Mule vil generelt være: Java, Spring, Maven, Web Services (Xfire,CXF, JAX-WS), JMS, XML, JDBC, JMX og J2EE applikasjons tjener.

Det er mange måter deployere Mule på, men måten jeg har funnet ut fungerer mest tilfredsstillende er pakke hver instans som en ear fil, og hot-deploy til JBoss. Når man deployer flere instanser så vil hver instans ha sin egen classloader og være fullstendig separat. Problemet med dette, i forhold til andre ESB produkter, er at Mule ikke kan dele såkalte konnektorer mellom ulike instanser. Konsekvensen av dette er at dersom man har to instanser som eksponerer Web Services så må hver instans ha sin egen port. Dette kan fort bli en utfordring dersom man har mange instanser.

Så for å summere opp. Fordeler med Mule er

• Fleksibelt og veldig pragmatisk rammeverk for integrasjon og prosessflyt
• Skalerer sannsynlig veldig bra teknologisk på komponentnivå
• God støtte for protokoller
• Open source, noe som gjør det lettere å debugge
• God støtte for unit- og funksjonell testing (noe som de aller fleste andre ESB mangler)
• Ingen lisenskostnader
• God online hjelp via deres mailingliste
• Relativ god støtte for innsyn/monitorering under kjøring via JMX

Svakheter

• Skalerer dårlig når det gjelder deployering
• Høy terskel for å komme i gang
• Fortsatt en del ting som ikke fungerer som det skal
• Mangler grafisk grensesnitt for konfigurering
• Mangler grafisk grensesnitt for XML mapping

Så alt i alt så er Mule et veldig interessant rammeverk som i mange tilfeller vil være tilfredsstillende for å gjøre integrasjon.