Det har alltid funnits ett stort gap mellan problembeskrivaren och problemlösaren när det kommer till programutveckling. Det gapet har med tiden försökts att överbryggas på alla tänkbara sätt. Problem beskrivs av personer som har kunskaper inom problemdomänen, medan lösningen skapas av personer som har kunskap i verktygen som används för att konstruera lösningen.
En väg att minska gapet och som fått alldeles för stort genomslag är CASE-verktygen, som exempelvis Rational. I ett CASE-verktyg enas problembeskrivaren och problemlösaren i ett gemensamt språk och metodik som ex. UML/RUP. Det finns generellt sätt mängder av problem med den här typen av modeller, men i synnerhet ett som har förpassat UML & Co till 90-talet. UML kan nämligen inte exekveras!
Att UML inte kan exekveras har man försökt att åtgärda med hjälp av kodgenerering. Det blev aldrig, av förståliga skäl, någon hit eftersom den genererade koden inte fick några fans bland utvecklarna som hela tiden låg steget före med ny teknik. UML är även ett problem med tanke på underhåll eftersom man blev tvungen att underhålla både kodbasen och modellen. UML nådde heller inte fram till roten av problemet, att minska gapet, utan skapade istället två nya raviner. Det första mellan problembeskrivaren och modellen, men även mellan modellen och problemlösaren. Den fylldes med nya roller som titulerade sig analytiker, kravhanterare och andra former av "fördyrande mellanhänder".
DSL (Domain Specific Languages) är ett annat sätt att minska gapet. Det går ut på att skapa språk som kan exekveras samtidigt som det närmar sig problembeskrivaren genom att "prata" samma språk som honom. Det viktiga med DSL är just att det, precis som UML, ska ge möjligheten att modellera inom problemdomänen samtidigt som det ger ett resultat som kan exekveras.
Ett enda språk kan inte lösa alla problem. Därför måste det finnas en mängd språk som på olika nivåer skapar lösningen. Vissa språk är nära problembeskrivaren och andra är närmare tekniken. Det är lite som idén med .NET (även om MS väljer att ersätta alla andra programspråk med C#) där flera språk enas runt en exekveringsmodell, tillskillnad från Java där alla kodare enas runt ett språk som ska passa alla problem.
En SOA är ett nätverk av komponenter av DSL:er som samspelar med det gemensamma i Web Services. Web Services ger även möjligheten att konstruera arkitekturer av komponenter utvecklade för olika exekveringsplattformar, vilket betyder att man kan uppnå fördelarna med .NET utan att för den delen vara fullt beroende av en exkeveringsmodell.
Skikten av språk som används, nära problembeskrivarens domäner ned till tekniken skiljer sig mellan en traditionel arkitektur och en SOA. I en klassisk skiktad arkitektur så finns en hierarki där ju närmare problemet man kommer desto mer finns behovet av DSL:er. Att knyta samman alla språken i ett gemensamt meta-språk kommer säkert ge de stora leverantörerna något nytt att bråka om framöver (se SCA och SDM).
Oavsett vem som bygger det ultimata meta-meta-meta-...-språket så är en SOA ett klockrent exempel på hur olika DSL:er samspelar i en arkitektur. Där finns det nämligen ingen hierarki som avgör vem som orkestrerar vem. En SOA är ett nätverk och inte en skiktad arkitektur.
Inga kommentarer:
Skicka en kommentar