August 6, 2004
@ 02:40 PM
Comments [9]
The silence of summer

I don't blog much in summer. That's mostly because I am either enjoying some time off or I am busy figuring out "new stuff".

So here's a bit of a hint what currently keeps me busy. If you read this in an RSS aggregator, you better come to the website for this explanation to make sense.

This page here is composed from several elements. There are navigation elements on the left, including a calendar, a categories tree and an archive link list that are built based on index information of the content store. The rest of the page, header and footer elements aside, contains the articles, which are composed onto the page based on a set of rules and there's some content aggregation going on to produce, for instance, the comment counter. Each of these jobs takes a little time and they are worked on sequentially, while the data is acquired from the backend, the web-site (rendering) thread sits idle.

Likewise, imagine you have an intranet web portal that's customizable and gives the user all sorts of individual information like the items on his/her task list, the unread mails, today's weather at his/her location, a list of current projects and their status, etc.  All of these are little visual components on the page that are individually requested and each data item takes some time (even if not much) to acquire. Likely more than here on this dasBlog site. And all the information comes from several, distributed services with the portal page providing the visual aggregation. Again, usually all these things are worked on sequentially. If you have a dozen of those elements on a page and it takes unusually long to get one of them, you'll still sit there and wait for the whole dozen. If the browser times out on you during the wait, you won't get anything, even if 11 out of 12 information items could be acquired.

One aspect of what I am working having all those 12 things done at the same time and allow the rendering thread to do a little bit of work whenever one of the items is ready and to allow the page to proceed whenever it loses its patience with one or more of those jobs. So all of the data acquisition work happens in parallel rather than in sequence and the results can be collected and processed in random order and as they are ready. What's really exciting about this from an SOA perspective is that I am killing request/response in the process. The model sits entirely on one-way messaging. No return values, not output parameters anywhere in sight.

In case you wondered why it is so silent around here ... that's why.

Categories: SOA
Tracked by:
"http://umuqjqf.com/granny-pee.html" (http://umuqjqf.com/granny-pee.html) [Pingback]
"http://vmco6a9.com/rikku-topless.html" (http://vmco6a9.com/rikku-topless.html) [Pingback]
« The Nerd, The Suit, and The Fortune Tell... | Home | Why I hate NBC Sports »
Friday, August 06, 2004 10:54:34 PM UTC
Is this similiar to the Asynchronous Invocation Application Block?
David
Saturday, August 07, 2004 1:10:25 AM UTC
No ;)
Clemens Vasters
Saturday, August 07, 2004 2:03:07 AM UTC
Take a look at the Java Portlet Specification (JSR-168):

http://www.jcp.org/en/jsr/detail?id=168

Item 20 under PLT.5.2.4 Request Handling states, "The render requests may be executed sequentially or in parallel without any guaranteed order."

Basically all the components in your web page would be implemented as portlets. From the client's perspective, it's still a request/response model because the portal has to aggregate the rendered markup fragments from all the portlets in a single page before sending it as a response. But from the portal's/portlet container's perspectives, the Render requests can be spawned asynchronously in multiple threads, and each portlet can use a remote service in an SOA. So you don't have to assemble your page synchronously.
Homam Alsayed
Saturday, August 07, 2004 3:10:18 AM UTC
Yes. And that's still not it.
Clemens Vasters
Monday, August 09, 2004 1:32:54 PM UTC
This sounds like the aggregation application block.
Dennis Mulder
Monday, August 09, 2004 6:10:18 PM UTC
I think using SharePoint could be an option. Each section on the page is a web part, which can connect to a back-end system, and management side of the portal comes out of the box. New web parts can also be developed if needed. Web parts can be designed for async operation as well.

however the downside (of using SharePoint) will be deployment process for the web parts (which needs a couple of configuration modifications).
Mehran Nikoo
Wednesday, August 11, 2004 8:25:16 AM UTC
Sounds like having fun with FABRIQ and an exploration of what kind of plumbing is needed in an async messaging (aka service-oriented) environment. My guess is that formatting is done by web server thread that handles the client-request and all backend work is farmed out to FABRIQ nodes (which manage their own threads).
Gerke Geurts
Tuesday, August 17, 2004 2:13:23 PM UTC
Well *I* think it sounds like the User Interface Process Application Block! And why don't you just use Content Management Server?? (just joking to the above two items)

To be honest, there's nothing I'd love better than for you to convincingly demonstrate the inappropriateness of the request-response model for many scenarios. I've seen it cripple the thinking (and therefore design) of developers too many times.

One thing we've done with our messaging system is turn HTTP into a full-duplex protocol by balancing the number of outstanding requests with the number of outstanding responses across a connection pool. There's also a timeout involved that bounces a connection back to the other side if it wasn't used recently. This allows us to layer request-response, one-way messages, and conversations in either direction on top of what looks like "one-way client-initiated" HTTP request-response. It feels like an ugly hack to build a full-duplex protocol on top of a half-duplex protocol (HTTP) which is actually sitting on top of a full-duplex protocol (TCP), but that's the logical response to all the stateful firewalls and HTTP proxies that fool people into thinking in terms of request-response.

My guess is something like I described above, with the HTTP client being the browser. If you could pull that off, it would seriously blow people's minds about web app design as well as freak out network administrators, since such a solution can be used to "tunnel" requests through firewalls and proxies.
Oran
Thursday, August 19, 2004 10:59:22 PM UTC

Oran - I agree with you in terms of benefits of one way messaging system over a request-response model. But you cannot change the nature of existing protocols. HTTP was designed to be a request-response protocol. (refer to RFC 2616 - HTTP 1.1) Although you could hack it to look like something else, this is not always the best and easiest option.

The best thing you can do with async messaging in a web-based application is to start rendering the HTTP response as soon as one of the page sections is rendered. But you cannot start streaming back the response unless the whole page is rendered completely. (you don't know which part is rendered first, so in an infortunate situation you are just waiting for the top-left element of the page to render)

The only solution to this would be to use different HTTP streams (e.g. using multiple frames/iframes), and this is what you can do with CMS and/or SharePoint, or you could design your own page.
Mehran Nikoo
Comments are closed.