Ok, that is something i might continue with, i'll dive deeper into this for sure. I must :)
Unless someone knows that this won't work cause of serialization problems etc?
Threats in C# are kinda simple, invoking the main threat etc from an background isn't hard, just something u need to know when u are using it. No need for using mutexes, semaphores, etc..
The dataportal in CSLA makes it differend, there must be some communication meanwhile between the client and the server.
Until later...
The question is push vs pull.
If you want the server to push a message to the client, that's hard. The reason, is this means that the server must be able to open an IP connection to the client, and typically a client does not have a routable IP address (the server can't ping the client).
Windows Azure .NET Services (or whatever the current name is - used to be Biztalk Services) solve this using the same sophisticated technology used by chat programs, online games, etc. I think the book Gaming Gems 4 (or 5?) has a chapter discussing the low level networking code you need to write to allow a server to punch a hole through most NAT/firewall scenarios - it is gory.
The other alternative is for the client to open a persistent IP socket connection to the server. You can't do this over HTTP, because HTTP doesn't allow it. But you can do it with TCP, and there may be a WCF channel that works this way (dualTcp?). It would be interesting to see whether this would work through the data portal. It might, if you put the callback reference into Csla.ApplicationContext.ClientContext.
If you want the client to pull a message from the server, that's easier. In this case, the client polls the server for messages and processes any it gets. This is how the Silverlight dualHttpBinding works in WCF btw - they just continue to poll the server to get messages.
You could do this with the data portal too, though you'd have to figure out a way to share state between the original (long running) request and the subsequent get status requests. In a balanced web farm these could run on different machines, so you probably need to maintain the shared state in a database table or something.
The strange thing is there isn't nearly any related question about this on the forum, hasn't anyone else ever ran into a situation like this.
About a balanced web farm, i think there will be strange, unforseen errors.
I guess u are right about pulling messages is easier.
Thanks for the insight!
Copyright (c) Marimer LLC