Will conversational flow engines and AJAX help with the coming multi-core problem?

A lot has been said about the coming issues as multi-core processors become mainstream if that hasn't happened already. Processors are getting more cores but individual cores are getting slower. This means that applications will need to be written in a parallel fashion to really take advantage of this and the majority of people will find that difficult, it isn't easy to do.
I've written quite a bit about this but I was thinking yesterday about the impact of all and AJAX and conversational state engines might just a a solution for a lot of web applications.
AJAX basically changes the way web applications are written. Pages before AJAX were monolithic. A single button resulted in a servlet processing the information a page at a time. A page might have had quite a bit of information on it with a lot of fields to validate against a database or caches etc. All of this logic would run on a single thread in the web container. Customer could multi-thread it but that wasn't easy.
AJAX changes this because each field can be validated 'live' using RPC calls to the server that process fields at a time. As you type the various fields on the page, each field can be validated separately using it's own RPC call from the page to the server. This results in many more server RPCs per page than pre-AJAX days but each RPC is much simpler than before also. This allows us to process the page using more smaller RPC and these RPCs can potentially overlap depending on how quickly information is filled in or how the page does things. Breaking up monolithic logic in to potentially parallel streams of smaller units of work is a good recipe for success on todays multi-core processors. Yep, there is more overhead because of the RPCs but it's probably a good trade off, those MIPs have to be used for something, right?
JavaEE does very little for people having to parallelize applications to run well on newer processors. But, Web 2.0/AJAX style applications and the new wave of POJO conversation centric flow engines may provide the building blocks to allow the masses to write parallel code without even realizing it. Conversation centric flow engines should also allow interactions with backend systems to be parallelized also in a natural way thats coded in the same way as people code web flow conversations using frameworks like Spring WebFlow. I can see how as the conversation flow engines like WebFlow evolve then they can also be used to parallelize many tasks in a familiar way and products like ObjectGrid can make that flow reliable and fault tolerant. By evolve, I mean, the conversation needs to be made independent of the web context and instead just be usable in a web context or any other context such as pulling state from several back-ends in parallel and blocking waiting for the results. Conversations may just become the next programming style and this should naturally allow parallel applications to be written easily/tooled and debugged. The current work on closures and conversational state need to be integrated also, lots of similarities and potentially programming model simplifications should be possible by combining both of those.

Comments

[Mircea Crisan]

At a given moment, a browser will not make more than 2 concurrent requests to the same server. I think this is what HTTP protocol mandates. So, the parallelization factor will not be that high.
Of course you can tweak the browser settings, or use multiple names for the same server IP, etc.

[Murali Kosaraju]

There are definitely ways to overcome the two connection limit, by probably having multiple CNAME entries in the DNS pointing to the same IP address, or by enabling http pipelining feature inside browsers.

As these Web2.0 technologies (AJAX, cometd, converstational flows, HTML 5.0) are still evolving, I am pretty optimistic that they would enable us to harness the power of multi-cores in a big way.

Billy's idea of parallelization of tasks, across the application stack, might find a place in future JEE specifications, but it maybe too much to ask for.