Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den CTO d. 2. juni 2006.
Nye arbejdsgange SOA medfører, at systemudviklerne i højere grad skal tænke på den samlede helhed, som deres moduler skal indgå i. Hos DSB har satsningen på SOA gjort det hurtigere at udvikle nye moduler til systemintegration.Efter et par år med en serviceorienteret arkitektur har DSB Informatik gjort en klar erfaring: Kulturen udgør en større udfordring end teknologien.
Det skyldes, at udviklerne i en serviceorienteret arkitektur udvikler små moduler, der kommunikerer på kryds og tværs med andre moduler. Dermed mister den enkelte udvikler kontrollen med det, han tidligere har opfattet som "sit" system.
- Det sværeste er at overbevise folk om, at det er en god ide. Det er en stor kulturforandring, når udviklerne bliver nødt til at give slip på noget, og det er ikke sjovt for dem, fortæller udviklingschef Niels Feldthus fra DSB Informatik.
DSB valgte at gå SOA-vejen efter først at have snuset til objektorienteret programmering med Java Beans. Formålet med Java-projektet var at gøre det muligt hurtigere at levere systemer til forretningen. Det skulle ske gennem genbrugelige komponenter, der kommunikerede indbyrdes via Java Beans.
- Det viste sig, at det var meget svært at vedligeholde sådan et setup. Så i 2003 begyndte vi at se på mulighederne i SOA. Det førte til en konkurrence i 2004, hvor vi valgte Oracle som leverandør af en SOA-platform, siger Niels Feldthus.
DSB's it-systemer består af en lang række applikationer, der kommunikerer indbyrdes. Nogle funktioner er implementeret i flere systemer, andre er dannet ved at koble systemerne tæt sammen. Det gør det svært at udvikle noget nyt, fordi en ændring ikke kun får betydning for det system, der ændres, men også for alle de systemer, der er afhængige af det.
Den afhængighed skal SOA-projektet hjælpe med at fjerne. Nu oprettes der webservices, som stiller integrationstjenester til rådighed for de applikationer, der har brug for dem. Til at udvikle disse webservices har DSB Informatik oprettet et kompetencecenter for integrationsløsninger:
- Når en forretningsenhed ønsker at få gennemført en integration, henvender den sig til centret. Her sikrer man sig, at alle de relevante spørgsmål bliver stillet. Tidligere var integration ofte et spørgsmål om at forbinde et punkt med et andet, men i SOA kommunikerer mange med mange, siger it-arkitekturchef Erik Haahr, DSB Informatik.
Det kræver en ny måde at tænke på hos udviklerne. Som eksempel nævner han en integration med det centrale ERP-system fra SAP:
- Der har SAP-udviklerne skrevet en tjeneste, hvor de stiller nogle data til rådighed. De bruger SAP-funktioner til at filtrere i dataene, så der kun kommer dem, et enkelt system har brug for. Men hvis de nu i stedet stillede alle data til rådighed, kunne mange flere webservices trække på dem - så kunne filtreringen foregå på webservice-laget i stedet for i SAP, forklarer han.
Den bærende teknologi i DSB's SOA-system er programmeringssproget BPEL (Business Process Execution Language). Det er en højniveausprog, der fokuserer på forretningsprocesser. Det meste af udviklingen foregår i et grafisk udviklingsværktøj, hvor udviklerne definerer applikationens sammenhænge og forløb. BPEL-koden afvikles af Oracles middlewaresystem Fusion.
- Udviklerne bruger BPEL til at udvikle integrationspunkter. Men vi er ved at varme op under forretningen for at få den til at tegne forretningsprocesser i BPML (Business Process Modeling Language, red.). Så er der værktøjer, der direkte kan generere BPEL-kode ud fra tegningerne, siger Erik Haahr.
Foreløbig er kun en enkelt webservice i drift hos DSB. Den bruges af de systemer, der sender billetter ud til kunderne i breve. Men i løbet af i år venter DSB Informatik, at godt 100 webservices går i drift.
- Vi er stort set tilfredse med at være gået SOA-vejen. Men vi kan godt føle os lidt alene i verden nogle gange - der er ikke mange, der er gået samme vej endnu. Derfor er det også vigtigt for os, at vi har et stærkt partnerskab med vores leverandør. Vi finder mange fejl i denne nye teknologi, for der er ikke så mange andre til at finde dem, siger Niels Feldthus.
Målet med SOA var at gøre udviklingen mere effektiv, så DSB hurtigere kunne få ny funktionalitet. Det er lykkedes. Tidligere brugte DSB Informatik typisk 600-700 timer på et integrationsprojekt. Den tid er nu bragt ned på 60 timer.
Foreløbig har DSB ingen planer om at indføre UDDI (Universal Description Discovery and Integration). Det er et katalog over de webservices, der indgår i en organisations it-arkitektur.
- Behovet for UDDI vokser med antallet af webservices. Så længe vi har et begrænset antal, kan vi klare os uden, men det er da noget, vi vil kigge på i fremtiden, siger Niels Feldthus.
Den serviceorienterede arkitektur giver udfordringer for it-driften. Tidligere bestod it-systemer af få, store systemer. Typisk var et system identisk med en bestemt server. Men webservices kobles sammen af mange små moduler.
- Det gør det svært at sige, hvad det vil betyde, hvis en server går ned. Så skal man først vide, hvilke tjenester der er afhængige af de tjenester, der kører på den, siger Erik Haahr.
Til gengæld passer webservices rigtig godt sammen med servervirtualisering. Her kan en enkelt fysisk server opdeles i flere logiske, der kører hver sit sæt af webservices. Derfor kigger DSB Informatik nu meget aktivt på VMwares og andres virtualiseringsløsninger.
Billedtekst:
Travlt I løbet af i år sætter DSB 100 webservices på skinnerne. Foto: René Strandbygaard
OriginalModTime: 01-06-2006 13:14:05
