We want to be able to call a CSLA object and have the code execute on the server. The code would save data to a database but then call another apps Web Service that could take a few minutes to complete. I have tested calling the web service asynchronously and all is good but my issue is if I do this from a CSLA object I wont be able to update the client with details of the save. So another option is to just call CSLA object and when that comes back make the web service call asynchronously but would like to keep everything on the server.
What other options do I have?
thanks
Sorry, I didnt do a good job explaining. We currently do use .Net remoting for our calls. The issue comes in when you call the server to execute your Fetch or whatever call, then you make an Async call from the server. You lose the ability to tell the client that the Async process is finished.
So the other option is to just make the async call from the client, in our case a windows form, so we know when the Async call is made. I was just curious if I was missing something or maybe not understanding the communication between the server and client through CSLS.
So at this time we are thinking of just making the an async web service call from the client after the CSLA call is finished.
You might try making the fetch async, and then calling the other server syncronously from within the fetch. Since it is already in an async mode, there probably isn't a need to make the second call async.
Version 3.6 introduces support for async data portal calls.
Prior to 3.6, the easiest solution (by far) is to use synchronous data portal calls, but to do it from within a BackgroundWorker component. In fact, this is what 3.6 does behind the scenes (on Windows - it is different in Silverlight).
The process is pretty easy - just create a BackgroundWorker, hook its do work and completed events. In the do work event handler make your data portal call. In the completed event notify the rest of your client app that the server work is done. The BackgroundWorker ensures that the completed event is raised on the UI thread, so you don't have to worry about most cross-thread issues.
Copyright (c) Marimer LLC