[WCF] C# Asynch calls met feedback

[Blitz]

Beste mensen,

Ik heb momenteel een programma dat om de 6 maanden tabel updates krijgt toegestuurd van een fabrikant. Dit zijn meestal zip bestandjes die 20-40 MB zijn en die bewerken alle SQL Hoofdtabellen met nieuwe medische informatie.

Momenteel heb ik al code geschreven die functioneert op Server niveau maar nu wil ik het maken dat deze ook via een WCF kan draaien. Ik loop echter al tegen 2 technische obstructies.

Omdat ik Silverlight ondersteun kan ik niet zomaar een zip openen op de Client side dus mijn besluit is om een ZIP toe te sturen naar de server zodat deze het allemaal zelf kan openen en inlezen. Een zip ziet er meestal zo uit:

Levering2011
- Hoofdactiviteiten.csv (50,000 tot 100,000 records)
- Subklassen.csv (700 records)


Het komt erop neer dat er een enorm aantal records nodig zijn om het programma in te lezen. Het probleem dat ik natuurlijk tegenaan loop met WCF is dat dit soort dingen uit testen sosm 15-50 minuten kan duren. En mijn vraag is concreet. Als ik een WCF service asynch call doe die de zip aanlevert Is het dan mogelijkom de client status updates te geven? Ik las al iets van een service broker maar ik krijg de indruk dat mensen juist willen dat je aan de cleintside alles gaat uitpakken en dan inlezen. Wat een mogelijkheid is maar dan moet je twee code basisen gaan onderhouden omdat bij silverlight er geen API is die de zip kan openen die ook bij WPF aanwezig is.

het mooiste zou zijn is dat de server het zipje uitpakt en gaat verwerken en dat daar berichtjes worden terug gestuurd dat de zip geopend is dat de hooofdactiviteiten nu wordt geupdate etc..

Heeft iemnd hiermee ervaring?

[CodeIT]

Wat je omschrijft is volgens mij goed te doen dmv duplex services:
Hier een goed artikel+voorbeeld: http://weblogs.asp.net/dw...uplex-service-part-i.aspx

[barfieldmv]

Wij doen het door 'server' jobs die de aktiviteiten draaien en updates naar een sql server tabel schrijven. Gewoon de sql server uitlezen op job id.

Nou ja, in ons framework zit geen tabel meer en is alles eigenlijk weg gewerkt in een stel base classes. Maar je snapt het idee.

[Niemand_Anders]

Dit soort zaken los ik meestal anders op. Ik gebruik meestal 'command queues' voor dit soort zaken.

De client doet eerst een verzoek om een command ID aan te maken.
Met dit ID kun je vervolgens het process aansturen en de status ervan opvragen.

Vanaf de client stuurt je dus bijvoorbeeld elke 2 seconden een update request.
De server geeft dan de status terug.

Omdat ik in mijn applicaties veelvuldig gebruik maak van message queues (service bus), is de werking vanaf een Silverlight client niet heel erg veel anders.

C#:

public class ProcessUpdateMessage
{
   public ProcessUpdateState State { get; set; }
   public string Message { get; set; }   
}

public enum ProcessUpdateState
{
   NotStarted,
   Running,
   Finished
}

De client kan uit de Message property de voortgang halen zolang de status 'running' is.

Maar als ik eerlijk ben, gebruik ik niet helemaal wat silverlight met informatie updates te maken heeft. Tenzij via de silverlight client de zip bestanden worden geupload, vinden lijkt mij de overige processen (zoals import van data) plaats op de server.

Daarnaast is het belangrijk om in het achterhoofd te houden dat WCF altijd one-way messaging is. In duplex mode doet WCF de polling voor jouw. WCF is geen CORBA implementatie. Echter als je zelf de polling verzorgt ben je flexibeler en kun je later ook overstappen naar bijvoorbeeld een servicebus implementatie.

Overigens maak ik meestal gebruik van een REST service ipv WCF.