70-årenes feil på 90-årenes plattform

---

Mange av dagens klient/tjener-prosjekter ser ut til å være igangsatt under mottoet: "play now -- pay later".

---

Forretningskritiske applikasjoner er applikasjoner som driver virksomheten -- stopper disse, stopper også virksomheten. Krav til gode og stabile svartider og høy tilgjengelighet er viktig. Disse applikasjonene oppdaterer de sentrale databasene i virksomheten. Ofte er det her snakk om heterogene databaser spredt på ulike plattformer. Krav til dataintegritet og konsistens er her et krav som ikke kan fravikes. Den dag en virksomhet ikke kan stole på sine vitale data, den dag har IT avdelingen for godt spilt fallitt. De fleste virksomheter er også avhengig av at denne typen applikasjoner raskt kan endres og tilpasses nye krav. Dette gjelder både funksjonelle og tekniske krav.

Mange opplever at i skifte fra enkle beslutningsstøttede klient/tjener-løsninger til forretningskritiske applikasjoner, må tidligere verktøy og annen programvare skiftes ut med store utgifter både til leverandører og ikke minst også intern opplæring.

Er det så mulig å angripe dette på en mer strukturert måte. Svaret er et ubetinget JA. IT har utviklet seg stort over de siste 25-30 år, men det er en "sannhet" som består og som vil bestå også videre. Det er uttrykket "transaksjon". En transaksjon er nøkkelen i alle forretningskritiske applikasjoner og finnes i alle bransjer.

En transaksjon er basert på fire elementer: Atomicity, Consistency, Isolation and Durability (ACID).

Atomicity:

Transaksjonen er alt-eller-ingenting. Hele transaksjonen må utføres --

eller alt må tilbakestilles. Delvis ferdige transaksjoner kan ikke

aksepteres

Jfr. ekteskapsløftet, en er ikke gift før begge parter har svart ja i kirken

(two-phase-commit)

Consistency:

Etter at en transaksjon er normalt avsluttet må alle systemer som har

vært involvert være i korrekte og stabil status -- dvs. ingen uavsluttede

oppdateringer etc. (debit=kredit)

Isolation:

Transaksjoner som utføres samtidig oppfører seg som om de

utføres i serie

En transaksjon ser ikke andres transaksjoners `delresultater'

Durability:

Når en transaksjon er normalt avsluttet, er alle endringer varige og vil

overleve eventuell systemfeil.

Transaksjonen bygger på avtaler (som en kontrakt).

Det var en selvfølgelighet at såkalte on-line-applikasjoner laget på 80-tallet bygget på ACID-begrepet. Transaksjonsmonitorer (TP-monitor) som CICS, IMS og IDMS/DC var nettopp utviklet med dette for øyet. Programmerere uten relevant "transaksjons"-bakgrunn, tror at dagens løsninger kan lages uten tilsvarende "middleware". Sannheten er at det ved distribuerte klient/tjener-applikasjoner hvor applikasjonsservere og databaser kan være spredt på et stort antall fysiske servere, er behovet for den funksjonalitet som TP-monitorer kan tilby, langt større enn i den tradisjonelle stormaskinverden.

Ingen av databaseleverandørene i klient/tjener-markedet har til hensikt å lage sine egne TP-monitorer. Til det ligger utviklingen på dagens TP-monitorer for mange år foran. Isteden forsøker noen å legge deler av funksjonaliteten inn i basen. Mens programmerere, ukjente med TP-monitorer, gjenoppdager behovet og prøver å programmere seg rundt problemene. I mange prosjekter utgjør slike hjelperutiner egentlig en mer eller mindre vellykket lokal TP-monitor med de vedlikeholdsproblemer dette medfører. De eldste innen IT-bransjen vil huske at det også i 70-årene ble utviklet mange "skreddersydde" lokale TP-monitorer. Ingen av disse er i drift i dag. De fleste ble konvertert til CICS eller IMS midt på 80-tallet.

I tillegg til de rene ACID-funksjonene, vil en TP-monitor også utføre skedulerings-oppgaver og "load-balancing"-oppgaver. Stabil støtte til disse oppgavene er en absolutt nødvendighet for forretningskritiske høyvolums transaksjonssystemer.

Leverandørene av distribuerte databaser har innsett at rene databaseløsninger med SQL API ikke er tilstrekkelige. For å bøte på dette har de innført begreper som: stored procedures, triggers og rules. Verktøyene som benyttes til dette er spesifikke for hver databasleverandør. Verktøyene er proprietære og løsningen er ikke flyttbare. Ulike deler av applikasjonen må skrives i totalt forskjellige verktøy. Jo viktigere applikasjonene blir for forretningsdriften, jo mer komplekse blir denne typen løsninger og alle drømmer om fleksible og "vedlikeholdsfrie" løsninger blir gjort til skamme.

Noen mener å tro at begreper som DCE (Distributed Computing Environment), MQ (Message Queuing) eller DOM (Distributed Object Managers) skal løse problemene. Slik er det dessverre ikke. Innføring av disse teknikkene vil bare gjøre det enklere å utvikle mer komplekse applikasjoner der behovet for transaksjonsmonitorer er enda større.

Det hevdes også ofte at løsninger basert på TP-monitorer koster mer enn tradisjonelle rene databasebaserte løsninger. Dette er også en misforståelse. Dersom en baserer sine løsninger på TP-monitorer, vil antallet nødvendige database-tilknytninger for en gitt arbeidsmengde bli dramatisk redusert. Lisenskostnader for antallet samtidige klienter reduseres betydelig.

Utviklingstiden for store komplekse klient/tjener systemer kan også reduseres med ca. 50 prosent da kompleksiteten reduseres. Totale besparelsene her kan bli store. Standish Group i USA har estimert de totale kostnadene for et TP-monitor basert klient/tjener system til mellom 30 - 50 prosent lavere enn tilsvarende løsninger basert på annen mekanisme.

Større organisasjoner som planlegger å utvikle forretningskritiske klient/tjener-applikasjoner eller "rightsize"-deler av sine applikasjoner, bør revurdere sine valg av utviklingsverktøy og middleware for å ta høyde for de utfordringer som det her kort er pekt på. I 70-årene kunne en gjemme seg bak uvitenhet og mangel på programvare. Slik er det ikke i dag.

Det finnes transaksjonmonitorer på markedet som bygger på den såkalte X/Open's XA protokoll. CICS, Encina, Top End og Tuxedo er eksempel på slike. CICS kan eksempelvis kjøres på HP, DEC og Sun-plattformer i tillegg til IBMs egne plattformer. Det finnes også utviklingsverktøy som NETRON/Fusion og HPS som støtter denne typen transaksjonsmonitorer. En del GUI-verktøy har også lansert støtte for tradisjonelle TP-monitore uten at dette er lagt vekt på i det norske markedet.

Enhver IT-ansvarlig bør stille kritiske spørsmål til sine utviklere hvor "syrlige" (ACID) de ferdige klient/tjener-løsningene er. Eventuelt bør det søkes råd hos erfarne konsulenter innen området. Dette vil bidra til å unngå store nye IT-skandaler i fremtiden og spare norske bedrifter for 3-sifrede millionbeløp. STEIN STøLEN, MARKEDSSJEF I IDC INTEGRERT DATA CONSULT

:

90 prosent av dagens klient/tjener-løsninger er basert på database-servere, ofte kalt TP-lite. Behovet for TP-monitorer, TP-heavy, er voksende og vil sannsynligvis dominere når det gjelder kritiske og høyvolums applikasjoner fra 1996 og utover i 90-årene.

Artikkel automatisk generert, 07/12-95, kl. 17.43 cw@oslonett.no