Hint: Data paging in Flex with Message Queue services

There are few ways of how you can handle data paging and/or lazy loading in webware applications, today i want to bring some light on how you can do it in Flex, technically idea valid for any other kind of webware, so you are welcome to reproduce it under anything you like.

For this particular test run you need to make sure you have following on board:

• Message Queue (MQ) services on server side (in my case i use MSMQ on Windows Server 2008 Web edition);
• Adobe Flex, v.2x and never
• Web service framework or any Remoting engine like WebORB, you can use for data transport simple XML over HTTP or sockets (as we use it for Linux and Apple environment where server side engine made with RealBasic), or if you are familiar with things like RemoteObject, you can go for WebORB.

Idea is quite simple, instead of struggling with implementing paged data loading with Yahoo and Hotmail style via preloading data on grid/list scrolling event (that is not so bad actually) we will use server side Message Queues instead. Whole server side infrastructure would remain as you had it done before with only difference, when client side send's request to server, server side collects data and pushes each result-row into Message Queue then server side pulls first returns first page of data to client side, so once client side is ready with loading it it will call again for the next page.

Practically it works the same way as you would implement paging normally, with only difference MQ here becomes as some sort of cache engine, where you can store common data or data with specific frequently used query filter.

Another thing, you have to keep in mind few things. You might need some data to be available for more than one session, so when you implementing your queue management think that you will have:

• Static queue – where data available as long as application lives (in MSMQ u collect this kind of data with peek method, this method reads message from MQ without removing it, so you can access it again any time),
• and Temporary queue – where data valid only for particular request.

Static queue is pretty simple to maintain, you just throw data when you need it, or you if you need to renew data, just clear the queue and throw data again into it.

Temporary queue is more tricky, when you initiate your primary request to server server side you need to implement some session ID for this request, so your queue manager will know how to serve you. So you create a queue on server and name it with session Id unique for the connected client side request, perform data collection and fill the queue with messages where each message holds your data row, then return back to client side a “package” that contains session id and first results of given page size, so when client side receives it, it will call server side again, but this time with passing session ID issued by server earlier. In case if you want to cancel data fetching, just send back request to server with given session ID, so your queue manager will know what queue to delete. Don’t keep “dead queues” because it will kill your server side performance. And I really recommend you to look into your particular MQ engine specifications to know limitations on memory and number of messages or queues you might have.