COM+ att vara eller inte vara, 4 myter
Förord
COM+ är en uppgradering av Microsoft Transaction Services 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, men även andra tjänster som nyttjats flitigt. 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 4 vanlliga myter.
MYT 1, Transkationer skall hanteras av COM+ för att kunna 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.
MYT 2, Object Pooling och Just In Time activation
Nästa myt. Många skriver och påstår att object pooling och JITa ökar prestandan i dina system. Det här kan vara rätt om det används i rätt scenarion. Men .... a) Object pooling och Just In Time activation jobbar bra tillsammans, så bra att efter varje anrop till ett objekt så läggs objektet tillbaka poolen. Det innebär tex att jobba med entiteter med olika egenskaper är uteslutet eftersom du inte kan vara säker på vilket objekt du får tillbaka från poolen vid nästa anrop. Så objekt i poolen är bara tillämpliga för objekt som inte innehåller ngt tillstånd.
b) Den stora vinsten för Object pooling är när objekten tar lång tid att skapa eller håller dyra resurser under hela sin livstid. Det är det igentliga användingsområdet.
c) Precis som för transaktioner så skapas här tungrodda och dyra kontexter
Om man kombinerar b och c så kräver det att kostanden för skapandet av objektet är mycket dyrare än kostnaden för kontexten. Annars så tar tjänsterna ut varandra och vi har introducerat komplexitet i vårt system utan någon vinst.
MYT 3, Rollbaserad säkerhet och Impersonation
I) COM+ är enda sättet att ge ett objekt en annan identitet. Det här är vanligtvis baserat på ren okunskap.
Igen så genom att lägga objektet i COM+ för att ändra identitet på det, så måste vi vara medvetna om de komplexa kontexterna vi använder oss av.
Att byta identitet på ett objekt är inte trivialt i .NET men dock fullt möjligt. Har man dessutom skrivit koden en gång så behöver man sällan skriva den igen och man slipper koppla på tunga och komplexa COM+
II) Rollbaserad säkerhet.
Den här tekniken är bra och sätter säkerhetstänket i fokus, men som för alla andra delar så introducerar de kontexter, och när vi nu kan lösa det i .net - varför då COM+?
MYT 4, Enterprise Services är helt integrerat med COM+
Det här är en .NET specifik myt. COM+ är byggt för COM, inte för .NET. Det innebär att den integration som sägs finnas bygger på Interop Services till stor del ( det gäller bara delvis för Library applications ).
Det här innebär ytterligare introduktion av komplexitet för våra system.
Förutom de kontexter som redan finns och existerar i COM+ så ökar vi på prestandaförluster och extra lager genom att lyfta in våra objekt i COM+.
Det här är något som i framtiden kommer att ändras, men i dagsläget är det vad vi måste arbeta med.
Sammanfattningsvis
I Sverige har vi få lösningar där igentligen COM+ 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?
Mats Helander
Bra artikel! Dock vill jag slå ett slag för deklarativa transaktioner, som jag definitvt tror är framtiden. I dagsläget är deklarativa transaktoner = distribuerade transaktioner, och du har naturligtvis helt rätt i att detta är onödigt "dyrt" (prestandamässigt) för transaktioner som bara löper över en datakälla. Men i .NET 2.0 kommer deklarativa transaktioner att förbättras så att de börjar med att köra en lokal transaktion och sedan sparkas en distribuerad transaktion igång som tar över om fler än en datakälla berörs under (den deklarativa) transaktionens gång. Med andra ord kommer "arkitektens våta dröm" att gå i uppfyllelse: Deklarativa transaktioner som inte kostar mer än vanliga lokala transaktioner - utom just i de situationer då distribuerade transaktioner behövs (vilket alltså avgörs runtime, transaktion för transaktion). Detta är enligt min mening den i särklass intressantaste nyheten i .NET 2.0! :-) /Mats
Fredrik Normén
Mycket bra artikel! Skulle iofs publicerats för många år sedan, men bättre sent än aldrig ;)
Johan Lindfors
Men jag vill belysa att de fulhack som du beskriver för att komma runt isoleringsnivå-utmaningar är mycket grant lösta i Windows Server 2003, med en enkel drop-down-lista där du som administratör kan själv välja isoleringsnivå, men se upp vad du gör och lär dig de olika isoleringsnivåerna. Bra dokumentation finns i SQL Server dokumentationen. Du kan också använda "SET TRANSACTION ISOLATION LEVEL" i dina SQL satser. Transaktioner kan du också få ta del av genom att använda Services Without Components i Windows Server 2003. Alla de här nyheterna har jag spelat in en MSDN TV presentation på: http://www.microsoft.com/sverige/msdn/msdntv Men som sagt, intressant läsning!
Martin Ljungqvist
Man kan hantera riktigt stora och transaktionsintensiva databaser genom att använda hints i stored procedures. Förövrigt anser jag att man alltid skall använda stored procedures, eller hur :-) Det som dock är lite tråkigt med COM+ är att varje anrop mellan två COM+ komponenter sker en context switching vilket ger en marchalling (till skillnad mot MTS:en, där anrop skedde inprocss och man fick mycket bättre prestanda). Så mitt råd med COM+ är i likhet med mediciner, if you dont need them, dont use them. Cheers!