Derek Wischusen on Integrating Flex, BlazeDS and Scala/Lift

Posted by Moxie Zhang on Feb 08, 2008

Sections

Development

Topics

Java ,

Rich Internet Apps

Tags

Scala ,

Flex

In December last year Adobe announced that the LiveCycle Data Services would be in open source and called BlazeDS. BlazeDS is a server side technology developed on JEE platform. It facilitates content streaming and server-side-push for Flex or AIR based RIA applications. Derek Wichusen of Flex on Rails wrote about integrating Flex, BlazeDS and Scala/Lift.

Regarding Adobe's announcement, Wischusen wrote:

While this announcement is definitely welcome news, there may be a lot of people out there who thought to themselves, “That’s great, but I don’t use Java.” Well, the good news is that just because BlazeDS uses Java the platform doesn’t mean that you necessarily need to use Java the language to take advantage of it.

In fact, Java the platform supports several different languages, including Groovy, Python, Ruby, and Scala. And, of course, ColdFusion. In theory, it should be pretty straight-forward to integrate any of these languages with BlazeDS.

Wischusen went on explaining why he used Scala:

Well, it is because recently I decided that I wanted to broaden my programming language horizons and I’ve found that Scala is both extremely interesting and very powerful. It’s both object-oriented and functional, it has mixin style composition, it has an exceptional implementation of Erlang style Actors for handling concurrency, and much more. Lastly, and perhaps most important for my purposes, there is an excellent webapp framework for Scala called Lift.

All together, Wischusen's integration project used the latest versions of JDK 1.5+, Scala , Eclipse, Scala plug-in for Eclipse, Maven, BlazeDS and Flex 3.

Wischusen started programming with creating a Lift project with step by step instruction on the post. Then He created a Eclipse project using Maven. Once the the created Life project was imported into the Eclipse project, the BlazeDS jars was added to the build path. After showing how to setup the development environment, Wischusen talked about how Lift handles HTTP request:

Lift is a view first framework. What this means is that by default lift will try to match an HTTP request against one its views. If it finds one it will do some processing on it, and then render it our as HTML. For more info on how Lift handles HTTP requests, check out this page.

For this project, the Flex was used to be the view so that Lift was not used as part of UI. The Lift was configured to only handle web services.

Wischusen posted the details steps and code examples on about Scala programming. He explained in details about Scala Actor:

When the Notifier Actor is started (you’ll see where this happens later) the act method is called. The first thing inside the act method is a call to the ActorPing.schedule helper method. This method basically says that I want to send a Notify message to this Actor in 500 milliseconds. Next comes loop which simply creates a loop and then react which has case statements that are used to handle incoming messages. So, when react receives a Notify or a “stop” message all of the code for that case is executed.

After creating the sever side application, Wischusen wrote a Flex application:

What we’ve create here is an app that has a very simple UI that consists of two buttons and a text input field. The app also has two HTTPServices and Consumer. A couple of things to take note of here. First, the Consumer subscribes to the “notifications” destination, the same destination that our Notifier Actor publishes its messages to. Second, the HTTPServices make calls to webservices/start_feed and webservices/stop_feed. If you’ll recall we set up our Lift app so that these calls would be routed to invoke the methods in our WebServices class.

When the application was developed, Wischusen wrote:

You now be able to boot up you Lift app, launch the Flex app, click the “Subscribe to ‘notifications’” to start the Notifier Actor and subscribe to the Consumer to the notifications destination. You should then see id number and the time in the text input field get automatically updated every 0.5 seconds. You can the click the “Unsubscribe from ‘notifications’” to stop the Notifier actor and the Consumer to unsubscribe from the notifications destination.

In the end, Wischusen concluded:

With these three technologies it’s really easy to automatically push data from the server to the client in real time. This is obviously a trivial example, but I think it should be relatively straight forward to scale this approach up for more sophisticated apps.

The source code of this project is provided at Life App and Flex App.

• Older >