Generation 5 » Managing Concurrency With Asynchronous HTTP Requests

 Subscribe to our RSS Feed | About Us

Managing Concu...
Generation 5 » Managing Concurrency With Asynchronous HTTP Requests

Reply

Generation 5 » Converting A Synchronous Progra...
Upcoming SlideShare
Loading in...5
×

Managing concurrency with asynchronous http requests

158

Published on

I developed a rather complicated GWT application last summer and spent plenty of time struggling with the concurrency issues involved with with applications that use asynchronous web requests: for instance, the HttpWebRequest in Silverlight or the XmlHttpRequest in Javascript. Up until Silverlight 2 beta, Silverlight programmers could perform synchronous requests, but the latest version of Silverlight supports only asynchronous requests… We’re scrambling to update our apps.

There’s a “standard model” that works for writing reliable, performant and secure RIAs — it works for GWT, Flex, and Silverlight and plain old AJAX apps too.


The model is that one user UI action should cause one http request with the server and the server should send back a bundle of data that has everything needed to update client state and redraw.

Sound familiar? This is the proven model that conventional web applications use — it works, unlike the generation of failed “client/server” apps we saw in the 90′s that showed that the general problem of client/server choreography is hard to do in practice; particularly with a system like GWT that offers very little support for dealing with concurrency.

Put all the business logic on the server; maybe you can do some form validation on the client, but do it again on the server. Since GWT and Silverlight let you code with the same language on client and server, it’s easy to share code.

Both client and server can send each other “state update” packets that bundle an arbitrary number of commands that are, preferentially, bundled into a single transaction.

Note that this goes against the general principle that complicated operations should be done by composing them out of simpler operations — that’s an excellent principle for developing object-oriented systems that live in a single address space, but it’s a dangerous way to build applications in distributed systems: if a client operation requires 20 web requests, a reliable application needs to do something correct when 19 of those operations succeed and 1 of them fails — never mind the cost in latency.

Now, it’s not possible to do this in every case: there really are cases where you need to connect to a legacy server that you can’t redesign, where there constraints on the client-server protocol, or you can save bandwidth by having the client make selective results (if some information is cached.) If you’re going to do that, you need design patterns that provide reliable answers to common problems. I’ll be talking about that in the next few days.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
158
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Managing concurrency with asynchronous http requests"

  1. 1. Generation 5 » Managing Concurrency With Asynchronous HTTP Requests  Subscribe to our RSS Feed | About Us Managing Concurrency With Asynchronous HTTP Requests I developed a rather complicated GWT application last summer and spent plenty of time struggling with the concurrency issues involved with with applications that use asynchronous web requests: for instance, the HttpWebRequest in Silverlight or the XmlHttpRequest in Javascript. Up until Silverlight 2 beta, Silverlight programmers could perform synchronous requests, but the latest version of Silverlight supports only asynchronous requests… We’re scrambling to update our apps. There’s a “standard model” that works for writing reliable, performant and secure RIAs — it works for GWT, Flex, and Silverlight and plain old AJAX apps too. The model is that one user UI action should cause one http request with the server and the server should send back a bundle of data that has everything needed to update client state and redraw. Sound familiar? This is the proven model that conventional web applications use — it works, unlike the generation of failed “client/server” apps we saw in the 90′s that showed that the general problem of client/server choreography is hard to do in practice; particularly with a system like GWT that offers very little support for dealing with concurrency. Put all the business logic on the server; maybe you can do some form validation on the client, but do it again on the server. Since GWT and Silverlight let you code with the same language on client and server, it’s easy to share code. Both client and server can send each other “state update” packets that bundle an arbitrary number of commands that are, preferentially, bundled into a single transaction. Note that this goes against the general principle that complicated operations should be done by composing them out of simpler operations — that’s an excellent principle for developing object-oriented systems that live in a single address space, but it’s a dangerous way to build applications in distributed systems: if a client operation requires 20 web requests, a reliable application needs to do something correct when 19 of those operations succeed and 1 of them fails — never mind the cost in latency. Now, it’s not possible to do this in every case: there really are cases where you need to connect to a legacy server that you can’t redesign, where there constraints on the client-server protocol, or you can save bandwidth by having the client make selective results (if some information is cached.) If you’re going to do that, you need design patterns that provide reliable answers to common problems. I’ll be talking about that in the next few days. Paul Houle on March 27th 2008 in Asynchronous Communications, Dot Net Comments (3) Comments (3) Login Sort by: Date Rating Last Activity Generation 5 » Optimistic Locking For Retrieving Result Sets [...] then you’re displaying the result of the search. The most reliable way to do this is to use Pattern Zero, which is, do a single request to the server that retrieves all the information — in that [...] Thibaud Lopez Schnei · 289 weeks ago 0 Hi, I wrote a paper that proposes simple rules to transform synchronous code to asynchronouse code: http://www.thibaudlopez.net/xhr/Writing%20effecti... . Hope it helps! (I'm sorry it's still in PDF format and has no examples yet, just pseudo code.) http://gen5.info/q/2008/03/27/managing-concurrency-with-asynchronous-http-requests/[1/12/2014 8:33:22 PM] Search for: Search Archives June 2012 (1) August 2010 (1) May 2010 (1) June 2009 (2) April 2009 (1) March 2009 (1) February 2009 (3) January 2009 (3) November 2008 (1) August 2008 (2) July 2008 (5) June 2008 (5) May 2008 (2) April 2008 (6) March 2008 (8) June 2006 (1) February 2006 (1) Categories AJAX (2) Asynchronous Communications (16) Biology (1) Books (1) Design (1) Distributed (1) Exceptions (2) Functional Programming (1) GIS (1) Ithaca (1) Japan (1) Math (1) Media (3) Nature (1) Semantic Web (3) Tools (28) CRUD (1) Dot Net (17) Freebase (2) GWT (9) Java (7) Linq (2) PHP (6) Server Frameworks (1) Silverlight (12) SQL (5) Uncategorized (1) Web (2) Analytics (1)
  2. 2. Generation 5 » Managing Concurrency With Asynchronous HTTP Requests Reply Generation 5 » Converting A Synchronous Program Into An Asynchronous Program [...] and GWT)  is expressing the flow of control between multiple asynchronous XHR calls.  A “one-clickone-XHR” policy is often best,  but you don’t always have control over your client-server [...] Post a new comment Enter text right here! Comment as a Guest, or login: Name Email Website (optional) Displayed next to your comments. Not displayed publicly. If you have a website, link to it here. None Subscribe to None Submit Comment Copyright © 2013 Generation 5. WordPress Theme design. http://gen5.info/q/2008/03/27/managing-concurrency-with-asynchronous-http-requests/[1/12/2014 8:33:22 PM]

×