Neward sparkar på ORMen

Det är få gubbar som är så pass underhållande att lyssna till som Ted Neward. I .NET Rocks! diskuterar han objekt-RDB-mappning där samtalet ibland hettar till ordentligt med en kille som jobbar med nHibernate.

Lyssna här!

Separation of Concerns

Deltog i en diskussion om vad man med skiktade arkitekturer kan åstadkomma för att skapa föränderlighet i systemen vi bygger.

Förändringar i systemen sker alltid på sikt, men frågan är vilka förändringar. Antag två typer av förändringar, funktionella och tekniska:

Funktionella förändringar

• Regler - att kunna göra tillägg och förändringar av villkor i systemet som representerar affärsregler
• Processer - att ändra sekvensen av aktiviteter i en affärsprocess
• Information - att göra tillägg av nya informationsfält i den existerande datastrukturen
• Resurser - att i systemet ändra från att använda en viss resurs/tjänst till att använda en helt annan
• Händelser - att i systemet kunna hantera händelser som inte var påtänkta från början

Tekniska förändringar

• Applikationsserver - ex. ändra från IIS till Apache/Tomcat
• Databasserver - ex. ändra databasserver från SQL Server till MySQL
• Protokoll - ex. ändra kommunikationsprotokoll mellan logiska enheter i systemet
• Plattform - ex. flytta applikationen från Windows till Linux
• Hårdvara - ex. göra en tech-refresh av hårdvaran
• Säkerhet - ex. man vill göra applikationen åtkomlig över internet
• Dimensionering - ex. lyfta applikationen från 100 användare till 10000 användare
• Integration - ex. att man vill exponera funktioner och dataåtkomst via API:er
• Utökning - ex. bygga in nytt klientstöd för PDA:er och mobiltelefoner

Jag menar att lager inte tillför något för funktionella förändringar i systemet. Då krävs det istället att man skapar egna logiska enheter för regler (Business Rules Management), processer (Business Process Management), information (Master Data Management), tjänster (Service Oriented Architecture) respektive för händelser (Event Driven Architecture). På det viset åstadkommer man SoC (Separation of Concerns) som skapar förutsättningar för systemet att växa med uppgiften.

Den skiktade arkitekturen kan inte alls svara upp mot funktionella förändringar, utan passar bättre för de tekniska kraven. Att kunna skapa nya lager eller att ersätta lager ger fördelar då man vill byta ut och lägga till teknik. Dimensionering kan hanteras genom att man skalar ut/upp runtime-miljön för ett lager. Hårdvaruvirtualisering bygger på skiktning i arkitekturen.

Framför allt tror jag att skiktade arkitekturer är populära för att man kan skapa 'Separation of Skills', dvs att vissa roller i exempelvis ett webutvecklingsprojekt kan jobba inom olika areas of interest, som man säger.

Visst kommer de tekniska förändringarna att kvarstå, men det är inget man tappar bara för att man inte bygger en traditionell skiktad arkitektur. Tvärtom så kommer SoC-design passa bättre även för de tekniska kraven.

Ser man till hur en skiktad design med lager på lager skulle hantera funktionella förändring så kan komplexiteten i relation till förändringstakten kunna se ut så här:


Tryggast är väl att det mest komplexa att ändra dvs processer kanske inte ändrar sig så ofta. Men det kan ju bero på att IT sitter och bromsar affärsutvecklingen med system som är byggda med skiktade arkitekturer.

Skapar man däremot en design där man skiljer de funktionella förändringarna åt logiskt så skulle det se annorlunda ut:

Väntar du också på bussen?

Väntar du också på en Service Bus som bygger på WCF? Medan du väntar så ta en titt på WSO2. Här får du all funktionalitet från Synapse på ett snyggt GUI för administration, men bäst av allt är att du inte behöver skriva en enda kodrad Java.

Läs mer på Paul Fremantels blog.

Kategorisering av tjänster

En gång i månaden kommer The Architectural Journal med en ny utgåva. I nummer 11 finns det en artikel som hetter Ontology and Taxonomy of Services in a Service-Oriented Architecture där Shy Cohen beskriver vilka typer av tjänster som en Service Oriented Architecture byggs upp av:

Bus Services

• Communication Services - intermediära (mellan tjänster) tjänster som message routing, pub/sub, m m
  
• Utility Services - tjänster för Service Discovery, Identity Federation, m m

Application Services

• Entity Services - tjänster som exponerar data entities
  
• Activity Services - tjänster som exponerar affärsspecifika funktioner
  
• Capability Services - tjänster som exponerar generella funktioner
• Process Services - tjänster som exponerar affärsprocesser

Jag har lite svårt för olika försök (som det här) att generalisera över en kategorisering av tjänster. Beroende på vad man vill åstadkomma så kommer ett antal Application Services att behöva implementeras. Shy's Application Services må passa i ett visst scenario men är i ett annat förmodligen helt irrelevanta.

Tror det återigen är viktigt att peka på att syftet med SOA inte är att kategorisera och generalisera över vilka tjänster man ska bygga, utan att se det som den infrastruktur som de s.k. Bus Service ska implementera. Dessutom är det lite väl sent att komma dragande med den här typen av artiklar nu när tekniken finns, kunderna är redo och det är dags att konkretisera istället för att flumma kring metaforer och ontologier.