Efter att ha fått höra akronymen SOA så pass mycket att det förlorade sin betydelse så känner sig de flesta av oss kanske inte så pigga på en ny akronym med ordet ‘Architecture’ i. Härom året fick jag höra att IBM försökte få ut SCA (Serivce Component Architecture) som en ny akronym som skulle ersätta det söndertjatatde SOA, men det visade sig vara i princip samma sak. Dock känner jag mig betydligt mer positivt inställd till den relativt nya akronymen EDA, d.v.s. Event-Driven Architecture. För er som var på JFokus i Stockholm förra veckan så kan hända att ni fick en introduktion till vad det hela var, för er andra så gör jag ett försök att sammanfatta det här.

Som namnet antyder så har det att göra med att saker sker ”händelsestyrt”. Enklast är väl att beskriva det hela med hur det skiljer sig från ”vanlig” SOA, där vi kopplar samman ett gäng tjänster (t.ex. Web Services) som vanligtvis är synkrona (request/response) eller har Message Queue som triggar tjänster asynkront (d.v.s vanlig JMS). Med EDA så gör man istället som så att man lägger händelser, elelr ”Events”, på en kö och låter alla lyssnare på kön hantera dessa som de själva anser vara bäst. Kön blir då en enda stor informationskanal som alla ”tjänster” i systemet lyssnar på. Med en Enterprise Service Bus så bygger man upp logik hur ett affärsflöde ska gå, d.v.s. vilka tjänster som skall anropas och i vilken ordning. Med EDA så behöver vi inte bygga upp någon sådan logik. Tjänsterna i systemet behöver inte heller addressera någon annan eftersom alla lyssnar på alla meddelanden.

Låter enkelt, eller hur? Tyvär gör ju ofta en förenkling på en sida att man förlorar något på en annan sida. I detta fallet när allt är helt asykront så blir det ju rätt komplicerat att göra felhantering. Sen har vi det där med att bygga allting asynkront. Flödet i applikationen blir ju inte riktigt lika självklart.

Den främsta anledningen till att vi vill bygga systemet med EDA har dock med prestanda att göra. Om vårt system är helt synkront så får vi inte plats med så värst många samtidiga anrop som om vi bygger det asynkront. Med dagens och framtidens moderna processorer så får vi också fler och fler kärnor, vilket gör det väldigt lämpligt att bygga system på det här viset.

En intressant sak med EDA är att man kan designa en applikation enligt detta koncept, d.v.s. låta applikationen tråda loss saker och ting utan att man själv behöver hålla koll på synkronisering i lika hög grad som man måste göra med ”traditionell” trådning. Låt dina ”Events” vara atomära operationer och lägg dem på en i en kö (förslagsvis någon i java.util.concurrent) och låt därefter lyssnarna exekvera dem. Detta ska inte missuppfattas som producer/consumer, där ett meddelande på kön är tänkt att aktivera en händelse (d.v.s, mottagaren implementerar opreationern tillskillnad från meddelandet).

Ok, så det var lite kort om vad det hela handlar om. Det finns en hel del intressanta artiklar att läsa. Vad det gäller implementationer av plattformar med stöd för detta så kan man använda sig av en vanlig ESB. Vissa av dessa har även speciellt förberett stöd för EDA, såsom ServiceMix. Hursomhelst så är detta något som jag tror vi alla kommer få läsa mer om framöver, så det kan ju vara bra att börja kolla på det redan nu.