Hvor skal intelligens integreres?

Bakgrunn om tjenestebuss

I en stadig mer tjenesteorientert verden, er tjenestebuss et nyttig og populært konsept for integrasjon. Kort fortalt er tjenestebuss en sentralisert samling av tjenester som tilbys konsumentapplikasjoner for å integrere mot ulike fagsystemer. Dette kan innebære en-til-en-mapping, eller hente og samle/sette sammen informasjon fra flere systemer.

Det er vanlig å velge å implementere en ”dum” tjenestebuss. Med ”dum” menes her at tjenestene egentlig ikke trenger verken å gjøre eller vite spesielt mye. En request kommer inn, og inneholder all informasjon som trengs for at tjenesten skal få gjort jobben sin. Innholdet i requesten kan så transformeres til nye requester mot et eller flere fagsystemer, og på bakgrunn av responsene herfra genereres en samlet respons.

Det er vanlig å velge å implementere en ”dum” tjenestebuss. Med ”dum” menes her at tjenestene egentlig ikke trenger verken å gjøre eller vite spesielt mye

Case closed, done deal, ikke noe hokus pokus. Ikke noe hukommelse, ingen transaksjonshåndtering. Et mer brukt og mindre flåsete begrep for dette, er tilstandsløse tjenester.

Når verden blir mer komplisert

Tilstandsløse tjenester fungerer i mange tilfeller helt utmerket. Men hva med når tjenestens oppgave er en deloppgave i en større sammenheng, kall dette gjerne en prosess, og dermed avhenger av historikk og resultatet av andre deloppgaver?

Man kan da se for seg at konsumentapplikasjonen holder styr på dette, og sender tilstrekkelig informasjon i hver request. Det er dog ikke alltid trivielt. Videre er det en relativt vanlig situasjon at i en mer komplisert prosess, så kommer requester fra flere ulike systemer, ikke kun den applikasjonen som initierte prosessen. Dette kan for eksempel dreie seg om asynkrone tilbakekall fra fagsystemer, når disse har gjort ferdig sine oppgaver.

Hva med når tjenestens oppgave er en deloppgave i en større sammenheng, kall dette gjerne en prosess, og dermed avhenger av historikk og resultatet av andre deloppgaver?

Det er som regel ikke mulig å kreve at alle involverte applikasjoner, gjerne fra ulike leverandører, kjenner tilstrekkelig til historikk/tilstand til å kunne gi all nødvendig informasjon som kreves av de ulike tjenestene. Leverandører av store/populære fagsystemer baserer seg ofte på tjenester med standard funksjonalitet, og gjør ikke uten videre store tilpasninger pga én konsuments spesielle behov.

Ytterligere faktorer kompliserer bildet for tilstandsløse tjenester. I en komplisert prosess kan det være slik at visse oppgaver skal utføres på gitte tidspunkter, eller etter en gitt tid. Det kan være slik at man skal forsøke igjen med ulike mellomrom et konfigurerbart antall ganger ved kommunikasjonsfeil, eller når omliggende systemer rapporterer at de ikke er ferdige med sine oppgaver. Det kan være at alternativ flyt skal kjøres for gitte kriterier, for eksempel ved visse typer feil eller utgått tidsfrist.

En prosessmotor kan ofte være løsningen, også kjent som arbeidsflytmotor og forretningsregelmiljø

Ytterligere, for saktegående prosesser, eller prosesser som av ulike årsaker stopper opp, vil det gjerne være et behov for å kunne gå inn og se tilstand. Dette er naturligvis ikke støttet av en tilstandsløs tjenestebuss.

Prosessmotor som mulig løsning

En prosessmotor kan ofte være løsningen, også kjent som arbeidsflytmotor og forretningsregelmiljø. I denne sammenheng menes med prosessmotor et system som har en definert flyt mellom steg, med et sett oppgaver som utføres i stegene, samt regler for overganger mellom stegene.

En prosessmotor kan sies å definere/implementere en prosess, og den vil holde styr på nødvendig historikk og tilstand, som typisk persisteres i en database.

Prosessmotor: Et system som har en definert flyt mellom steg, med et sett oppgaver som utføres i stegene, samt regler for overganger mellom stegene

Det finnes flere prosessmotorrammeverk, inkludert open source, som det går an å basere implementasjonen på, for eksempel jBPM, Activiti og Documentum. Typisk implementerer man en prosess med et antall steg, og hvor hvert steg i hovedsak utfører én oppgave, eventuelt med mindre bi-oppgaver i tillegg, som for eksempel meldingsutsendelser avhengig av progresjon.

Enkelte steg kan også være det vi kan kalle vente-steg, hvor prosessen utelukkende venter på input fra omliggende systemer som i øyeblikket arbeider på prosessen, eller aktivt poller status fra disse systemene.

Eksempel på en prosess

Et trivielt eksempel på en prosess kan være et søknadssystem, hvor første steg tar imot og registrerer en søknad, neste steg varsler saksbehandler, tredje steg venter på at saksbehandler skal behandle saken, og når dette er gjort ankommer man fjerde steg, som er å informere søkeren om resultatet.

I ett tilfelle er prosessen så triviell, i praksis bare å stå og vente på en innkommende request, at implementasjonen har endt opp mye mer komplisert enn oppgaven som utføres

Gjennom en stor kunde har vi fått mye erfaring med forvaltning av applikasjoner som refereres til som prosessmotorer. Der har man dog kanskje vært litt for glad i å løse alt med prosessmotorer, både med og uten rammeverk for dette. I ett tilfelle er prosessen så triviell, i praksis bare å stå og vente på en innkommende request, at implementasjonen har endt opp mye mer komplisert enn oppgaven som utføres. Og i et annet tilfelle finnes det ikke egentlig noen prosess, det er kun snakk om hukommelse.

Dette er eksempler som med fordel ha vært implementert annerledes.

Alternativer til prosessmotor

Hva annet kunne man ha gjort? Det holder egentlig ofte å ha en database, og en lettvektsapplikasjon implementert i ønsket språk for å oppdatere og agere på bakgrunn av innholdet i databasen. Dette kan være frittstående applikasjoner, men kan vel så gjerne pakkes sammen med andre støttesystemer til tjenestebussen. Det er gjerne ikke nødvendig å gjøre ting mer kompliserte enn de er.

Det holder ofte å ha en database, og en lettvektsapplikasjon implementert i ønsket språk for å oppdatere og agere på bakgrunn av innholdet i databasen

Konkrete erfaringer med forvaltningen av applikasjonene omtalt i forrige kapittel viser at prosessmotorrammeverk kan finne på å definere langt flere databasetabeller enn nødvendig. Ved et tilfelle så har rammeverket i tillegg spredt dataene utover på uoversiktlig og lite intuitivt vis. Når det så kun er en enkel prosess med få steg å holde styr på, så er det et betinget spørsmål om det strengt tatt var nødvendig å innføre et prosessmotorrammeverk.

Implementere prosesser på tjenestebussen?

Hva så med å implementere prosesser på tjenestebussen selv? Ja, det er en interessant tanke! Nødvendigvis vil dette medføre at ikke alle tjenester på bussen lenger er tilstandsløse, så her må fordeler for den spesifikke prosessimplementasjonen vurderes opp mot et eventuelt ønske om et rent og gjennomført tilstandsløst design av tjenestebussen.

Hva kan så fordelene være? Her er noen:

• Raskere implementasjon. Tjenester på bussen er typisk enklere å implementere, med all støtten man får av tjenestebussen, versus en helt ny applikasjon som må opp og kjøre på egenhånd.
• Færre systemer å forvalte og drifte.
• Færre servere å anskaffe og vedlikeholde.
• Mindre nettverkstrafikk.

Selvfølgelig må ulemper også nevnes:

• Selv om det totalt blir færre kall inn til tjenestebuss, så vil kall til prosessmotor-tjenestene typisk være mer tidkrevende enn ordinære tjenester, da de involverer databasekall. Dette kan påvirke totalytelsen til tjenestebussen, om man ikke gjør jobben riktig.
• Enkelte oppgaver kan trenger litt ekstern hjelp, avhengig av hvilken teknologi tjenestebussen er implementert med. Timere kan for eksempel være nødvendige å implementere eksternt.

Så, hvor vil du at jeg skal plassere intelligensen?

Det blir nok mye opp til deg selv å vurdere hva som vil passe deg og ditt behov best. Forhåpentligvis har du nå fått nyttige innspill til vurderingen.

Spørsmål man bør stille seg, er blant annet hvor viktig det er å holde tjenestebussen ”ren” og tilstandsløs. Og videre, hvor kompleks er prosessen som skal implementeres? Er det egentlig bare snakk om å ha litt hukommelse?

Spørsmål man bør stille seg, er blant annet hvor viktig det er å holde tjenestebussen ”ren” og tilstandsløs

Har du ikke tidligere vært inne på tanken om en prosessmotor, så er det kanskje akkurat det du trenger. Eller omvendt, dersom du har satt deg fast i et spor hvor prosessmotor alltid er løsningen, kanskje du kan se på de andre alternativene. Under gitte omstendigheter er alle potensielle plasseringer i den innledende figuren reelle muligheter, noen dog hyppigere enn andre.

Føler du deg i stand til å forsvare valget ditt når du tar et?