(.NET 2.0 beta 2)

Hej!

Jag har ett litet problem: Jag har en webservice som hostas utav iis 6, dessutom har jag en windows service som gör allt jobb. Jag behöver ett sätt att snabbt kunna skicka saker mellan de här två tjänsterna (asp.net körs ju som tjänst, samma sak med mitt program) så windows messages är ju uteslutet.

Det jag funderar lite på är remoting, fast är det kul att ha egentligen? Hur pass snabbt är det? Hur fungear det på större datamängder?

Hur arbetar asp.net:s isapi när den jobbar mot asp.net-tjänsten?

Någon som har någon koll på det här, det spelar ingen roll om win32 api behöver användas eller annan unsafe-kod, hastighet och stabilitet är det viktigaste

/Mvh
Oskar Johansson

Hittade precis följande sida hos microsoft: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/interprocess_communications.asp

Nu funderar jag på om "Anonymous Pipes", "File Mapping" mot swap-filen eller någon COM-historia är det bästa. själv tycker jag anonymous pipes verkar intressantast. Någon som har några kommentarer?

Nu har jag hittat en implementation av Name Pipes för .net som verkar rätt vettig:
http://www.codeproject.com/csharp/DotNetNamedPipesPart1.asp
http://www.codeproject.com/csharp/DotNetNamedPipesPart2.asp

Någon som har några erfarenheter om det här?

<citat>
Någon som har någon koll på det här, det spelar ingen roll om win32 api behöver användas eller annan unsafe-kod, hastighet och stabilitet är det viktigaste
</citat>
Hastighet och stabilitet rimmar faktiskt lite illa när du pratar om webservices, inget fel i webservices och prestandaförlusten är inte speciellt stor, men flaskhalsen ligger nog knappast i kommunikationen mellan din ASP.NET kod och Servicen, utan i gränssnitten mot din webservice.

I ditt fall så hade jag gjort din NT Service som en COM+ komponent och sedan hostat den som en WindowsService. Det finns en vis overhead i användning av COM+ men du kan minska ner den genom att använda dig av pooling och JIT. Samtidigt så får du en stabill service som enkelt kan igå i Transactioner om detta blir ett krav längre fram.

Eftersom du sysslar med BETA 2 så kanske en beta version av Indigo skulle vara något för dig, den löser alla din kommunikationsproblem på ett smidigt sätt, det dröjer dock ett tag innan den kommer i skarpversion.

- M

Tja, nu har jag ingen riktig koll på com+ :/

Men visst, kan vara värt att titta på. Kan ju säga att jag funderat på det, det jag funderar mest på är hur debuggningen kommer att bli. Hur fungerar det när det gäller debuggning på com+-appar?

Nu har jag kört msdntv + google, hur hostar man server-delen själv? Som jag har förstått det så drar com+ själv igång en tjänst vid namn dllhost.exe men det vill ju inte jag? Någon idé?

"Som jag har förstått det så drar com+ själv igång en tjänst vid namn dllhost.exe men det vill ju inte jag?"

Vill du inte ha en process igång eller vill du inte att den skall heta dllhost.exe?

Varken eller, jag vill ha en process igång men jag vill att det är min process.

Jag har två tjänster igång, den ena tjänsten är asp.net, den andra är min egen. Jag vill hosta com+-servern för min applikation i min egna tjänst, inte i dllhost

Som jag förstått det så alla "server komponenter" som du hostar i COM+ kommer att heta ddlhost. Ingne anning om du kan ändra på det men det tror jag inte.

Om du inte vill det så är lösningen att skriva en egen NT Service och använda dig av typ remoting för att kommunicera mellan din ASP.NET sida och din NT Service.

Är dock lite nyfiken på vad du skall göra, för det kanske finns en annan bättre lösning om du beskriver mer vad som skall hända i din NT Service.

- M

Jo...

Saken är att jag vill utföra allt grovjobb i en egen service, det är inte riktigt smidigt att stoppa in det i t.ex. asp.net eftersom att jag kanske behöver fler gränssnitt än just webservices.

Anledningen till att jag inte vill hosta i dllhost är att jag då i så fall kommer com+ endast att fungera som en brygga, totalt blir det så att allting måste korsa två processgränser varje istället för endast en gräns (asp.net.exe -> dllhost.exe -> min_service.exe)

Jag vill inte exekvera alltihopa i com+, känns inte som att jag har någon bra anledning till att göra så, dessutom känns det som att jag förlorar en del kontroll på exekveringen av kod och skaffar mig lite bekymmer vid debuggning.

Remoting har jag tittat en del på, problemet är att jag upplever det lite för långsamt (har dock inte gjort några praktiska test än, men det känns ändå lite långsamt med en massa serializering och nätverkstrassel)

Det jag sitter och gör nu är ett ramverk för ett projekt jag håller på att dra igång. Håller på att skriva ett debugging-ramverk för services, håller dessutom på att fundera på hur jag enklast ska föra över saker inom en dator över processgränserna med så hög hastighet som möjligt utan att det blir instabilt.

Jag har redan en egen NT tjänst, hur får jag den att kommunicera med andra saker på burken? :P

Vilken sorts data är det som skall skickas i ditt gränssnitt?

Är det mer eller mindre funktionsanrop med några parameterar eller skall du skicka stora datamängder ( > MB)?

En annan variant är gamla hederliga sockets vilket kan vara användbart om du skall skicka stora datamängder via ett enkelt protokoll (typ en klump data in och en klump data ut) och eventuellt flytta på din service till en annan maskin. Haken är att du får snickra ett eget protokoll. Och det känns litet 80-tal, det borde gå att göra snyggare i .NET.

Är det en massa anrop med litet mer invecklade parametrar som skall göras så skulle jag nog sikta på Remoting, men jag är som dig inte säker på prestandan, men jag tror inte att det är något problem i sammanhanget (i alla fall inte om det är en Web Service som är front-end).

IMHO.

Litet mer detaljer om vad för sorts anrop skulle vara trevligt.

/Andreas

Sockets vill jag helst slippa, känns som en omväg, någon form av delat minne vore smidigare känns det som ;)

Hur som haver, exakt vilken data som kommer att skickas vet jag inte, eller snarare, det kommer variera. Jag bygger endast ett ramverk nu, datan som kommer att skickas kan variera mellan några få bytes till några kilobytes till någon megabyte eller ännu mera. Jag vet inte, just nu handlar det om kilobytes. Vill dock inte av misstag låsa mig vid något som kan bli en stor flaskhals i framtiden (t.ex. kan det bli så att två olika services måste kunna prata snabbt med varandra, eller att en helt vanlig asp.net-sida ska kunna prata med servicen och skicka data fram och tillbaka några gånger)

Jag är till 99,9% säker på att service och webservice inte kommer befinna sig på olika maskiner. Däremot är det mycket möjligt att olika services kommer prata med varandra, men det är ett annat problem som jag antagligen kommer lösa med remoting

Aja, jag får se, kanske remoting är ett smidigt sätt att lösa problemet på, om ingen kommer på något "kuligare" än remoting så får det kanske bli det

Sockets kan ju ses som delat minne som endast läses seriellt :-). Om man dessutom har en socketförbindelse mellan två sockets på samma maskin så är det förmodligen implementerat med delat minne. Poängen är flyttbarheten. Jag vet många applikationer (väldigt vanligt i Java-världen) där man använder sockets för att prata mellan olika delar av ett system.

Men jag håller med dig, är det ett mer komplicerat gränssnitt än att knuffa stora klumpar med data så är nog Remoting ett bättre val så länge det är OK att låsa sig till .NET-plattformen (vilket det förmodligen är iom att du är i det här forumet :-) ).

/Andreas

Det kommer nog vara rätt låst när det gäller serversidan ;) Mitt projekt handlar om att låta vem som helst vara klient i slutändan :P (Väldigt förenklat, tryckte upp en tråd i något hjälp-mot-ersättnings forum här, tyvärr inget intresse :P )

"Anledningen till att jag inte vill hosta i dllhost är att jag då i så fall kommer com+ endast att fungera som en brygga, totalt blir det så att allting måste korsa två processgränser varje istället för endast en gräns (asp.net.exe -> dllhost.exe -> min_service.exe) "

Nja, du plockar ju dina kod från din service.exe och lägger som en egen dll som hostas i COM+ vilket då istället kommer att bli.

(asp.net -> dllhost.exe) eftersom din kod ligger i COM+ och exekveras där och inte i din egen NTService.

"Jag vill inte exekvera alltihopa i com+, känns inte som att jag har någon bra anledning till att göra så, dessutom känns det som att jag förlorar en del kontroll på exekveringen av kod och skaffar mig lite bekymmer vid debuggning."

Man skall inte blanda in COM+ i onödan då det finns en visoverhead med det hela, dock ingen jätte overhead. Vi har precis byggt en egen EnterpriseGateway på jobbet och i den så gör vi en fasligt massa hemska prestandakrävande saker.
- Det börjar med ett webservice anrop, som kallar en COM+ komponent som kallar en annan COM+ komponent som loggar till databasen vad som hänt, samt input data och annat smått och gott.
- Den första COM+ komponent kallar sedan en annan COM+ komponent som i sin tur klara en annan COM+ komponent för att få lite settingsdata.
- Går tillbaka till den andra COM+ komponent och med hjälp av reflection så laddas en dll och exekveras i denna dll
- Denna dll processar lite info och kallar LogCOM+ komponnet som skriver ner i en databas
- Går tillbaka till den COM+ komponent som exekverade DLL och kallar ytterligare på LOGCOM+ (som återigen skriver till databasen) komponenten.

Under tiden så serializeras/deserializeras input data och output data mellan object och xml-strängar några gånger. Samt andra kontroller och krims krams... Totalt tar detta 30ms när vi kallar webservicen lokalt på maskinen. Vilket är helt okej med tanke på att vi har lagt en transaction runt hälften av det.

Några bekymmer vid debugging skaffar du dig inte, inte mer än vid en vanlig NT-Service allafall. Inte heller så förlorar du kontrollen vid exekvering av kod

Där emot så är jag lite nyfiken, varför inte bara använda vanliga DLL som du refererar till i din ASP.NET kod. Jag ser helt klart fördelen av att inte göra så, det blir mer SOA genom att inte referera dll i varje program, utan istället kalla en service som står och kör.

En annan sak som du bör tänka på när du kör det som en NTService är hur du hanterar flera samtidiga anrop. Jag har lite för dålig koll på hur det fungerar men jag misstänker att du endast kan hantera single anrop in till din NTService och du där i får start en ny tråd och köra koden vidare. Men som sagt har tittat väldigt lite på detta så jag kan ha fel. COM+ sköter denna hantering till dig och kan ha flera instanser av dina komponenter igång samtidigt.

.NET Remoting är nog den bästa och enklaste lösningen för dig (om du inte vill använda COM+), internt mellan 2 olika AppDomainer så körs ju remoting automatiskt av .NET så någon större prestanda förlust jämfört med något annat protocoll tror jag inte du får.

Allternativt så får du funderar på att ASP.NET webservice skriver till en minnesposition och att din Service sedan läser från denna minnesposition, typ någon memorystream, men det låter inte riktigt värt tiden och de felmöjligheter som detta innebär.

IMHO så skulle jag nog satsa på en komponent som gör det du vill som du sedan hostar i COM+ istället för att du hostar den i din NTService. Om du vill vara säker på att COM+ komponeten startar när maskinen startom, så säger du att den skall köras som en service (det betyder inte att det blir fler processbounderies, inte som jag förstått det iallafall).

- M

"Mitt projekt handlar om att låta vem som helst vara klient i slutändan :P"

Du är en COM+ lösning abosult enklast, det är ju bara att refererar DLL i sitt nästa projekt, istället för att syssla med sockets och remoting.

- M

Hm... Jag är fortfarande tveksam till det hela med com+, det där med att vem som helst ska kunna vara klient har inte så mycket att göra med servicen, snarare att de som "ansluter" till servicen kan leverera data till t.ex. mobiler, pda:s, webbläsare, program etc. etc.

Debuggningen är jag tveksam till också, just nu har jag skrivit en fullt fungerande service-emulator som låter mig dra igång debuggningen som om man skrev ett helt vanligt windows-program, jag slipper med andra ord allt vad installutil och riktiga tjänster heter.

Jag är nog nästan med inne på remoting tror jag, känns som att det blir vettigare till det här

Jag har inte läst hela tråden men tittar på ursprungsfrågan. Du har webbservice och en windows service och vill få dessa att prata med varandra snabbt.

Mitt svar är databasen. Låt servicen hämta och leverera data till databasen, din windows service kollar givetvis i samma databas för att utföra arbetet, troligen per intervall eller nåt annat. En sql-server har också triggers som i sin tur faktiskt kan köra exe-filer eller varför inte sparka igång servicen om just en sådan behövs för arbetet.

Det skulle nog inte riktigt fungera med den hastighet jag behöver, dessutom blir databasen då en flaskhals eftersom att kommunikationen bara ska ske inom servern, databasen ligger då ute på nätverket och allt blir segt :/

Varför inte göra ett försök. Hur transaktionsintensivt är egentligen applikationen? Vad har ni satt upp för krav att den skall klara att ta emot/lagra/leverera? En sql-databas på samma server torde kunna hantera några tusen transaktioner per sekund eftersom databasmotorn klarar bättre prestanda än många tror.

En annan variant är att skriva en virtuell cache i ett com-objekt som du lägger i mts:en för att få högsta prestanda som i princip håller all data som den fylls med men det innebär även risker om servern går ner eller annat - då kommer den nollställas.

Du får nog specificera lite tydligare för att kunna få en bättre bild över vad man kan rekommendera.

Tja...

Webservice (eller någon annan tjänst, eller ett program eller vad som helst) ska kunna prata med en service. Servicen är själva motorn i alltihopa. Det är inte säkert att alltihopa kommer ligga på en server, det är mycket möjligt att t.ex. ett program och servicen kommer ligga på en klientdator. De måste kunna prata med varandra på ett så snabbt och effektivt sätt som möjligt. Dessutom vill jag inte binda upp mig för mycket mot en massa saker utom just sådant som är gratis eller ingår i t.ex. win2k, windows xp eller win2k3.

Jag håller på att fundera på remoting men jag vet inte om jag är riktigt nöjd med det heller :/

Hur mycket prestanda skulle man förlora på att använda COM+ med out-of-process, man skapar bara en "bufferkomponent" som sedan både webservice och service får ansluta till, servicen i form av "server" medan webservicen ansluter i form av "klient"?

"Det är inte säkert att alltihopa kommer ligga på en server, det är mycket möjligt att t.ex. ett program och servicen kommer ligga på en klientdator."

Jag har lite svårt att se vad det är du egentligten vill göra. Du verkar inte själv har riktigt koll på hur det hela fungerar, det underlättar om du vet hur den färdiga lösningen skall se ut innan vi diskuterar tekniska detaljer.

Om du pratar Service i ett SOA sammanhang, så är servicen placerad på ETT ställe och alla program runt omkring accessar den service på denna maskin, men nu verkar det som om du vill installera en service och programet på varje klientdator? Har jag missförstått dig?

- M

Servicen är bara en miljö för "plugins" att köras i.

Andra saker, oavsett vad, som är skrivna i .net ska kunna prata med den här servicen. De ligger alltid på samma dator. Det kan vara ett annat program, en annan service, en webservice, en asp.net-sida eller vad som helst.

Själva servicen kan lika gärna vara ett vanligt program, den hostar dock fortfarande samma "plugins". Oavsett vad så måste andra program kunna prata med den här saken.