torsdag, december 22, 2005

SOA-kartläggning

För ett tag sedan skrev Tamina Vahidy en artikel om resultatet av en undersökning som gick ut på att kartlägga vilka komponenter som användes mest för att uppnå en SOA.
  • 71% Web Services
  • 61% Portalramverk
  • 46% Applikationsserver
  • 43% Integrationsramverk
  • 36% Säkerhetsramverk
  • 18% Analysramverk
  • 18% Datacentralisering
  • 14% ESB
  • 14% BPM
Tamina konstaterar "- That's an excellent illustration not just of how companies are building SOA, but of SOA's complexity". Hon säger att SOA är inte en applikation, utan en paradigm. SOA är allt ovan, från portalramverk till datacentralisering. Det är det som gör det komplext!

Sedan kan man ju konstatera att prioriteringarna (av siffrorna ovan att dömma) är något förskjutna mot EAI och inte de delar som implementerar det unika med en SOA, nämligen BPM och ESB. Det är bara att konstatera att vi kommer få se negativa erfarenheter av SOA så länge man inte uppnår målen med SOA. Ronan Bradly beskyller produktleverantörerna för att paketera sina gamla EAI-produkter som ESB:er, vilket jag skriver under på.

söndag, december 18, 2005

SOA och DSL

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.

onsdag, december 14, 2005

WS-Management

WS-Management (eller MS-Management) har publicerats här.

Läs mer om WS-Management här.

Enligt denna källa kommer WCF i.o.m. R2 supporteras av WS-Management.

Tjänsteorientering IV - Första steget

Att uppnå en SOA är ingen enkel omställning. Att gå från en applikationsorienterad IT-miljö till en tjänsteorienterad kräver stora förändringar inom IT.

Applikationer har karaktäriserats som en paketering av tjänster, där just paketering har ingivit en positiv trygghetskänsla. Trygghet både för den som använder applikationen, men även för den som erbjuder tjänsterna. Det negativa med applikationen är att den är som en svart låda som säger "jag erbjuder allt eller inget" i form av tjänster.

Applikationer saknar förmågan att kunna kopplas ihop med omvärlden om man inte gör det på applikationens villkor. Dels mellan lager som gränssnitt, logik och data, men även tjänstevis. En SOA måste kunna erbjuda samma trygghet som en applikationen ger, men även uppfylla de delar som anses vara negativa med applikationer. Ett tjänstenätverk måste kunna gruppera tjänster i vita lådor, eller meta-applikationer. En meta-applikation är en paketering av tjänster i en SOA som ska garantera samma trygghet man fick med en vanlig applikation.

Meta-applikationen har en rörlighet som en traditionell applikation saknar. Den består av ett tjänstenätverk som en del av ett större nätverk. Gränserna för meta-applikationen manageras av verktyg som kan upprätthålla dess förväntade tjänstenivå.




Här måste SOA börja, d v s att applikationerna förändras. Att bygga en SOA är ett jobb som arbetar sig bottom-up. Sitter man på en applikationmiljö som behöver integreras m h a en broker-lösning eller ett middleware så kan man definitivt göra det som en start. Men en SOA handlar om att få bort applikationerna och byta ut dom mot meta-applikationer i ett tjänstenätverk.

Så trycket måste ligga på applikationsutvecklarna om SOA ska bli en realitet. Tillsvidare får IT nöja sig med applikationsintegration, vilket tyvärr ändå verkar vara det enda så gått fram till IT som en definition av SOA.