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.

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. 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]