“Passive kinds of data”, like countries, regions, etc were done in a similar manner.

The main difference was that they had a well known URI ahead of time as well as longer cache timeouts. Regardless, when that data was changed on the server, it would also update that resource/URI.

Love this approach. Were all the UI requests including more passive kinds of data (enumerated lists of regions for example) also handled by this single architectural approach in this scenario?

I.e.
string MyWSStart(string bla) -> Returns URL “wswait.ashx?id=100″.
Open connection to wswait.ashx and wait for response.
string MyWSEnd() -> Returns result.

I will have it up on my blog at http://www.geekswithblogs.net/jcdickinson/ in a few minutes.

Glad you liked it.

Security is a big topic. The question is what threat profile we’re trying to protect against.

One option is for the same saga that created the resource to protect it with an ACL.

The thing is that you need to understand that probably the only way for an external attacker to know the guid/uri of the resource is for them to go for a man-in-the-middle attack. You’d need HTTPS to protect against that. Once you have that on the request, and you don’t allow anyone to list the response resources, you’re probably secure enough not to need HTTPS on the response.

I listened to your latest DNR episode and after reading this post I must say that this is a really awesome approach. Thx for sharing.

I have a small nitpicking question though: what about security of the response resources (supposing that they contain sensitive information, which is not unlikely). I know its not easy to determine a GUID on the right time (before deleting the resource), but those kid hackers of today can do just about anything. Any thoughts about this topic?

Again, great stuff.

I do use REST where it makes sense – but primarily as a kind of message serialization mechanism.

What he’s describing is using REST/HTTP to do messaging and pub/sub. I think that’s great. However, from a “how do I get my head thinking the right way” perspective, I find that plain messaging and pub/sub is simpler to grasp. Once you understand the applicative protocol you want to set up, mapping that to resources and GETs and POSTs isn’t very difficult.

Does that make sense?

Also I found this page quite interesting (particularly the distributed observer pattern near the end):

http://duncan-cragg.org/blog/post/distributed-observer-pattern-rest-dialogues/

I agree with the first commenter on that post – Rob.
IIS and ASP.NET are not designed to do comet in a scalable way.

There is the other problem of synchronous communication from server to client where server threads end up being blocked while waiting for the communication to succeed.

Hope that helps.

I wondered if you’d looked at the duplex WCF functionality that should help remove the need to do so much polling in Silverlight apps:

http://weblogs.asp.net/dwahlin/archive/2008/06/16/pushing-data-to-a-silverlight-client-with-wcf-duplex-service-part-i.aspx

It’s also really interesting reading this article. I worked on an XML over HTTP project many years ago that used many of these patterns for long running async jobs and it’s good to see you’ve adopted the same techniques.

Glad you like it. Let me know how it works out for you.

I use XSD to define the structure of the data returned. Sometimes additional documentation is needed anyway.

BTW, the X in XML stands for eXtensible (which you already knew), but I’m just reiterating that to say that it is quite easy to add elements in future releases without breaking existing code.

In some cases I could see leaving the schema out of the contract because it makes it easier to add elements in future releases without breaking existing code.

You’re absolutely right – which is why the process which actually writes the response to the disk is the beginning of a saga which may have its final (delete) phase triggered either by a read, a certain number of reads, and/or time.

The trick would be knowing when an item becomes eligible for cleanup. I’m not sure you can delete it immediately after a successful (non-404 response) status request from the user (assuming you can even detect that under IIS, I don’t know). You might want to give them a little more time in case they have system problems at their end.

I actually have another sample with nServiceBus that demonstrates that, but it only works for ASP.NET pages. If you want to call the web service directly from the browser, there is no async model set up.