Hugo Troche's blog

Push Architectures with Flex

One of my favorite subjects to preach about is the importance of designing push architectures in enterprise systems. The classic example of when a push architecture is needed is the dashboard. In order to keep a dashboard up to date the options are to have the client program regularly poll the server for changes or to have the server push updated information to the dashboard when necessary. The later alternative performs and scales better.

The problem is how to implement such architecture with web clients. A server can’t push data to web clients due to the stateless nature of http. The market has come up with a number of solutions to this problem. I talked about such solutions in an earlier post. The reason I am going back to this subject is due to new developments in Flex.

Flex is the form based cousin of Flash. It is arguably the most complete RIA framework in the market. Quick disclosure, I started working for Adobe a few days ago. Yet, I used Flex extensively in other projects before. There are two developments that made in my opinion Flex an attractive option for push architectures. First, last year Flex itself became Open Source. That means the Flex SDK is available for anybody to use at no cost. Second, in February this year, the Flex server product became Open Source in the form of BlazeDS. With BlazeDS you have access to powerful remoting capabilities. With BlazeDS a Flex application can access POJOs directly and most importantly it can subscribe to topics on the server.

BlazeDS is deployed as a simple war file in any JEE compliant server. The topics are defined in an XML configuration file. Then the Flex client simply subscribes to the topic by becoming a consumer with two lines of code, then every time that that the topic has a new message, it gets “pushed” to the Flex clients. In reality no message gets truly pushed to a client due to the nature of http. Flex just implement a very clever polling mechanism. You can see how to do all this in many tutorials online.

The flex topics can also be configured to listen to JMS topics/queues. This means that you can actually easily access and manipulate backend integration infrastructure like Tibco. I think that now Flex has become a must tool for any web developer.

AJAX and Messaging. The AJAX Pull Architecture Dilemma

With more and more AJAX applications popping up, I am seeing this and solving this problem often. It is well known in the thick client world that to keep thick clients over the network in the same state you have to use a Push Architecture with a messaging architecture in the back end. Let's take a look at the most common example on an application that needs to keep state synchronized across all clients, the Dashboard.

The Dashboard is usually a table (sometime something much more complicated) that contains information that is updated in real time by other clients and other services. For example, imagine a trucking company that has a table that contains all their trucks, who is driving their truck, what the truck is carrying, where the truck is going is going and the truck estimated time of arrival to its destination. This information is vital to the dispatchers to allow them to know what truck will be available when and where. Then they can make the most efficient use of the trucks on the road.

The trick is to keep this tables synchronized across all the clients without having the clients poll the database every x seconds to see if there are any changes. Such strategy simple does not scale. What you do in this case is you set up a messaging server in the back end like JBoss Messaging or TIBCO, create a topic in the Messaging server that all the clients subscribe to and then every change made to the table by clients, or maybe a GPS service, is published to the topic and all clients get a new message and update their table. This is a more efficient model.

How do you achieve a similar push architecture with AJAX? It is easy to create a dynamic AJAX table that updates itself asynchronously without ever resubmitting the page. You can do it with straight Javascript and HTML, or you can use a library like Google's GWT or DWR. The problem is that the AJAX page will eat up your server resources. By constantly polling for changes, you will have constant queries on your database when they are not necessary. But, how do you implement messaging with AJAX?

If you want to make your life easier, use Apache ActiveMQ as the JMS provider.
ActiveMQ provides Javascript remoting objects for the AJAX pages to listen for messages asynchronously. If you want to use another framework or JMS provider, you will need to create a POJO or servlet on the server side that writes and listens to the JMS topic, and the remoting Javascript objects need to listen to events from that POJO or servlet. JBoss is working on a similar feature for their JMS product. TIBCO also has AJAX libraries and support.

With all the messaging support for messaging and AJAX in the market, there is no excuse to use Pull Architectures in AJAX clients anymore.

Email me if you need more details.