Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den CTO d. 2. juni 2006.
IKKE OVERALT For Mark Information er SOA en bedre metode til at integrere virksomhedens kernesystem med andre applikationer. Men teknologien er ingen patentløsning, der skal indføres overalt.
Softwarehuset Mark Information vil gøre det nemmere for kunder og samarbejdspartnere at få adgang til data i virksomhedens applikation. Derfor er den ved at omskrive dele af applikationen til en serviceorienteret trelagsarkitektur. Men udviklingsdirektør Niels Bredegaard ser ikke SOA som den hellige gral, der kan løse alle problemer. Tværtimod er der dele af applikationen, som ikke skal omskrives til SOA.
- For os er SOA en løs arkitektur af forretningslogikkomponenter, som understøtter og eksponerer services for tredjepartsinteressenter. Tredjepartsinteressenter kan være andre it-systemer, som modtager data fra vores system eller lægger data ind i det, siger han.
Dermed er vægten klart lagt på integrationen. For Mark Information er SOA et middel til at gøre det lettere at integrere firmaets produkt, ProMark, med produktionssystemer, ERP-systemer og andre applikationer.
ProMark er en applikation, der opsamler og bearbejder data fra maskiner, medarbejdere, materialer og it-systemer. Den bruges for eksempel til at planlægge en produktion med, eller til at beregne akkordlønnede medarbejderes arbejdstid og løn. Derfor er integration en naturlig del af applikationen: Den skal kunne kommunikere med en række andre systemer. Den nuværende version af ProMark er integreret med godt 60 forskellige systemer.
- For øjeblikket er vi lidt fastlåst, både når det gælder opsamling og viderelevering af data. I mange tilfælde skal vi modtage og levere data i formater, vi ikke er så glade for, for eksempel som flade filer. Med webservices får vi en ensartet integration, hvor vores system kan kobles tættere ind i andre systemer, siger Niels Bredegaard.
Projektet omfatter to grundteknologier: ProMark skal omskrives til en trelagsarkitektur, og det skal blive serviceorienteret ved hjælp af webservices. For øjeblikket har ProMark to lag: En klientdel og en serverdel. Den kommende version får tre lag: en klientdel, der samtidig bliver integrationsdel, en applikationsserver og en database.
- Den trelagsarkitektur giver helt naturligt et solidt fundament for en serviceorienteret arkitektur. Men vi omskriver ikke hele applikationen til SOA, siger han.
Som eksempel nævner han opgaven med at oprette akkordaftaler til en medarbejder i systemet. Det vil altid være en intern opgave, som de færreste virksomheder vil have brug for at give andre systemer adgang til. Derfor bliver der ikke en webservice, der giver mulighed for at oprette akkordaftaler til en medarbejder.
Hele den store beregningsmotor, der er selve hjertet i ProMark, omskrives heller ikke til webservices. I stedet skriver udviklerne en række webservices, der giver adgang til udvalgte funktioner i beregningsmotoren. Det skyldes især hensynet til ydeevnen:
- Når man skal håndtere meget store datamængder, får man for dårlig performance i en ren servicearkitektur. Når vi afvikler store beregninger på applikationsserveren, vil vi ikke operere via service requests, det vil simpelthen køre for langsomt, siger Niels Bredegaard.
Han forklarer det med, at hver gang en webservice modtager en forespørgsel, skal den kontrollere, at afsenderen nu også har lov til at få svaret. I en traditionel applikation autentificeres brugeren kun én gang, hvorefter han kan udføre alle de beregninger, systemet giver ham lov til.
Ydeevne er vigtig, fordi mange af systemerne anvendes af akkordlønnede medarbejdere i produktionen. De har ikke tid til at vente længe på, at systemet reagerer.
ProMark er skrevet i fjerdegenerationssproget Progress. Derfor var det naturligt for Mark Information at fortsætte med Progress, da applikationen skulle omskrives til den nye arkitektur. Her bruger man udviklingsplatformen OpenEdge, der er en Progress-indgang til Eclipse-miljøet. Så udviklernes brugergrænseflade er en Eclipse-klient, mens sproget er Progress 4GL.
- Det giver den fordel, at hele håndteringen af data er ekstrem stærk. Til gengæld savner vi nogle af de smarte muligheder for design af brugergrænseflader i Visual Studio, som det ville være rart at få fat i, siger Niels Bredegaard.
Netop datagrundlaget er et af nøglepunkterne i projektet. Udviklerne skal analysere, hvordan det eksisterende system behandler data, og ud fra den analyse danne en ny datamodel:
- Man kan sige, at vi i dag har en applikation, der lægger data i en database. Det er en fysisk datamodel. Nu skal vi afklare, hvilken logisk datamodel den afspejler. Og den logiske model skal vi så putte ned i en ny fysisk model, der understøtter SOA, forklarer Niels Bredegaard.
Projektet er delt op i mindre, overskuelige bidder. Den første fase går ud på at flytte hele beregningsmotoren over på applikationsserveren og eksponerer 10-15 webservices, der kommunikerer med den. Den fase ventes færdig til november. Hele projektet er estimeret til at tage syv-otte mandår. Niels Bredegaard regner med, at det er færdigt om et par år.
Overgangen til SOA har betydet ændringer i måden, Mark Information udvikler på:
- Vi er blevet meget mere strukturerede. Vi bruger mere tid på at dokumentere det, vi laver. Det har også taget længere tid at komme i gang end normalt. Men det var vi forberedt på. Selvfølgelig er det altid vigtigt at specificere og dokumentere, men i SOA og trelagsarkitektur er det altafgørende - ellers kan andre jo ikke vide, hvordan de kan bruge de webservices, vi eksponerer, siger han.
Til gengæld gør SOA og trelagsarkitekturen det muligt at ansætte specialister på for eksempel brugergrænsefladesiden. Udviklerne behøver ikke længere kende alle hjørner af applikationen, når den består af klart opdelte moduler med veldefinerede grænseflader.
Niels Bredegaard advarer om en fare ved teknologien:
- Man risikerer at blive alt for maskinel i udviklingsprocessen. Så bruger man al sin tid på at dokumentere i stedet for at skrive kode, siger han.
Hvis en organisation skal få succes med SOA, skal den vide præcis, hvad den vil opnå.
- Organisatorisk og styringsmæssigt er det en stor opgave. Man tager fejl, hvis man tror, at det bare er en ny teknologi, det er en helt ny måde at designe en applikation på, siger han.
Han har disse råd til firmaer, der overvejer at gå i gang med SOA:
- Gør det, som man altid burde gøre før nye projekter: Lav en business case og afklar, hvad man vil opnå. Men brug dobbelt så lang tid som normalt. Det samme gælder ved uddannelse, dokumentation og fastlæggelse af systemets struktur, her skal man også afsætte dobbelt tid. Den investering i tid kommer igen senere, når produktiviteten stiger eksponentielt, siger han.
Samtidig advarer han mod at begynde at kode for tidligt:
- Det er simpelthen livsfarligt. Hvis man i starten får defineret et datasæt forkert, vil det give problemer i hele resten af processen.
Billedtekst:
gevinster — Når vi er kommet længere i overgangen til trelagsarkitektur og SOA, kan vi begynde at høste gevinsterne. Så bliver det nemmere at tilføje ny funktionalitet og integrere med nye systemer, siger Niels Bredegaard fra Mark Information.
OriginalModTime: 01-06-2006 13:08:22
