Tja då skriver jag väl igen då.

Serien av COM+ inlägg som jag precis skrivit började med den här, men ngn klåfingrig plockade bort det, så skriver det på nytt...

--
COM+ är en uppgradering av MTS och en plattform för att underlätta utvecklandet av distribuerade system. Framförallt har den ett transaktionsstöd och tight integration med DCOM för att kunna arbeta i skiktade lösningar.

Det finns många påståenden och skriverier om best-practices för arkitektur där COM+ nämns som en central del. Många har hoppat på COM+ tåget och nästan lika många har upptäckt att det inte är riktigt guld och gröna skogar. När man jobbat med COM+ ett tag så stöter man på problem efter problem, inget av dem har nämnts i de arkitekturbeskrivningarna man följt.

Jag tänkte skriva lite om de olika COM+ tjänsterna som finns och titta på när man kan nyttja vilken var och försöka bena ut ett par myter.

1) Transkationer skall köras av COM+ för att styras ifrån vårt BOL.
Det här är många arkitekters våta dröm, att transaktionerna skall styras ifrån vårt Bussiness Object Layer och jag håller med dem att i många scenarion kan det vara bra. Ur ett fågelperspektiv så ser det här ultimat ut. Men om vi tittar närmare på implementationen av COM+ transaktioner så ser vi snabbt att vi skjuter oss i foten.

a) För varje tjänst vi slår på i COM+ så skapas en utanpåliggande context. Det här är en dyr och tungrodd resurs som är tuff att tränga igenom. Det innebär prestanda förluster när vi arbetar mot våra objekt.


b) När vi startar COM+ transaktioner så startar vi också tjänsten "Distributed Transaction Coordinator" (DTC). DTCn arbetar precis som det låter med distribuerade transaktioner, men frågan vi måste ställa oss är - "Vad innebär distribuerat i det här fallet?".

Det är inte som man kan tro, att det innebär en distribution över nätverket, utan innebär en distribution över datakällor. DTCn är alltså utvecklad och designad för att jobba med transaktioner som blandar in flera databaser.

För att uppnå det så jobbar den med ngt som heter "Two-phase commit" vilken är en intensiv kommunikation mellan DTC och datakällan för att bestämma om en transaktion skall lyckas eller inte.

Two-phase commit och DTC blir då väldigt kostsam, onödigt kostsam om vi enbart har en datakälla.


c) COM+ transaktioner arbetar med en isoleringsnivå som heter "Serializable", det här är den tyngsta isoleringsnivån vi kan arbeta med. Den är guld för Data integriteten men döden för skalbarheten. Man behöver inte skriva någon speciellt avancerad databas-logik för att snabbt sätta sig i en sits där delar av eller hela tabeller blir låsta och skapar "dead-lock" situationer. (Nu finns det iofs fina fulhack för att komma förbi det här, men som alla fulhack så funkar de sådär och introducerar ytterligare en onödig komplexitetsnivå)


Summan av det hela blir att COM+ transaktioner lätt kan introducera en ytterliggare komplexitetsnivå i våra system utan att igentligen tillföra något extra som ex lokala transaktioner inte redan har. Man vinner mer på att lära sig arbeta med de lokala transaktionerna i sitt BOL istället för att använda de "bekväma" Enterprise Services.

I Sverige har vi få lösningar där igentligen COM+ transaktioner kommer till sin rätt och jag är helt emot att göra system mer komplexa än vad de måste vara, jag vet inte hur det är för er?

Tur att man arbetar efter DDD och rena .Net klasser utan Enterprise Services ;)

Även detta inlägg måste jag säga att jag håller med dig om, men det vet du redan ;)

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