Blogg
Här finns tekniska artiklar, presentationer och nyheter om arkitektur och systemutveckling. Håll dig uppdaterad, följ oss på LinkedIn
Här finns tekniska artiklar, presentationer och nyheter om arkitektur och systemutveckling. Håll dig uppdaterad, följ oss på LinkedIn
Handlar egentligen SOA om applikationsarkitektur? Eller ens om systemarkitektur? Martin Folwers Bliki, har en artikel om fenomenet Application Database.
Där beskrivs karaktärsdrag hos en Application Database relativt en Integration Database. Artikeln avslutas med följande mening:
As people discuss Service Oriented Architecture a common term is that of an autonomous application - which seems to imply an application whose data is stored in an application database.
Jag Googlade på “SOA” och “application database” för att hitta något exempel på en sådan association. De mest tydliga jag hittade, var en artikel hos Microsoft om ett mönster man kallar Fiefdom.
Artikeln definierar autonoma applikationer med en “egen databas” som typfallet för implementation av en tjänst inom ramen för en SOA. Applikationen finns kvar som fundament. Dessa kan publicera tjänster till olika former av konsumenter. Det finns nog de (även om jag inte tillhör den skaran) som ser en motsats i begreppen applikation och SOA.
Nej, det är nog så att SOA i praktiken handlar mer om integration än om applikationsarkitektur. Praktiska aspekter så som transkationshantering (dvs robusthet) sätter gränser för granulariteten i en SOA. Artikelns (Microsofts) sammanfattning av transaktionsbegreppets inverkan på tjänsters granularitet (och indirekt rättfärdigande applikationens fortlevnad som entitet i en SOA), känns mitt i prick!
Sedan återstår förstås frågan om hur stora applikationerna ska vara, i termer av informationsmässigt ansvar och hur applikationskartan ska se ut i stort. Det är kanske där de viktigaste fundamenten läggs för en SOA? Och visst är det ansvaret för en Enterprise Architect, snarare än en Application Architect?
En enskild applikation kan dock vara en enorm investering (journalsystem, produktionsplanneringssystem etc) i sig själv. Värden som återanvändning, automicitet, testbarhet, versionshantering, modularisering etc kan kopplas till verksamhetsvärden, så som kvalité, utvecklingskostnad, förvaltningskostnad och anpassningsbarhet till yttre förändringar. Artikeln (från Microsoft) indikerar att SOA inte adresserar dessa värden på ett adekvat sätt inom en applikation. Artikeln har några år på nacken. Om den skrivits i dag, och kanske av någon annan än Microsoft, vore en referens till Service Component Architecture naturlig. Det är en term som ofta används för att beskriva en komponentbaserad ansats som ska hjälpa applikations-arkitekter att nå ovan nämnda värden, utan att fastna i infrastrukturella utmaningar.