SOA: Inte bara för Powerpoint-konsulter

Ofta får man höra att SOA är en arkitektur som passar för som man säger programming in the large. Det skrämmer en vanlig kodare som än själv ;) SOA är en arkitektur som skalar från det man normalt implementerar i en klass upp till orchestration på en hög nivå. SOA kryper in under skinnet och sträcker sig långt ned i det som vi idag kallar applikationer. SOA är en applikationsarkitektur lika väl som en enterprise arkitektur.

Så till alla programmerare: SOA är inte värt vatten om det inte börjar med att implementeras på applikationsnivå. SOA är inte bara för Powerpoint-konsulter.

O.b.s. Ser du en web sida som beskriver BPEL eller SOA som en teknik för att integrera applikationer med en service façade så anmäl den här ;)

SOA: Var går gränsen?

När SOA ska definieras hamnar man ofta i en diskussion som handlar om ytterligheter. Vart tycker du att SOA hamnar mellan de här två ytterligheterna?

1. En komplex enhet som innehåller all funktionalitet och data.
2. All funktionalitet och data representeras i oändligt många små okomplexa tjänster.

Jag vågar nästan säga att alla nog anser att det borde ligga någonstans i mitten. Men vad är det som bestämmer hur många tjänster som ska byggas i en SOA och vad ska tjänsterna göra?

Processer! Det är processerna som bestämmer. Finns det processer som kräver funktion och data, så ska det finnas som en tjänst. Finns det processer som kräver andra processer så ska de finnas som tjänst. Finns det flera processer som kräver samma funktion och data så ska det finnas tjänster. Det är processerna som avgör hur många och vilka tjänster som krävs.

Service Oriented Architecture skapas med Process-driven design (top-down el. outside-in).