Attendee question of the day:
A long running CPU and memory intensive piece of work needs to be done when requested by a user in an ASP.NET application and then reported back to the user when complete. How do you do it without placing too much load on the ASP.NET server?
A possible solution:
Start a new thread from the ASP.NET request. This new thread should not do the work itself but rather use Remoting to invoke the work on a remote server (that may be dedicated to the intensive work). But how do you get updates back to the user? You can either do it in a truly disconnected manner by sending an email to the user when the work is complete or you can have something on the user’s browser poll back to the server for updates. Possibly looking in Cache for updates posted by the thread using the Remoting object. You could do this polling using a simple META REFRESH (ugly) or use something more elegant (and lightweight) such as Remote Scripting.
I implemented a very similar solution to kick off NAnt scripts and watch their output from an ASP.NET application. It used Remoting to a ScriptRunner object hosted by a Windows Service. All output was captured by the ScriptRunner and then retrieved using Remote Scripting calls to get the status update from the thread holding the reference to the Remoted object inside ASP.NET.
I presented “Remote Scripting in .NET” for the first time last Wednesday (1/28/2004). The event was held at Microsoft’s offices in Findlay, Ohio. There were about 30 people with quite a few Microsoft employees. The presentation digs deep into how Remote Scripting works and gets rather technical in places – this knowledge is not necessary to use Remote Scripting but it is often useful to really understand what is happening. It also looks at how the landscape has changed with .NET and Microsoft phasing outsupport fortheir JVM. I was worried that I may have lost the audience in places but was very pleasantly surprised by the number of probing and interesting questions I received.
There was a certain feel of Remote Scripting vs. Web Services which I should have anticipated but didn’t. They are different tools and both have their strengths … as with all technology decisions – it depends on your requirements!
Presentation slides and demo code are available for download.
The demo code is interesting in that it implements a simple remote call to look up a book title by ISBN from clientside script in a webpage using:
1) Microsoft Remote Scripting client (applet)with ASP
2) msrsclient clientwith ASP
3) Microsoft Remote Scripting client (applet)with ASP.NET
4) msrsclient client with ASP.NET
5) IE behavior client with ASP.NET Web Service.
Some of the interesting questions that came up:
Q–What about security?
A – You can use Remote Scripting over HTTPS/SSL.
Q – What about using Remote Scripting from a Windows Forms application?
A – Hmmm … a web service would certainly be a much easier fit since you would have to write a WebRequest based client or do something really hokey with a hidden Browser control!
Q – Which is more scalable and which yields better performance?
A – I plan to run some benchmarks. I suspect that Remote Scripting is lighter weight due to using a less verbose protocol although it is based on System.Web.UI.Page which may have more overhead than a custom HTTP handler as used by Web Services.