AJAX

July 09, 2008

Read Java System Properties from Flex

Since the advent of BlazeDS we can deploy a Flex application on any JEE Application Server. I personally like to place all the resources like web services endpoints, usernames, etc in Java system properties. Then I can simply get them back by doing a System.getProperty('propertyName"). If you want to know how to set and use Java system properties in JBoss, read one my previous blog entries: Setting Java System Properties in JBoss .

If your Flex application is being served from a JEE application server, it would be nice to be able to read the Java system properties of that server. On alternative is to have a POJO in the back end that reads the Java system properties in the back end, then the Flex client queries that information from the POJO using remoting. This is the option to use if you also need modify Java system properties from the Flex application. If you don't need to modify the Java system properties, there is an easier alternative.

With Flex you have the ability to pass variables to the application at startup via flashVars. A Flex application gets compiled to a Flash (SWF) file. That file usually is served embedded in an HTML page. So, if you want to pass variables to the application you create an index.html page to serve the application that looks like this:

<html>
<body>

    <object id='flexApp' height='100%' width='100%'>
        <param name='stockCheckEndPoint' value='http://foo/stockEndPoint/>
        <param name='ldapServer' value='ldapServerName>'/>
        <embed name='flexApp' src='flexApp.swf' pluginspage='http://www.adobe.com/go/getflashplayer'
	 height='100%' width='100%'/>
    </object>

</body>
</html>

This page passed the values of stockServiceEndpoint and ldapServer to the Flex application. To read those values in Action Script Flex provides the following instructions:

stockWebServiceEndpoint = Application.application.parameters.stockCheckEndPoint;
ldapServerName = Application.application.parameters.ldapServer;

Now the values of the flashVars are in couple ActionScript variables ready to be used. This still does not solve the problem of reading Java system properties in a Flex application. The solution involves using the flashVars as described above, but instead of serving the Flex application from a static html page, to serve it from a JSP page that reads the Java system properties.

<html>
<body>

<%
    String stockCheckEndPoint = System.getProperty("stockCheckEndPoint");
    String ldapServer = System.getProperty("ldapServer");
%>

    <object id='flexApp' height='100%' width='100%'>
        <param name='stockCheckEndPoint' value='<%= stockCheckEndPoint %>'/>
        <param name='ldapServer' value='<%= ldapServer %>'/>
        <embed name='flexApp' src='flexApp.swf' pluginspage='http://www.adobe.com/go/getflashplayer'
	 height='100%' width='100%'/>
    </object>

</body>
</html>

As you can see, instead of creating an index.html file to serve the Flex application, I created a JSP file (index.jsp) to server the Flex application. I read the Java system properties and placed it in the variables stockCheckEndPoint and ldapServer. Then I passed the value of these variables as flashVars. Now I can access the values of those variables with ActionScript as mentioned before. Use this formula, so you never have to hard code variables in Flex again.

Posted at 10:50 AM in AJAX, Flex, JBoss | | Comments (1) | TrackBack (0)

June 12, 2008

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.

Posted at 02:12 PM in AJAX, Messaging, Software Architecture | | Comments (0) | TrackBack (0)

May 15, 2007

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.

Posted at 07:04 AM in AJAX, Messaging, Software Architecture | | Comments (0) | TrackBack (0)