WCF van toepassing?

[Eriksk]

Hallo,

het volgende is het verhaal:
Op een site worden bepaalde waarden ingevoerd. Hierover worden berekeningen uitgevoerd, waarvan de resultaten opvraagbaar zijn in de website. De berekeningen duren te lang om 'on-the-fly' uit te voeren. De berekening kan gestart worden vanaf de website als de beheerder dat nodig vindt, maar ze zullen doorgaans gestart worden door een scheduler (Windows service). Als een gebruiker de berekening gestart heeft en deze is nog niet afgelopen, dan mag de scheduler niet nogmaals de berekening starten.
Alles vindt plaats op één Windows 2003 machine (muv de database).

Ik heb nog nooit wat met remoting (WCF) gedaan, dus ik vroeg me af of dat hiervoor geschikt zou zijn. Dan zou het remoting object, de berekening en logging doen en bijhouden of deze bezig is of opnieuw gestart mag worden.
Waar kan ik dan het beste de remoting object plaatsen? En als ik het goed begrijp dan zou het object een singleton moeten zijn...

Zit ik in de goede richting?

Overzichtje:


Alvast bedankt

[D-Raven]

Waar je het de service plaatst die de bereking voor je uitvoert is helemaal aan jou. Lijkt mij dat het niet op dezelfde machine zal draaien als de website. Je wilt ten slotte dat dat ding een of andere "zware" bereking gaat uitvoeren. Een aparte pc lijkt mij dan misschien wel zo handig. Maargoed dit kan jij beter bepalen dan ik .

Een singleton ? Een wcf service is nooit een singleton. Wat je kunt doen is in je object structuur wat achter je "publieke" service interface zo implementeren dat je wcf service gewoon een call op een manager class doet, welke teruggeeft wat zijn status is (Bezig, Gestart, Klaar o.i.d). Die manager klasse zou dan singleton achtig gedrag bevatten want hij moet tenslotte de status van de operatie bewaren.. Maar ikzelf zou dan een static status object gebruiken welke het laatste resultaat bevat.

[Eriksk]

Ik dacht eigenlijk aan het implementeren van .NET Remoting, zodat je remoting object een singleton is. Die wordt dus niet bij elke call opnieuw gecreëerd. Bij WCF maakt het niet meer uit welke techniek je gebruikt (webservice / Remoting / Message queue), maar dat principe (van dat singleton object) blijft toch wel?

[D-Raven]

Ik zou WCF geen remoting noemen. Met WCF bouw je een service, en hoe deze communiceert met de buitenwereld (p2p, soap, whatever) maakt wcf transparant.
Je bouwt dus een service welke jou client aanroept om dingen gedaan te krijgen. Deze client doet dit via een proxy welke gegeneerd is door een tool in het .Net framework. In het algemeen lijkt het dus meer op de consumeren van een (web) service dan echt Remoting (zoals corba etc, dingen waaraan ik denk als ik het woord Remoting hoor/lees).

Het zeggen dan je remoting object een singleton is, is ook niet correct.
Je maakt een instantie van je proxy (clientside), welke verbinding met de service maakt. Deze service wordt in princiepe maar 1 keer gestart. Maar afhankelijk van je configuratie kan dit verschillen.

Maar je kan best in deze situatie een WCF service gebruiken. Omdat je vanuit een website werkt is het misschien net zo handig om er een webservice van te maken.

[Laurens-R]

Als je serieus WCF zou willen gebruiken, zou ik me eerst even goed verdiepen in SOA.

WCF heeft namelijk niet speciaal iets te maken met het op afstand uitvoeren van zware berekeningen, maar is een hulpmiddel voor het gemakkelijk opzetten van services. Deze services kan je vervolgens weer middels SOA modelleren en in je business integreren.

SOA is namelijk een way of thinking en geen specifieke werkwijze of technologie.

[Verwijderd]

Zelf zou ik Mutex gebruiken: Wikipedia: Mutual exclusion

[Laurens-R]

Mag ik vragen wat mutexes hier mee te maken hebben? Het gaat nu om het centraal aanvragen van informatie/services... mutexes is manier die bij multithreaded programmeren gebruikt word, om gelijktijdig gebruik van resources uit te sluiten

[Niemand_Anders]

Je kunt toch simpel in de database de state van het record zelf wijzigen? Als de state 'calculated' is, dan hoeft de windows service het record niet meer te verwerken.

Als je de berekening vervolgens in een aparte assembly onderbrengt kun je die assembly (business en data logics) gebruiken in zowel de WFC service als de Windows service.

Je WFC service / website zou ook eventueel een NamedPipe kunnen aanroepen welke de Windows Service hosts.

[Eriksk]

Er moet dan in meerdere tabellen eem IsCalculated, CalculateAgain en CurrentlyCalculating velden komen
Los daarvan, mijn verbinding valt weg en de velden staan op dat moment verkeerd! De berekeningen zouden best lang kunnen duren, dus om een lange db-transactie te starten lijkt mij niet wenselijk.

Ik dacht dus aan een centraal object die zelf weet welke nog berekend moeten worden. Iedereen die iets wil berekenen moet uiteindelijk bij dit object uitkomen. Maar hoe creëer ik zo'n object, die dus eigenlijk altijd bestaat en maar één instantie van is...

[Niemand_Anders]

Meerdere tabellen? Elke berekening heeft een 'basis' tabel waarvan andere tabellen gekoppeld worden om alle informatie op te halen. Aan die basis tabel voeg je dan een veld CalculatedState toe (TinyInt). 0 = not started, 1 = calculating, 2=calculated. Je kunt namelijk nooit meerdere states op hetzelfde moment krijgen. Op het moment dat een berekening opnieuw uitgevoerd moet worden zet je de state simpelweg weer op 0.

Overigens, zelfs als je een object hebt welke precies weet wat wel en niet berekend is, zul je *die* informatie ook ergens moeten opslaan. En waarom mogen er geen meerdere instanties van dat object zijn? Zolang je voorkomt dat een berekening niet dubbel wordt gestart (gebruik van CalculatedState) hoef je hier geen problemen te verwachten.

Ik weet niet precies wat voor berekeningen je uitvoert, maar misschien is Linq to SQL (l2s) geen slecht idee. Met l2s kun je database records verwerken alsof je alles al lokaal hebt. Pas als je alle informatie hebt geupdate, roep je de SubmitChanged methode van de DataContext aan en dan worden als je wijzigingen atom en middels optimistic concurrency verwerkt op de database. Database transacties moet je *JUIST* gebruiken als je veel records gedurende langere tijd gaat aanpassen.

Als je meerdere berekeningen tegelijktijd uitvoert, zorgt dan wel dat je aan de DataContext een connectie meegeeft, en hem niet de standaard connectie laat gebruiken. De DataContext cached namelijk dan de connectie (private static declaratie).