Efter att ha varit inblandad i flertalet disskusioner och hört talas om flertalet andra så tänkte jag slänga ut en liten fundering.

Microsoft och en del företag runt Microsoft pratar väldigt mycket om SOA, lyssnar man på vissa föreläsare så låter det som om SOA var svaret på alla problem inom mjukvarubranschen (ungefär som de flesta sa om COM/DCOM när det begav sig)

Personligen så tycker jag att det här synsättet är farligt och delvis felaktigt.

SOA är ett alternativ i arkitekturvärlden, inte ett dåligt alternativ, men likväl ett alternativ. Microsoft lyfter fram sitt alternativ ganska starkt nu, men det gör att vi inte få glömma eller tappa andra alternativ. För varför finns det alternativ?

- För att vi skall kunna anpassa oss till situationen, så klart.

Med en enkelspårig arkitekur så får man enkelspåriga lösningar och enkelspår leder ofta till återvändsgränder.

När grundbulten i SOA, Web Services, låg i sin vagga, så var det som svar på ett problem. Problemet handlade om interopabilitet mellan olika system på olika plattformar. Att tex få ett system baserat på COM/DCOM att kommunicera med en CORBA lösning var ett riktigt aber. I de här fallen är Web Services det förlovade landet och SOA absolut en väg att gå.

Men det innebär inte att det är enda arkitekturen vi bör hålla oss till. Jag hävdar bestämt att SOA är bra för interopabilitet mellan system men bör inte, av skalbarhets- och prestandaskäl, vara vår lösning för tex intern kommunikation i våra system. I alla fall inte i dagsläget.

Jobbar man i en sann OOP/OOA miljö så kan Web services vara ett bra kompliment till vårt system.

ex;


______
| Data | (Db eller annan store)
-------
|
|
______
| DAL | (DAL, DAO, O/R M, Infrastructure osv )
-------
|
|
-------
| BOL | (DOMAIN Model, Bussinees Layer, Infrastructer osv)
-------
| ------
| ---------------------------------- | WS | (Integration Point)
______ -------
| App | ( Application Layer, Infrastructure )
-------
| ------
---------------------------------- | WS | (Integration Point)
------

Men i övrigt så bör man även lära sig jobba med objekt orienterade patterns and practices, titta på remoting och andra alternativ för system i homogena miljöer.

(upd: Fick stryk för att WS även kan nyttja application layer )

Mkt intresant och jag vill bara säga att jag håller med dig.

/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.com

Patrik,

Mycket trevligt initsiativ med dina inlägg i denna gruppen! Skall se om jag inte hinner med att skriva ett par ord här också under veckan.. lite körigt just denna veckan, mycket som skall vara klart på fredag om man säger så =P

Ja kan inte säga emot de redan inkomna kommentarerna.
Lustigt, för jag tänkte själv skriva ett inlägg nu när jag kom hem, har funderat hela dagen på nått bra ang DDD vs SOA etc...

Bad även Pelle i morse att skapa upp en DDD samt TDD forum, men inte fått nått svar. Får väl se om det blir av.

Mvh Johan

<b>pelle kommenterar:</b>
Jag föreslår att ni postar i .net arkitekturforumet och om det börjar svälla upp kan vi bygga fler sektioner men innan vi fått in nåt hundratal postningar tror jag vi kan ligga kvar i detta tills vidare. Att sätta upp för många forum som inte används är onödigt - så upp till bevis, var aktiva så går jag er till viljes sen :-)

Kunde inte hålla med mer - exakt så tycker jag att en bra systemarkitektur ska se ut!

Det enda jag gör annorlunda är att sätta databasen underst! :-)

Just att använda Web Services som Integration point till BOL är en mycket bra ide tycker jag. För mindre/enklare system som dessutom är web-baserade är det i min mening overkill, men för ett stort och helst skalbart system är det en mycket gedigen arkitektur!

/Mats

Hej

Vet inte om detta hör hemma i den här tråden men men..

En sak som gör mig lite konfundersam med SOA är hur man skall hantera transaktioner. Säg att jag har ett planeringssystem för taxibilar eller något likanande, i programmet så vill jag registrera fakturor i företagets system genom en webbtjänst på det interna nätet. Båda "processerna" är lika viktiga, får jag fel då jag sparar en körning så skall jag inte skicka en faktura osv..

Men det finns inget rekommenderat sätt att lösa detta på, i varje fall inte som jag sett. Eller är detta ett fall där SOA inte är lämplig som lösning?

Det finns in dagsläget ingen standard för hur man skall kunna låta flera webservices ingå i en transaktion.

Det finns ett antal förslag och ett fåtal proof-of-concept implementationer men ingen har riktigt lyckats.

Tänker man efter så är det inte så konstigt.

HTTP är ett tillståndslöst protokoll. Det vill säga alla anrop är "fire and forget". För att kunna klara av distribuerade transaktioner så krävs det "Two-phase-commit" vilket innebär kommunikation fram och tillbaka med den kontrollerande tjänsten.

Två vägskommunikation i flera omgångar och HTTP rimmar ganska illa :) ...

Det här är dock ngt som arbetas på, vi får se vad Indigo grabbarna och tex IBM kommer fram till ...

Hmm, så vitt jag förstår så behöver du inte alls välja att utveckla med SOA ELLER DDD utan istället så kan du implementera en SOA-lösning med hjälp av DDD.

De centrala delarna i en SOA lösning är separerade autonoma applikationer som mycket väl kan implementeras med hjälp av DDD men som däremot inte behöver eller bör exponera sin interna struktur. Istället exponerar dessa autonoma applikationer de gränssnitt som de själva vill ska användas för kommunikation, både när det gäller datatyper och metoder.

Jag kan till och med se stora fördelar att använda DDD vid utveckling av en SOA-lösning eftersom jag är en stark förespråkare av meddelandeklasser som exponeras med hjälp av XSD, och med de sätt som jag visat under höstens roadshow så borde det vara "enkelt" att applicera de serialiseringsattribut som krävs på våra domänobjekt för att de ska kunna hanteras korrekt.

Det är precis samma sak med SOA vs Objektorienterad Programmering, vi använder OO för att implementera SOA!

Eller är det helt enkelt så att jag inte fattat ett dugg vad DDD går ut på?

Nejdå du har i stora delar rätt, vs var nog pedagogiskt fel ..

Meningen var att försöka belysa att SOA _inte_ var den ultimata enda lösningen utan ett möjligt verktyg för integration i våra applikationer.

Framförallt ville jag trycka på att SOA än så länge lämpar sig mest för integration med andra system, inte som vissa förespråkar, en konstant applikationsarkitektur. Vad som händer när Indigo släpps och förfinats är en annan story.

Sen undrar jag vad du menar med "Det är precis samma sak med SOA vs Objektorienterad Programmering"?

Allt i .NET är ju OOP? Sen om du väljer att bygga en OOA med hjälp av DDD eller ngn annan metodik är ju i stort ointressant?

Johan,

Med DDD skapar man oftast ett Anticorruption Layer för att distribuera sina objekt för remoting.
Ett lager som i princip konverterar sina Domian entiteter till DTOs (Data Tranfer Objects.)

Detta blir interfacet ut mot andra system. Så de kan prata med ens Domain.

Med DDD bygger innifrån ut, man börjar med Domain bitarna (som är till stor del det MS kallar för Business Object Layer, dock inte hela sanningen för Domain layer rör sig lite på DAL oxå.)

SOA baseras ju mer på en utifrån in princip. Man ser interfacet som det viktigaste och bygger det först och sedan de business relaterade bitarna. (I alla fall om man gör som Sunblad en gång sa till mig att de gjorde. de kan ju ändrat sig, det har hänt förr.)

DDD handlar heller inte om att bygga typade datasets eller använda Datasets överhuvudtaget så som ni gör i eran SOA. Det är mer en tabel driven princip där datan oftast är en kopia av datakällan.

Många anser att DDD är mer OOP än andra byggnadssätt/tanke modeller m.m. detta för att man fokuserar mer på objektens levnad och samhörighet baserat på en mer verklighetsbaserad nivå. En spegel av verkligheten. Där man har aggregat och associationer som viktiga reglar i DDD tänkandet.
Där classer oftast är något som man kan ta på i verkligheten. Faktura, Ordersedel, Bil, hjul etc...
Obs! Många anser att DDD är mer OOP än andra saker, det betyder inte att andra modeller m.m. inte är OOP. Dock står objekt för saker vi har i verkligheten. Vissa modeller för mig verkar mer class orienterade än object orienterade.

Precis som Patrik säger så vill _många_ att man bygger sin SOA så att de flesta (om inte _alla_) interface är baserade på remoting arkitektur, Web services, Bin remote, etc... en konstant applikationsstruktur.

Mvh Johan

Nu har vi så klart scenarion där distribution är viktigt, i ganska många klient / server lösningarn.

Men där tror jag mer på remoting approachen, dvs inte meddelandebaserat i samma utsträckning utan distribuerade objekt.

Tyvärr känns remoting i det avseendet halvfärdigt (undrar varför ingen byggt en server tjänst än runt det där?)

Jag håller med Patrik.

Remoting ska avändas för att kommunicera mellan två system som befinner sig på två olika maskiner. Om båda maskiner använder sig av .Net platform och vi vet att systemen inte behöver anropas från annan platform, så ska .Net remoting användas. .Net Remoting ger bättre prestanda än tex Web Services. Många kanske tänker "Vi bygger en Web Service, för det KAN hända att vi någon gång kommer att att behöva integrera andra system med vårt system", OBS! KAN. Då anser jag att man tar till den enkla metoden först, inte bygga saker för att det KAN tänkas, utan den lösning som passar bäst för att lösa problemet för tillfället. Skulle det visa sig i framtiden att vi skulle behöva bygga en Web Service för att integrera andra system, då först implementerar vi en Web Serive. Varför lägga ner extra energi och tid på att skapa Web Services när vi inte behöver dom eller vet om vi behöver dom? Finns så mkt annat vi kan använda den tiden till, tex testning etc. Jag kanske är för stor Agile freak ;)

Innan .Net, så byggdes system med ASP och BOL och DAL skrevs som COM+ komponenter. I sammband med .Net har det dykt upp lösningar som har ersatt BOL och DAL med Web Services, även om det är ett "internt" system. De som bygger på detta sätt har nog inte förstått vad syftet med Web Service. Web Services användas för integration mellan olika system/platformar och behövs ofta inte till något annat.

Nu när helt plötsligt SOA har dykt upp och blivit "hypat", så tror alla att alla system ska byggas efter SOA både interna och externa, vilket är helt fel. SOA ska användas där det verkligen behöves, inte för att det finns och är "hypat".

/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.com

<b>.Net Remoting ger bättre prestanda än tex Web Services.</b>

Om man använder en binary formatter ja =) Men jag kan hålla med om att det har blivit "hypat" att man skall kunna dela med sig av information till höger och vänster. Jag skulle vilja påstå att det är inget man behöver ta hänsyn till när man designar sin applikation, iaf inte speciellt mycket.

Man bygger upp sin architektur som man vill ha den och om/när man inser att man behöver dela information, vare sig det är internt eller externt, så bygger man på ett facade (anticorruption om man nu ska använda ddd termonologi) layer i sin architektur.

Och självklart är det inget hinder att använda sig av flera olika facader parallellt, t.ex en facade byggt på .NET Remoting för homogena system och WS för övriga. Man kan juh till och med ha helt olika krav på affärslogiken utåt mellan olika partners och då är parallella facader ett måste.

Fokus skall ligga på att bygga en robust, skalbar och flexibel architektur och sen kan man bygga olika gränssnitt mot den om/när man behöver.

Andreas:

Ska man vara ännu petigare så beror det på val av kanal, formaterare, interface design, marshaling, objekt akitiverings model och tillståndshanteringen ;) Du kan även via Web Services skicka binär data för att ev få upp prestandan, men dock är ofta remoting snabbare, speciellt som du säger Andreas om man har en binär formtaterare och rätt kanal etc.

När det gäller implementation av fasader så är det en mycket elegant lösning som Microsoft Patterns & Practises också förespråkar i sina guiedlines till utvecklare.

Vi kommer säkert se guiedlines i framtiden från PAG, där O/R-mappers användas och entity objects etc, specielt när och om Object Space kommer. Men kanske redan innan dess, vem vet ;)

/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.com

Jag vill bestämt hävda att det ena inte utesluter det andra. Det är helt korrekt att en SOA-lösning "designas" utifrån genom att tidigt i processen definera vilka kontrakt som bestämmer meddelanden som skickas och tas emot, men ett av skälen till dessa tidiga kontrakt är att kunna dela upp implementationen av de olika aktörerna i en större distribuerad lösning i olika projektgrupper vilka då själva teoretiskt kan bestämma den interna strukturen och då inte bara eventuella domänobjekt utan hela den interna datastrukturen (t.om. databasens fysiska struktur med tabeller och relationer).

Med andra ord, det är enligt min mening helt upp till respektive projektgrupp om de vill använda DDD och jag kan till och med se vissa vinster med att göra det, speciellt eftersom enligt den process som både Microsoft och Sundblads rekommenderar så har vi redan diagram i t.ex. UML som beskriver informationsmodellen och då ofta domänobjekten.

Jag vill också hävda att det ibland kan finnas fördelar med att tänka långsiktigt i utveckling av dagens lösningar, med det vill jag uppmuntra till att välja Web Services framför .NET Remoting. De indikationer som jag fått både internt och externt är att .NET remoting inte är en långsiktig lösning, själva Don Box vill bestämt att Web Services prioriteras! Däremot kan det finnas ett värde i att lära sig hur programmeringen med .NET Remoting fungerar eftersom det för närvarande ser ut som om att hanteringen av Web Services i .NET Framework 2.0 ser mycket mer ut som dagens .NET Remoting implementationer än dagens Web Services implementationer. Men det är som sagt, bara indikationer...

Förutom själva ideén med att bygga system utifrån och in. Vilket provades på 80-talet när många applikationer byggdes utifrån vilka rapporter som skulle skrivas och i slutändan låste applikationerna till bara de rapporterna. Det tvingade fram OOP metoder i början av 90 talet där systemen byggdes innifrån och ut för att säkerställa att de kunde utvecklas och byggas på utan att bygga in sig.

Som jag förstått så är det inte PAG och MS corp som hävdar att utifrån och in är att föredra, utan 2xSundblad?

Dessutom har jag redan tagit tillbaka mitt "VS" eftersom jag i efterhand upptäckt att det var pedagogiskt oriktigt och det blev en inkorrekt "jämförelse".

Oavsett det,

att bygga onödigt komplexa lösningar när det inte behövs är i min mening slöseri med tid och företagets eller kundens resurser. Det är självklart att man skall bygga system som klarar förändringen i en organisation (vilket jag hävdar är enklare med en utifrån in approach), men att lägga till finesser som inte efterfrågats är kanske snyggt i en akademisk miljö men självmord i ett projekt där pengar och tid är viktigt.

Det här gäller ju inte bara Web Services utan precis allt annat, om ett företag vill ha en hemsida så har de inte bett om en fullfjädrar SOA lösning med content managment möjligheter från pocket pc.

Vad gäller att använda sig av dagens SOAP/WS specifikation för att kommunicera i homogena miljöer så skapar det ett antal problem och begränsningar i onödan, exempelvis:

1) Du kan inte ha ngt tillstånd, utan att implementera komplexa "session" hanteringar a'la webb applikationer. Vilket gör att det mångt och mycket blir "Fire and Forget"

2) HTTP är varken snabbt eller speciellt enkelt att utöka, det har sina fördelar som att tex det alltid är enkelt att öppna i brandväggar. Men måste alla applikationer kommunciera ut på internet?

3) SOAP är pratigt och bygger stora meddelanden = kostar onödig prestanda, vilket tynger ner företagets LAN i onödan och kanske även WAN om det kommunicerar ut på internet. I slutändan blir det kostsamt för prestanda och skalbarhet.

4) XML är grymt pratigt och vill man jobba med komplexa objekts hierarkier så stöter man på mer problem än man löser. Även oavstående gällande prestanda / skalbarhet blir ett problem.

5) WS och transaktioner? Existerar inte, vill jag jobba med två ws i samma transaktion eller styra transaktionen över mitt dist lager får jag bygga min egen lösning. Oftast komplex och sällan speciellt pålitlig.

6) Meddelandebaserade "Fire and forget" system passar inte in alla scenarion.

Det sagt så ser jag dock fram emot med spänning på Indigo. Det verkar bli lika revolutionerande som distribuerat ramverk som hela .net var för övrig systemutveckling.

Att Don Box just nu äter, drömmer och älskar med meddelandebaserade protokoll innebär dessutom inte att det måste vara den ultimata lösningen, jag har själv sett och hört honom vid tre tillfällen (oberoende och hos MS i Redmond) säga "Remember me? I'm the guy who wrote that COM-Book! I'm so SORRY!" ;). Det är alltid farligt att ta vad en person säger som den absoluta sanningen.

Sen bygger Indigo och dess meddelandebaserade arkitektur på mycket mer komplexa byggstenar som eliminerar i princip alla de punkter jag listat där uppe. Om så blir fallet, då kan det börja bli intressant att använda i även homogena miljöer.

Vad jag har hört, så jobbar MS med att ta fram ett binärt sätt att kommunicera mellan platformar för att få ökad prestandan på Services. När jag pratade med PAG under den tid då Shadowfax var under diskution, va just prestanda problemet med Web Services den stora frågan. Om jag inte har helt fel så kan imorgon dagens Services byggt med hjälp av Indigo, byggas oberoende av protokol och format, men att SOAP kommer vara det primära formatet för det har blivit en acceptabel standard hos flera platfoms distributörer. En annan sak som är intresant är att Microsoft vill byta ut HTTP till ett bättre protocol som inte är tillståndslöst. Jag hoppas de kommer lyckas med detta, för det är på tiden att byta ut HTTP. Jag håller med Johan Lindfors att det kan vara tillfördel att välja Services framför .Net remoting. Men är det ett system som kräver hög prestanda och där vi vet med säkerhet att systemen som vi ska kommunicera med över nätet har .Net platformen, så är .Net Remoting ett bättre alternativ. Men det är betydligt enklare att skapa en Web Service för kommunikation än att använda .Net Remoting. Men val av Web Service eller .Net remoting är ett beslut man får ta utifrån kundens behov och krav.

När det gäller MS och 2xSunblads arkitektur, så är den bra, den är inte dålig. Den fungerar och den har sina för och nackdelar som med allt annat. Val av arkitektur ska göras för varje enskilt projekt, det finns ingen speciell arkitektur som passar alla lösningar.

Java utvecklare är mycket långt för många av oss .Net utvecklare när det gäller arkitektur. Men det är inte så konstigt, Java har funnits mkt längre än .Net och har varit OO sedan skapelsen och användas av många fler utvecklare, men som tur är så har många Java utvecklare gått över till .Net :)

MS har i en .Net show om Enterprise Architecutre (För två åresedan), erkänt själva att de inte är lika duktiga som många andra inom området, men med hjälp av andra så ska de bli mycket bättre, vilket det har verkligen blivit. MS har välidgt duktiga arkitkter så som tex Jack Greenfield etc. De gör ett imponerande och mycket bra arbete. Även PAG gör ett mycket bra arbete, om ni får tid över, läs gärna deras guiedlines.

Om vi ser på Java utvecklare igen, så har de under lång tid använt OOP samt DDD. Den möjligheten fanns inte under den tid då COM+ och ASP fanns. Men nu när .Net kom, där C# kom och VB.Net blev OO, så har det blivit möjligt att använda OOP och DDD i .Net applikationer. DDD har blivit mkt uppmärskamat av .Net utveckalare runt om i världen under den senaste tiden, vi kan se många MS arkitekter och utvecklare skriva om DDD, Refactoring och TDD etc t.om Jack Greendfiled och Co, nämner om domain model och data mappning i sin bok om Software Factories (En lösning för att ta utvecklingen till nästa nivå) som ett alternaiv till att lyckass (OBS! de nämner inget om table module). De paratar tex också om hur vikigt Agile är, speciellt för att kunna få ner kostnaden i projekt. Agile bygger delvis på att vi inte ska bygga det vi inte behöver nu, utan enbart bygga det som behövs för idag.

Några av världens främsta arkitketer som Martin Fowler och Evans etc, pratar mkt om DDD,TDD, Refactoring och Agile etc och använder det idag. De har t.om blivit inbjudna av Microsfot för att hålla presentationer om ämnena.

Nästa version av VS 2005, kan kompleteras med Team System, som har verktyg som NUnit för TDD och massor andra underbara verktyg som jag verkligen ser fram mot. I VS 2005, finns det även vertyg för att underlätta Refactoring etc.

MS tar nu även fram en Agile model, Microsft Solution Framework Agile. Som ser lovande ut. Agile bygger på att kunna leverera det kunden vill ha inom projektets deadline. Agile är tydlig på att vi inte ska bygga det vi behöver i morgon, utan det vi behöver idag. Det är idag viktigare att leverera till kund i tid och få ner kostnaderna än att bygga något som ev kanske kommer att användas i framtiden. Med en bra arkitektur och tex med hjälp av DDD, så kan tex Web Services enkelt läggas till senare då olika system behöver integresas. Med hjälp av DDD, kan vi bygga SOA lösningar som kan att bli lättare att underhålla.

SOA är idag den bästa lösning enligt mig när det gäller integration mellan olika platformar, där DDD är en bra grund för att bygga lönsingar som bygger på SOA. Dock ska inte Services användas som komplement till gårdagens BOL och DAL COM+ komponenter i ett "internet" system. Med hjälp av tex DDD så kan metoder exponeras med hjälp av fasader och anticorruption layers. Ofta är det ett få tal metoder som måste exponesras via Services. När system behöver integreras, då först skapar vi Services och exponerar enbart de metoder som behövs exponeras (Alltså enbart de som kommer att användas). Med en bra domain model, så finns redan all affärslogik klar, och att lägga till en Web Sercice fasad, där ev anticorruption layer kan behövas, för att exponera en eller felera metoder via Services, är ofta varken tidskrävande eller svårt (om man har en bra domain model). För den produckt jag har varit med och utvecklat på min arbetsplats, var tanken att först exponera de flesta av våra "kärn" funktioner via Web Services. Men vi valde att göra detta när det först fanns behov. Vi sparade både tid och pengar på detta, vår tidsuppskattning var ca: 80 timmar. Nu efter 2 år, så har vi behövt exponera 2 metoder via Web Services. Det tog oss 5 min att skapa en Web Services som anropade två av våra metoder. Med detta vill jag säga, vänta med implementation av Web Services, lägg tid på en bra domin model, vid behov skapa Services, men bara de som behövs för att integrera ett annat system. Det sparar ni både tid och pengar på.

/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.com

Det jag tycker är mest synd, är att MS oftast fastnar i _en_ arkitektur och inte i flera.
Jag personligen och troligen håller de flesta med mig är att en arkitekt skall förstå och kunna hantera flera olika arkitekturer där de passar in för de krav kunden har och hur applikationen måste leva.
Jag skulle villja se en drivrutin byggd efter SOA ;-) Jag skulle villja se en drivrutin byggd efter DDD eller efter Table model eller MS DNA. Ett importsystem som kräver kontrollerande loggning, transaktionsstöd till max samt stora krav på prestanda baserat på SOA eller DDD.

Och varför bygga en win form eller ett intranet efter SOA när man inte ens behöver distribuera interfacen?

Olika applikationer, program eller rutiner har olika krav de kan baseras på olika utvecklingsmodeller som passar bäst baserat på kundens krav, de har även olika arkitekturer baserat på utvmodellen samt dess krav. En XP metod ger oftast en model med mindre design än en SCRUM metod. RUP,AGILE ger större möjlighet till en bra DM. SOA ger stora fördelar då kunden kräver ett interface baserat på ett visst kontrakt med ett system de vill prata med etc... Det är viktigt att man som Arkitekt känner till arkitekturer som passar för olika ändåmål och inte bara _stirrar_ sig blint på en och samma.

DDD är stort inom Javas värld, Java är stort för att deras värld är mer öppen, de begränsar sig inte till en enda arkitektur och lösning utan erbjuder flera. Tack vare .Net och dess OO blir mer o mer modeller och arkitekturer mer och mer intressanta. Jag har pratat med flera som läst och gått efter MS SOA som nu intresserar sig mer o mer av DDD och andra byggnadssätt. Om MS bara kommer begränsa sig på ett sätt kan de tappa folk för att de hittat en annan intressantare värld som är bredare. Det kan slå fel.

Visst kan man använda DDD för SOA, men det förespråkar inte MS idag och då pratas det knappt om det.

Arkitektur är som religion. Man kan inte säga att en har mer fel än e den andre. I skolan får man lära sig att det finns olika typer av religioner, samt hur de troende ser på biblen etc... Samma borde det vara med arkitektur. Man får lära sig de olika modeller som nyttjas och sedan är det upp till en själv att välja den eller det man vill tro på eller som passar ens krav bäst.

Mvh Johan

Det har varit intressant att följa den här tråden. Det är lätt att se att bidragsgivarna är kompetenta och engagerade utvecklare. Det är lika lätt att se att flera av dem har missförstått vad SOA egentligen är.

Låt mig först hålla med Johan Normén som säger att vi Sundbladare kan ändra oss och att vi har gjort det förr. Det är verkligen sant! 1995 skrev vi till exempel en teknisk rapport som helt och hållet byggde på de idéer som nu kallas för DDD. Vi är idag långt ifrån lika övertygade som vi var då om att DDD är en bra strategi för design av ”business systems”. I dag tänker vi annorlunda än vi gjorde då, och förhoppningsvis kommer vi senare att tänka annorlunda än vi gör nu.

Låt mig också säga något om outside-in och inside-out. Outside-in är inte en idé som kommer från oss; det är inte heller en idé som är specifik för SOA. Det är i stället grundidén för ”interface-based computing”. SOA är helt och hållet baserat på idén om interface-based computing, så det är naturligt att SOA också bygger på idén om outside-in. Det är möjligt att PAG inte sagt så mycket om det här än, men den som lyssnar på Pat Helland inser att outside-in är den enda möjliga strategin för SOA. Han säger att utsidan är det enda som är intressant för en tjänsts konsumenter; insidan är ”merely implementation”. Vi tycker att det bara är att hålla med.

Det talas mycket om att Java (och, vill jag lägga till, ”the object-oriented community” i sin helhet) är mer inriktad på inside-out. Jag är böjd att hålla med. Jag ser dessutom ett tydligt samband mellan detta och med företagens attityd till det IT-stöd de tycker att de får. De tycker att strukturen på de IT-system de har tillgång till i alldeles för liten utsträckning påminner om verksamhetens struktur. Det är faktiskt den dominerande inställningen från verksamhetsansvariga när de uppmanas att ge sin syn på vilket IT-stöd de faktiskt får.

Och det kanske inte är så underligt. Verksamheten ser alla IT-system från utsidan, medan de som utvecklar dem har en klar tendens att se dem från insidan och att också exponera dem med utgångspuntk från deras interna struktur. Den här tråden är ett bra exempel på det. Hade systemen byggts från utsidan och in hade verksamheten ganska säkert uppskattat dem mer än de gör nu.

En annan sak som behöver klaras ut är den roll SOA bör spela. SOA är inte ett sätt att strukturera en applikation. SOA är i stället ett sätt att strukturera en organisations hela IT-stöd. Därför är inställningen att ”lägga till litet SOA där det behövs” inte särskilt produktiv. Man bör i stället tala om att vi går från en ”applikationsorienterad” till en ”serviceorienterad” arkitektur, där den senare bygger upp IT-stödet från ett verksamhetsorienterat i stället för ett applikationsorienterat perspektiv. Gissa vilket perspektiv som kommer att göra mest nytta för verksamheten!

SOA är inte till för att utforma drivrutiner! SOA är till för att utforma informations- och exekveringsstrukturen för en hel organisations hela verksamhet! Det problem som företag upplever som allra allvarligast efter problemet med att dagens IT-stöd inte liknar verksamheten är att oförutsedda integrationsproblem är svåra att lösa. Med andra ord: i går byggde vi de integrationsproblem vi har idag. Frågan vi bör ställa oss är om vi idag skall bygga morgondagens integrationsproblem eller om det är värt att undvika det. SOA har potentialen att undvika detta problem och är därför väl värt att överväga, inte för en specifik applikation utan för en hel portfölj av IT-stöd.

Jag har också ett par ord att säga om ”agility”. Man kan se på agility på två sätt. Det ena sättet – det som det talats om i denna tråd – handlar om att så snabbt som möjligt få ut en lösning. Det andra sättet – som jag inte tror har nämnts i tråden – är att se till att det man utvecklar blir så enkelt som möjligt att snabbt ändra när verksamheten ändras. Vilken syn på agility man väljer kommer att avgöra om organisationen blir agile! Med andra ord: en för snäv syn på ”agile system development” kan leda till att den organisation som äger dessa system inte blir agile alls! Gissa vilket synsätt som på sikt leder till bäst resultat för den ägande organisationen! Även här har SOA en del att erbjuda.

Slutligen: Johan Lindfors har alldeles rätt när han säger att det inte finns något motsatsförhållande mellan SOA och DDD, bara de båda strategierna får sina rätta roller. SOA måste vara den övergripande strategin som leder till en verksamhetsliknande struktur på IT-stödet och som definierar service interfaces. DDD blir ett sätt att implementera ett eller flera sådana service interfaces, men bara för den som finner att det är det bästa sättet. Och det är inte alls självklart att DDD objektiv sett är överlägset ens för implementering av en service; det finns flera mera moderna och konkurrerande ansatser som i många fall kan visa sig överlägsna.

Det blev litet mycket, men jag kom ju också in rätt sent i debatten. Hoppas alla har överseende.

/Sten

Hej Sten!

Det var ett tag sedan sist! Allt väl hoppas jag! Och det var förresten ett mycket intressant inlägg!

Ja, jag är ännu senare med ett litet inlägg här och jag har egentligen inte så mycket att invända eller tillägga.
:-)

Dock blev jag nyfiken på en liten detalj. Du skrev att du inte är övertygad om att DDD är bästa sätt att implementera en service. Det är absolut inte jag heller även om jag tycker det är en ansats med potential. Det jag blev nyfiken på var vilka ansatser du ser som mera moderna och konkurrerande?

Mvh
Jimmy
www.jnsk.se/weblog/
###

" Han säger att utsidan är det enda som är intressant för en tjänsts konsumenter; insidan är ”merely implementation”. Vi tycker att det bara är att hålla med."

Jag måste säga att jag anser att han har fel där. Ok. Visst är interfacen viktigast det har de alltid varit. Men om vi ser på en Domain eller låt säga en service med Business logik så är ju självklart Interfacet ut viktigt då det är detta vi pratar med. Men även Business Logiken spelar stor roll. Det är inte interfacet man ändrar på vid förändringar utan oftast business logiken. En räknerutin kanske måste struktureras om reultatet kanske måste ha nya värden, status flaggor måste kanske läggas till i medelandet m.m. Så att säga att insidan har mindre betydelse låter lite tragiskt då det är motorn för att skapa utsidan.

Man säger oxå att Out-side in gör att det blir mindre justeringar i interfacet men att Inside-Out ger mer ändringar i interfacet. Varför förstår jag inte, då anser jag att man är en sämre programmerare som inte byggt en bra model som är förändringsbar. Mina Interface har oftast vart detsamma när jag byggt Inside-out, det är oftast Business jag ändrat, men det har gjort det enkelt att ändra interfacet oxå om det behövdes. Outside-in kan ge problem i båda delarna. Oftast låser man sig till ett interface som inte går att ändra även då kund kräver det och man kan även låsa Business rules för att man la för lite energi på den innrebiten.

Dock kan jag tycka att vid specandet av sin model specar man ju interfacets krav. Just nu arbetar jag med en service modul för RSS 2.0, jag vet hur interfacet skall se ut då jag har spec på detta, men jag börjar bygga insidan. Jag börjar bygga tranformatorn som omvandlar mina aggregat till XML data när insidan är klar och fungerar fint bygger jag fasad/service biten som skickar medelandet eller tar emot ett om jag vill transformera åt andra hållet. Behöver jag bygga om nått så är det insidan jag måste bygga om. På så vis är DDD bra när den riktar sig mer mot att insidan måste ha god struktur och uppbyggnad för att övriga lager som nyttjar Domain Layer skall kunna byggas med så lite logik som möjligt.

Dock kan jag även säga det att även om man bygger insidan först så måste man ju ha förtåelse över systemet. Om det skulle vara SOA så har man ju tidigt specar på hur dessa interface skall prata och även krav på vad de skall returnera. Då kan jag starta bygget genom att göra deras insidor. Det är ju aldrig så att man bygger en arkitektur där man inte ens vet om användarens(klienternas) krav.

När Pat Helland säger att outside-in är den enda möjliga strategin, och att insidan är "merely implemenation" menar han inte då att det är mindre viktigt för kunden att kägga till insidans logik?
För det är en helt annan sak. Det är ju typ vad inkapsling är. Jag kanske missuppfattat detta med outside-in och in-side out men av det jag hittat på nätet baseras det vart man lägger fokus när man startar modellering. Och jag har nog aldrig stött på någon som inte känner till de interface som behövs innan man tar fram sin modell. Det är det som gör dessa ord kluriga... vem modellerar classer och metoder i kärnbiten om man inte känner till interfacens krav? Då gör man ju nått som inte ens har krav, då är min fråga Vad bygger man då? vet man ens det?

Jag skulle ju kunna bygga fasad eller service interfacet först och sedan bygga mig inåt tills jag nått mitt mål. Men detta brukar oftast generera i en mer Transaction scriptet lösning. (Då syftar jag på Fowlers Transaction Sctip pattern) http://www.martinfowler.com/eaaCatalog/transactionScript.html vilket jag verkligen avskyr. Men det behöver vi inte ta upp här.

Om jag skissade upp min Domain Model skulle jag oxå kunna bygga utifrån-in då jag känner till modellen, men hur ofta bygger man väggarna innan grunden för ett hus? Och vemn vet hur dess Business skall användas i interna apps? Att binda dem i en Bound Context för att ge dess bussiness logik förmågan att nyhttjas av andra subsystem kan ju minineras om man inte har en god model över dess bitar.

Så att bygga SOA out-side in känns mer som att göra det misstag man en gång gjorde med det funktions orienterade sättet, att bygga få metoder men många inputparametrar och över 200-1000 rader kod för en metod. Där metoden gjorde flera redundanta saker.

Men som jag du ser har jag funderingar vad du egentligen menar med Inside-out och outside-in jag känner mig osäker på dem, för visst är det så att vi pratar olika nivåer här? hög o låg nivå modellering?

Att jag tog upp drivrutiner som ett exempel var bara för att visa att _MAN_ bör som arkitkt inte rikta in sig på en Arkitektur form utan flera och lära ut dessa, Det är då man har en arkitekt, en person som kan anpassa arkitekturen för kraven. Kan man bara bygga tjänse orienterade lösningar hur skall man då förstå att Drivrutiner bör byggas med prestanda och tyvärr på ett mer transactions scriptat sätt där OO inte har sin plats?

Samma gäller utv-modeller. RUP (Vatenfall, Itterationer...), Agile, XP, Scrum etc... Dessa är oxå anpassade efter olika former av krav från kund. RUP är fint den har många olika modeller, vanligast är Vattenfall och Itterationer. Då kunden inte vet sina krav är Agile, XP eller Scrum bra modeller för att lösa nått snabbt där man måste sitta nära och prata med kund. Om kunden vet sina krav så kan UP vara en model för det projektet för då har man en massa underlag och kan sammanställa dessa till detaljerade skisser m.m. Detta har ju inte direkt med Arkitektur att göra, men arkitekturen påverkas ju av den metod man väljer. Designen får en mindre roll i XP då man inte har tid att bygga riktig bra kärna. Men oftast bygger man för mkt lull lull o tänker detta kan vara bra att ha, vi kanske behöver det sen. Vet ej var detta tankesätt kommer från men det är inte ovanligt att man ser APIer som en kollegor har byggt som _kan_ vara bra att ha sen om man vill göra fler flexibla saker. Har men en bra DM är det rätt lätt att lägga till dem efter hand.

Sedan har vi den stora frågan, är SOA framtiden? eller bara en liten bit i den framtid vi redan är i? jag har arbetar med många B2B, B2C, samt logisktsystem och bara behövt använda några remote interface för handdatorer, små enstakade moduler. Men ca 70% är fortfarande interface där vanlig traditionell marshaling existerar. jag skulle _Aldrig_ i hela mitt liv bygga dessa interface remote bara för att _man_ kanske vill nå dem senare. Skulle detta bli fallet skulle jag koppla till ett lager för detta. Evans kallar det Anticorruption Layer andra Tranformation Layer någon Remote Interface Layer o vissa bara Service Layer. En god DM löser även detta galant, och det är mer vanligt att man gör sin applikation mer service orienterad efter hand än att man bygger den service orienterad med en gång.



Mvh Johan

Sten:

Kul att du kom med i diskutionen, det var delvis ett mål med denna tråd, att få med 2xS (om jag inte har helt fel).

Jag kan hålla med om mycket du säger. Jag är dock inte jätte insatt i er arkitektur som ni har idag, den tidigare ni har använt er av har inte varit mitt val eller favorit, men varför prata om gårdagen?

Jag har hört att den nya arkitektur ni har, bygger mycket kring SOA. SOA är idag ett av de bättre valen när man pratar "Integration" mellan system. Jag har redan från starten av det som då kallades Shadowfax och genom det vill jag säga att jag har inget mot SOA, tvärt om, tog mot inbjudan från PAG för att jag tycker SOA är intresant ämne. Att bygga ett system efter SOA för att det "kan" hända i framtiden att vi behöver integrera system, är inget som jag strävar efter (om jag inte är säkert på att det kommer att hända). Vad jag har erfarat och läst så är det ofta väldigt få tjänster som behövs skapas vid integration (kan självklart bli många fler). Att skapa en Service i .Net är väldigt enkelt och har man en bra grundarkitektur för sina system, så krävs det ofta väldigt kort tid att lägga till en Service fasad vis behov. Varför? Jo för alla affärslogik finns redan, och att skapa ett interface utåt med hjälp av Service går ofta väldigt fort.

Det finns ingen annledning att lägga ner tid eller slösa resurser genom att enbart kommunicera med Services mellan lagren i en app för att det "kan" hända att vi behöver öppna upp för integration i framtiden. Vid behov, då läggs Services till och ofta som en fasad ovanpå applikationen. Det är med andra ord enkelt (behöver inte vara) att applicera SOA efteråt när det finns behov av att skicka meddelanden mellan tjänster.

Som Jimmy, är jag också nyfiken på vilka ansatser du ser som mera moderna och konkurrerande?

/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.com

Jag tycker absolut att SOA är en bra ideé, man skall definitivt ha i åtanke att system möjligtvis måste integreras i framtiden och att det kan komma som ett krav från större organisationer.

Av flera anledningar tycker jag dock inte att man alltid skall utgå från att integration är ett krav. Jobbar man med organisationer som IKANO banken och andra finansiella institutioner så är det vanligt att det är ett krav men i många fall är det inte det.

Jag tror att om man bygger en föränderlig arkitektur och är medveten om begränsningarna i dagens och morgondagens teknik för tjänster, så kan man bygga sina system på ett sådant sätt att om det behövs så blir det enkelt att skapa tjänster runt dem.

Microsofts vision är ju att vi i framtiden skall komma åt alla våra system från var vi än är och från vilken enhet som helst. Men vi är långt ifrån där idag, det tekniska stödet för det är inte bra nog och organisationerna har ännu inte tagit det till sig.

Hur framtiden ser ut, speciellt med Indigo, kan man bara gissa. Dock tror jag att utan starka krav från organisationer så är tjänstebaserade IT-system något som vi får vänta med för jag säger som i så många andra scenarion, "Varför implementera ett extra lager av komplexitet i onödan?"

Jimmy, Johan och Fredrik N., Patrik!
Tack för era svar och kommentarer. Innan jag går i svaromål måste jag säga att vi på 2xS är inne i en extremt arbetsfylld period, vilket gör att jag förmodligen måste ligga lågt på den här tråden från och med att jag gjort detta inlägg och fram i stort sett till jul. Jag vill ändå så gott jag kan försöka klarlägga vår position och svara på åtminstone den del av de frågor ni direkt och/eller indirekt ställer.

Ett problem i våra kommunikationer är att vi har helt olika uppfattning om vad SOA är. För oss är SOA inte en teknik för integration som man kan ta till ”vid behov”. Att lägga ett service interface – ofta en web service – framför ett program leder inte till SOA. Det kan bidra till förenklad integration av svårförenliga system, men det är inte SOA.

Vi menar att SOA är en attityd till hur ett informationsstöd byggs upp för en hel organisation. Att införa SOA kommer att ta lika lång tid som det tog att införa objekt, det vill säga mellan 10 och 20 år. Och i likhet med objektorienteringen kommer SOA inte ens då att stå för en dominerande del av befintlig programportfölj.

Jag vill också mena att jämförelsen mellan SOA och DDD är felaktig. Som vi ser det handlar DDD om struktureringen av en applikation, medan SOA handlar om att definiera en uppsättning självständiga (autonoma) services med olika uppgifter och olika ansvar som kommunicerar med varandra. SOA konkurrerar alltså inte med DDD utan är överordnat. DDD kan sedan väljas som en av flera strategier för implementeringen av de service interfaces som definierats som en lösning på de krav som identifierats på respektive service.

SOA-paradigmen skall i stället, menar vi, ställas mot applikationsparadigmen. Don Box har sagt det bäst: ”Applikationsbegreppet är inte längre relevant. Vi skall i stället bygga system av självständiga program som kommunicerar med varandra genom meddelanden.” Detta är självklart sagt från ett SOA-perspektiv och gäller inte för den som inte ansluter sig till SOA-tanken.

Självständigheten är en nyckel till SOA. Den leder till att en tjänst kan vidareutvecklas till att tillgodose nya behov utan att störa befintliga konsumenter. Den leder också till att en tjänsts interiör kan förändras totalt, till exempel genom att ersätta en domändriven design med en XML-driven, utan att det har någon betydelse för konsumenterna annat än att prestanda och/eller skalbarhet kanske förbättras. Det är alltså inte insidan utan utsidan som är viktig för konsumenten. Insidan är däremot synnerligen viktig för tjänsten och för tjänstens ägare. Sådana ändringar och sådan vidareutveckling ter sig betydligt svårare i en applikationsdriven design där information och verksamhetslogik (”business logic” eller ”business rules”) är strukturerat efter applikationens behov och inte efter verksamhetens eller informationens struktur.

De tre grundbultarna i ett modernt verksamhetsorienterat informationssystem (”business system”) är den information verksamheten har behov av och bidrar till, de verksamhetsprocesser (”business processes”) som använder, skapar och förändrar den lagrade informationen, och det regelverk (”business rules”) som främst utgör restriktioner på information och beteende men också genererar information och beteende.

SOA adresserar var och en av dessa grundbultar på ett långt bättre sätt än en applikationsorienterad paradigm gör. I en processintensiv miljö (= de flesta affärsdrivande företag) stimulerar SOA till definition, design och implementering av särskilda services av olika slag för regelkontrollerad, ansvarsfull och strikt kontrollerad försörjning av information (”entity services”), för utförande av de aktiviteter som utför själva arbetet (”activity services”) och för sammanhållandet av dessa aktiviteter i verksamhetsprocesser (”process services”).

I en färsk IDC-undersökning om hur företag såg på och prioriterade sina IT-lösningar framkom att det vanligaste önskemålet av alla (delades av 36,2% av de undersökta företagen) var att program och tjänster skulle integreras bättre med affärsprocesserna. Detta är ett mål som är betydligt svårare att nå med en applikationsorienterad paradigm än med en serviceorienterad.

SOA har också fördelen att stimulera till separation av de tre grundbultarna, där information och regelverk hanteras i entitetstjänster medan processer och aktiviteter hanteras i process- respektive aktivitetstjänster. Jämfört med fotboll, bandy eller ishockey påminner det om separationen av taktiska dispositioner från regelboken. Regelboken är ett separat dokument som (tillsammans med domaren) utgör restriktioner på ”deployment of tactics”. I en applikationsorienterad paradigm tenderar alla tre att hållas ihop i tämligen monolitiska applikationer, och dessutom förekomma redundant i flera applikationer.

Tvärsgående angelägenheter som säkerhet, loggning och felhantering för att nämna några vanliga exempel kan på liknande sätt skötas av separata tjänster. Det är ju åtminstone delvis detta EDRA (f.d. Shadowfax) handlar om.

Det är också tjänsters självständighet och den separation av olika slag av angelägenheter i olika services som gör SOA-baserade lösningar ”agile”. SOA kräver mer inledande planering än traditionell applikationstillverkning, men en belöning är den ”agility” en SOA-baserad programportfölj möjliggör för den ägande organisationen. Att enkelt kunna förändra verksamheten när förändringstryck uppstår utifrån är långt mer värdefull ”agility” än att snabbt – ofta som i XP med förkortad analys – få ut en tätt sammanhållen applikation.

Som vi ser det är alltså SOA en övergripande strategi för att lösa övergripande verksamhetsproblem (”buisness problems”). En applikationsorienterad paradigm går mera ut på att skapa en så god struktur som möjligt för ett specifikt verksamhetsproblem (”application problem”). Vårt intryck är att den diskussion vi för på denna tråd försvåras av att endast vi och Johan Lindfors har det övergripande perspektivet medan andra deltagare främst har applikationsperspektivet. Observera att detta uttalande inte är ett försök att sätta oss och Johan på några höga hästar, bara ett försök att hyfsa diskussionen.

Det är absolut inte fel att utgå från en applikationsorienterad paradigm – tvärt om kommer det att bli den dominerande miljön för de flesta system som kommer att byggas under de närmaste åren. Det är emellertid inte heller fel – långt därifrån – att utgå från en serviceorienterad paradigm. Många företag kommer att gå över till en sådan under de närmaste åren, och det gäller särskilt ”big enterprises”.

Jag ger alltså alla er rätt i nästan allt ni säger, givet att ni utgår från en applikationsorienterad paradigm. Med en sådan utgångspunkt skall man undvika SOA så långt det någonsin går och i stället försöka lösa kommande integrationsproblem med hjälp av nyskrivna interfaces.

Det jag har litet svårt för är den oförsonliga hållning jag uppfattar att ni har när det gäller användandet av DDD som taktik för att strukturera applikationer. DDD är en möjlig ansats, men det finns andra man borde överväga i många situationer. Och, som jag har sagt till Johan N ett par gånger: användandet av Microsofts dataset är inte liktydigt med Table Driven Design (TDD). Så gott som alltid när dataset används så som Johan N menar att de alltid används är det ett bra exempel på riktigt dålig design. Det är som att byta ut fotbollsskorna mot moonboots när man skall slå en straffspark och sedan säga att en straffspark är egentligen inte en bra målchans. Men det är inte den norm man bör rätta sig efter när man använder dataset.

Med allt detta sagt kan jag inte annat än förvånas över att så smarta grabbar som ni inte bejakar det nya och spännande som SOA medför. Det borde ju bara utöka er arsenal och göra er mer attraktiva på marknaden.

Till slut ett par ord om mitt sätt att uttrycka mig på om ”mera moderna och konkurrerande” ansatser. Det var ett onödigt uttryckssätt. Det jag tänkte på var dels det jag talat om i det här inlägget med en mera övergripande ansats (som inte står i konkurrensförhållande mot DDD utan mycket väl kan kombineras med DDD för design av de tjänster man kommer fram till att man behöver), men också den ökande användningen av XML-strömmar genom services. SOA och web services är ju inte helt beroende av varandra, men vi tänker oss gärna web services som dominerande teknik för SOA’s service interfaces.

Om vi nu skall kommunicera utåt med XML, och om de flesta uppgifter en service har är att slussa data från en databas till sina konsumenter, verkar det klokt att låta den JOIN-kapabla databasen själv generera den XML-ström som skall returneras till konsumenten i stället för att först bygga upp domänobjekt som liknar databasens och sedan låta ”vanlig” kod generera den struktur konsumenten behöver. Särskilt som i varje fall SQL Server tenderar att bli allt mer XML-kapabel.

Jag är ledsen att det här blev ett så olidligt långt inlägg, men jag får ursäkta mig med att jag inte kommer att hinna göra några fler på ett tag. Jag skall emellertid följa med vad ni andra skriver.

"SOA konkurrerar alltså inte med DDD utan är överordnat. DDD"
Jag vet ej om jag sagt detta eller om det framgått missförstånd i min text (kan bara svara för mig nu.)
Men DDD är hur man tänker SOA är ju hur man strukturerar en Arkitektur m.m. Det som är mer konkurrerande
borde i så fall vara outside-in vs inside-out byggsättet.

"...medan SOA handlar om att definiera en uppsättning självständiga (autonoma) services med olika uppgifter och olika ansvar som kommunicerar med varandra."
Det tror jag vi alla är med på. Dock anser jag att en fördig app där man öppnar upp interface utåt gör att dessa interface kan
användas i en uppsättning av SOA.

”Applikationsbegreppet är inte längre relevant. Vi skall i stället bygga system av självständiga program som kommunicerar med varandra genom meddelanden.”
Allt handlar ju om att skicka meddelanden redan idag, om det är marshaling eller soap spelar ju ingen större roll. Och jag ser
det heller inte som ett problem. FÖr mig är Services inom SOA just distibuerande applikationer. Eller publika tjänster. MS har
alltid haft vision med handdatorer o alla skall nå allas tjänster visionen, samma vision man även har i filmen Antitrust. (minns inte svenska titeln.) En annan fråga är... är vi redo för detta? känner vi till alla risker?


"...information och verksamhetslogik (”business logic” eller ”business rules”) är strukturerat efter applikationens behov och inte efter verksamhetens eller informationens struktur."

Njao... Där håller jag heller inte med. DDD handlar just om att lösa detta. DDD är som sagt ett sätt att tänka utifrån krav som
ställs av kravställaren och där man fokuserar på de innrebitarna för att just lösa det du ovan ser som ett problem.


"Som vi ser det är alltså SOA en övergripande strategi för att lösa övergripande verksamhetsproblem (”buisness problems”).!"
Håller med. Men som du även säger ställer inte alla dessa kraven, så min o ev andras fundering är, varför inte lära ut flera och
olika arkitkturer som anpassar efter kundens krav? SOA är ett krav då det handlar om det du säger, men jag tror och kan nästan vara säker på att applikationsbegreppet kommer leva så länge vi har ett OS och inte ett OS som en tunn klient. Varför skall ettlagersystem byggas efter SOA? Då tänker jag främt på de administrativa bitarna. Eftersom ett lagersystem oftast nyttjas med handdatorer är det ju viktigt med tjänster som dessa kan nå så ett sådant system blir en blandning av SOA och Applikation. Fast oftast går tjänsterna mot applikationens bussinessbitar.

"Med allt detta sagt kan jag inte annat än förvånas över att så smarta grabbar som ni inte bejakar det nya och spännande som SOA medför. Det borde ju bara utöka er arsenal och göra er mer attraktiva på marknaden."
Det är inte att vi inte vet vad det medför, vi vet mkt väl vad en sådan arkitektur medför, jag är mer förvånad att ni begränsar er
och ger era elever ett begränsatt byggsätt. Det är många som vart hos er som kommit till oss med massa frågor och som mer och mer
även börjar intressera sig av DDD för att det är bäst för det vi gör idag. Som du även säger kan DDD vara en god grund för en SOA, SOA är inte ett sätt att tänka utan en arkitektur. DDD används för att bygga upp en arkitektur.

"Och, som jag har sagt till Johan N ett par gånger: användandet av Microsofts dataset är inte liktydigt med Table Driven Design (TDD)."
Jag brukar vara aktsam att skriva TDD när jag pratar om det jag i princip själv hittat på är Tabel Driven Design. Vad jag vet så betyder det nått annat från ett tidigare dataliv än vad jag menar med just Tabel Driven Design.
För mig är Tabel Driven Design när datan man skickar är en kopia en spegelbid av databasen. Där datan i princip är uppbyggd efter realtioner än OO. Jag kallar även det Tabel Driven när man genererar Entiteter rakt från Dbn och nyttjar dem som om de vore rena o pure Domain objekt. Men det är en annan historia, allt är smal o tycke som ni vet. Just Dataset är mer eller mindre baserat efter en databas tabeller och kolumner, för mig är inte detta ren OO där O står för objekt som baseras efter metaforer av verkligheten, så som BIL, Kund, Människa, Hus etc... Att använda Datasets gör att man tappar dessa rena objekt. Eftersom jag även gillar DDD pga att att det mer eller mindre spelgar vekligheten blir Dataset för mig en databärare som nyttkas för att prata mellan Datakällan och Domain lagret inget annat. Dataset är stora och klumpiga, vårt lagersystem behövde skicka datapaket hela tiden och ett dataset vs DTOs (Data tranfer objects) gjorde stor prestanda skillnad. Ett dataset har extremt mkt onödig information med sig som oftast inte behöver nyttjas. Även spårbarheten minimeras då det blir mer kod och inte alls lika logisk som med DTOs. Men smaken är som baken. Det hela handlar för mig om hur man vill se ett system och hur logiskt det är för andra utvecklare. Refactoring är något jag nyttjar ottroligt mkt för
att minska redundans, öka språbarhet även prestanda. För mig skall en metod helst hålla sig under 100 rader kod.
Jag går även under filosofin prestanda kan man köpa billigt men arbetkraft och underhåll är det som blir kostamt därför är det viktigt att ha en bra struktur så nära människans synsätt som möjligt.

Arkitektur är som politik :-) Jag använder erat sätt att bygga då det behövs, jag använder DDD när det behövs, jag använder Manager modellen då jag anser den mest läpad etc... Lika så olika utv metoder.

Mvh Johan

Sten:

Jag tror alla i denna tråd har baskunskaper inom SOA, dock så tror jag många ink jag själv diskuterar kring att applikationer internt inte ska kommuniceras med Services mellan skikten, tex att COM+ komponenter som BOL och DAL ska inte bytas som Services, vilket det har ryktas om att vissa föredrar. Det vi vill påpeka är att Services är vikitg vid "integration" och inte som en intern teknik för att kommunicera mellan skick i en applikation. Jag tror på en framtid (även nu) där system behöver skicka meddelanden mellan varandra, protokoll och platformsoberoende, men detta gäller som du säger för större organistationer och inte för små lokala applikationer som inte behöver "integration" med andra system. Om inte SOA är enbart tänkt för integration mellan system, där det handlar om att skicka meddelanden platforms och protokolloberonde mellan varandra, då har jag fått fel bild av SOA och skäms jag över mitt deltagande och bridragande till EDRA, och tycker det är pinsamt att jag tog mot inbjudan av Ron Jacobs om jag nu inte förstått vad SOA handlar om.

Många system idag har redan affärslogik och för att få dessa system att enkelt skicka meddelanden mellan varandra i en organsiation så kan SOA appliceras och där Web Services "idag" är en given teknik. Sedan hur det kommer utformas med tiden är en sak.

Vill bara också säga att vi har faktiskt aldrig jämfört DDD med SOA utan ser dom som två helt olika saker.

/Fredrik Normén NSQUARED2
http://fredrik.nsquared2.com

"Med allt detta sagt kan jag inte annat än förvånas över att så smarta grabbar som ni inte bejakar det nya och spännande som SOA medför. Det borde ju bara utöka er arsenal och göra er mer attraktiva på marknaden. "

Två kommentarer runt det här,

<b> - 1 - </b>
Det är inte det att vi inte ser det nya och spännande som SOA medför och tycker att det är fel eller inte förstår vilken nivå SOA arbetar på. Det handlar mer om att inte köpa SOA som "The silver bullet", lika lite som OO är (försök skriva en snygg och snabb rapport i ren OO). Var sak har sin plats och det är anledningen till att jag startade den här tråden.

SOA är nytänkande och intressant men precis som många andra arkitekturer och "patterns and practices" så gäller: ( för att utveckla vad Martin Fowler http://www.martinfowler.com/ brukar säga ) <b>- "With every how comes a when"</b>.

<b> - 2 - </b>
Jag skulle dessutom se det som mer förvånande om inte "smarta grabbar som vi" såg på ny råd och rön med kritiska och forskande ögon för att se vart det passar in och hur.

Jag vet inte hur det ligger till med resten i den här tråden, men på alla föreläsningar jag någonsin varit på, oavsett om det varit matematik, socialtarbete eller databetingat, så har man alltid blivit matad med samma mantra, "Inget är säkert, var kritisk och bilda alltid en egen uppfattning".

<b>Summerat</b>
Själva kontentan med vad jag försöker få fram är vad många andra sagt här också. SOA är bra och troligtvis lika revolutionerande som OO var i början av 90-talet. Men, att fokusera på en enda arkitektur, ett enda designmönster och en enda möjlig lösning kommer snabbt kunna handikappa en utvecklare / arkitekt och göra honom/henne mindre flexibel inför förändringar, nya utmaningar och nya problemställningar. Detta är vad jag tycker är fel med den "hypade" SOA debatten.

Hej Sten,

Två /mycket/ intressanta inlägg...verkligen synd att du inte har en blog! (?) :-)

Jag håller med dig i mycket av det du skriver, men kanske mest av allt i att det kommer att ta tjugo år innan vi riktigt vet vad vi pratar om när det gäller SOA ;-)

Så med denna brasklapp så håller jag som sagt med dig om en hel del.

Att SOA handlar om autonoma servicar håller jag t ex verkligen med om. Autonoma och helst (implementationsmässigt) isolerade.

Fowler gjorde ett inlägg för ett tag sedan här : http://martinfowler.com/bliki/DatabaseStyles.html där han beskrev skillnaden på en "Applikationsdatabas" och en "Integrationsdatabas".

Med SOA är det inte ovanligt med att gå ett steg längre och låta varje /service/ ha sin egen, ganska lilla, databas.

Så i stället för tio servicar som alla går mot samma databas med hundra tabeller, har vi tio servicar, var och en med egen databas och med (i snitt) tio tabeller i varje databas.

Frågan blir: med så enkla små databaser - behövs verkligen ett lager med en liten domän-modell på typ tio eller färre klasser? (med allt vad domänmodellen innebär av O/R mapping etc)

Och om vi vill ha en sådan liten domänmodell, behövs verkligen DDD för att skapa den? Blir det någon skillnad om man börjar med klassmodellen eller tabellerna?

Man kan t o m fråga - hur stora /blir/ egentligen kraven på infrastruktur (olika tjusiga lager) mellan Servicens gränssnitt och databasen i en SOA? Vilka lager behövs egentligen?

O/R Mapping och DDD är (i min enkla förståelse av saken) svar på problemet med "skalbarhet" i växande applikationer. Alltså inte skalbarhet som i "prestanda/skalbarhet" (där man snarare kan förlora en smula) utan skalbarhet som i "hur fanken håller man egentligen /reda/ på 500.000 rader kod??"

Men om nu varje service blir så avgränsad och hanterbar - har inte problemet som O/R och DDD skulle lösa försvunnit?

Ja nu har jag verkligen klämt åt mig själv (som ju utvecklar en O/R mappare - men bara så att det är helt klart så är jag helt och hållet för SOA också!) :-)

För som sagt, om servicar inte kräver särskilt avancerad arkitektur för att implementera (i allmänhet) så består ju dagens/framtidens problem snarare i hur man kan hantera "skalbarheten" (här /både/ vad gäller "prestanda/skalbarhet" och "hur ska man kunna hålla reda på't?") i att kombinera olika servicar till en applikation!

Ok, dags att börja måla mig ut ur mitt hörn! :-)

Till att börja med är jag inte orolig för att marknaden för DDD och O/R kommer att försvinna anytime soon...den har knappt börjat, och precis som du säger har ju knappt ens OO börjat faktiskt /dominera/ applikationspoolen än! :-) Det är en trög marknad, på det stora hela (även om vi här på forumet förstås alltid ligger i yttersta framkant) ;-)

Men då till frågan: Behövs DDD, Domänmodellen och O/R om man utvecklar med SOA?

Jag tror det: dock bara ibland, men inte alltid.

I mitt exempel ovan hade vi servicar som gick mot små databaser med i snitt tio tabeller i varje. Om datamängderna sedan dessutom är små kan man kankse ibland t om fråga sig om man ens behöver en databas. Det kanske räcker med att spara XML dokument direkt på disk? Eller - och nu är verkligen cirkeln sluten :-) - varför inte helt enkelt flatfiles? (OBS: Inte ironiskt!)

Men säg att en databas på runt tio tabeller verkar som vad vi vill ha till vår service.

Tja, om vi har en databas med säg bara /tre/ tabeller (också säkert rimligt för många servicar) så skulle jag nog säga att DDD, domänmodeller och O/R är lite overkill. Och om vi har säg trettio tabeller i databasen - tja, då skulle jag nog säga "fundera på om inte det här i själva verket är flera olika services som du kan dela upp..." - vilket förhoppningsvis skulle vara ett gott råd i många fall, men man kan ju tänka sig att det kan finnas tillfällen när även trettio tabeller skulle vara rimligt...

Så, säg, trettio tabeller? Ja, då verkar väl inte DDD, domänmodell och O/R helt orimligt för att hantera implementationen av en sådan service? Det är nog vad jag skulle göra. (Har dock inte implementerat en service mot en db med trettio tabeller)

Men runt tio tabeller - det tycker i varje fall jag låter som ett [för att vara höftat tjugo år innan vi vet vad vi pratar om ;-)] rimligt tal för en vanlig "snittserice" - Servicea Vulgaris.

Behövs DDD, domänmodell och O/R då?

Nånstans mellan klart "nej" (tre tabeller) och klart "ja" (trettio tabeller) hittar vi den situation vi undrar över, och som vi (jag i vart fall) tror kommer att vara vanlig.

Så savret blir: (Tadarada-Tada) Det Beror På! (tm)

Jag har ofta gjort enkla appar på runt tio tabeller och tyckt att det varit klart produktivt att använda O/R med en domänmodell och att utgå från många av de koncept som återfinns inom DDD (som jag dock inte är någon klippa på - har inte läst boken av Evans ännu). Det borde inte vara någon skillnad på en service med tio tabeller?

Något som jag tycker är ett ganska bra exempel och som de flesta redan kan är RSS. En enkel service som går mot en databas med bara ett fåtal tabeller i - skulle /du/ använda en domänmodell?

Mitt svar är att /jag/ skulle det, men det är också litegrann för att jag utvecklar med domänmodeller i sömnen ;-) Om du vill använda en helt annan approach så tror jag att det är följande som är den egentliga poängen:

* Med SOA blir varje service såpass begränsad att du är ganska fri att välja den arkitektur/design/programeringstil som /du/ föredrar för att implementera den! :-)

Så att implementera våra servicar i SOA /ska/ vara ganska lätt och något vi redan bör vara helt bekväma med om vi redan är vana att utveckla tio (eller kanske hundra!) gånger mer komplexa /applikationer/.

Däremot, hur man ska tackla utmaningen att komponera applikationer av våra servicar är en /helt/ annan femma! Där har vi som sagt tjugo år av helfestliga misstag framför oss! :-)

Som du påpekar, Sten, är det alltså inte frågan om att utrusta våra applikationer med en Web Service fasad, utan om att skriva servicar som är små "mini-applikationer" och sedan bygga en ny typ av applikationer ovanpå dessa servicar! :-) Dock /vet/ jag att det är ingen i den här tråden som trodde något annat, så jag får väl helt enkelt konstatera att jag är mycket glad att du missförstod detta en liten smula så att du kände dig manad att skriva dina lysande inlägg! :-)

/Mats

Hej alla!

Den här tråden kanske är "klar"? Om inte så tar jag och fyller på med några små reflektioner:

Don Box har ju inte gjort sig känd som en stor förespråkare för t ex OR mappers, snarare tvärtom. Just nu känns det som att Don tycker att "ingen kan någonsin behöva en annan abstraktion än message".
;-)
Hur som helst så såg jag i Tim Ewalds (Don Box kompis) senaste blogpost en oväntad mening. Han skrev: "In general, you want an internal object model that you use to implement your core logic."

OK, detta är väldigt lösryckt från följande blogpost:
http://pluralsight.com/blogs/tewald/archive/2004/11/17/3538.aspx
Tims rykte gör att det lilla citatet är ganska anmärkningsvärt tycker jag!

En helt annan grej som jag tänkte nämna var när jag lyssnade på Anders Hejlsberg på JAOO för någon månad sedan. Före presentationen så "visste" jag att Anders inte anser att OR Mapping funkar. Till min förvåning sa Anders i det avsnitt i presentationen som handlade om C# 3.0 ungefär att han tycker OR Mapping är ett stort steg i rätt riktning. Sedan fortsatte han att säga att han inte var nöjd med det utan ville lägga till native stöd för att jobba med data i C#. Hur det skulle se ut hade han inte kommit fram till än. Jag gissade då på X# som inspiration, men hörde sedan från någon att Anders inte var förtjust i X#. Hur som helst högintressant tycker jag!

Och så retade jag mig återigen idag på att vi inte har stöd för något liknande AOP Introduction redan idag i C#, men det är nog en annan diskussion...
:-)

Mvh
Jimmy
www.jnsk.se/weblog/
###

Med alla turer runt Objects Spaces vara eller inte vara så undrar man hur Microsoft tänker. Från att höra Don Box i princip säga att han gärna skulle se att OS begravet till att de bara för någon vecka sedan kungjorde att de planerar att släppa det efter Longhorn i alla fall.

Man blir ju förvirrad för mindre.

Object Spaces är lite Vaporware från Microsoft faktiskt. Det har levt sitt eget liv i flera år nu, finns, finns inte, finns, finns inte. Sen har det varit ett j*kla liv i Microsofts newsgroup för Object Spaces där utvecklarna bakom t.ex. LLBLGEN PRO och EntityBroker (och andra) har yttrat sig om att MS inte alls borde slöppa ett O/R verktyg utan istället bygga in stöd i ramverket för utveckling av denna typ av verktyg - så som det sker på Java sidan.

För att återgå till SOA:

http://www-106.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=317&entry=65585