Feb 11 2008

Server push with Ruby on Rails using Flex, JRuby, and BlazeDS

Tag: ActiveMQ, ActiveMessaging, Flex, Flex and Rails, JRuby, Messaging, Server Push, blazedsDerek Wischusen @ 5:32 am

In a previous post I discussed how you can integrate Flex and Scala/Lift using BlazeDS.  In this post I’ll show that it’s also possible to get Rails running on BlazeDS using JRuby.

Here is what I am using for this example:

You don’t really need Netbeans, but I’ve found that it makes things a bit easier.

For this example I am going to assume you have a basic understanding of Flex and Rails.  That said, if anyone has a question, not matter how basic, please feel free to ask.

Here are the source files if you want to follow along:

—– 

Ok, first lets get the Rails app set up.

1. Create a new Rails app called RoRBlaze.

2. Generate a controller called Greeting with an index view.  i.e.,

> ruby script/generate controller Greeting index

3.  Open up your newly generated greeting.rb file and add the following code:

class GreetingController < ApplicationController
  include Java
  import "flex.messaging.MessageBroker"
  import "flex.messaging.messages.AsyncMessage"
  import "flex.messaging.util.UUIDUtils"

  @@msgBroker = MessageBroker.getMessageBroker(nil)
  @@clientID = UUIDUtils.createUUID()

  def hello
    @msg = AsyncMessage.new()
    @msg.setDestination("notifications")
    @msg.setClientId(@@clientID)
    @msg.setMessageId(UUIDUtils.createUUID())
    @msg.setTimestamp(Time.new.to_f)
    @msg.setBody("Hello from Rails")
    @@msgBroker.routeMessageToService(@msg, nil)
    render :text => "Greeting Sent"
  end
end

4. Open view/greeting/index.rhtml and add a button to it like so,

<%=button_to "Send Greeting to Flex", :action=>"hello" %>

5. Go to the BlazeDS folder and  locate the following two .jar files in tomcat\webapps\blazeds\WEB-INF\lib:

  • flex-messaging-common.jar
  • flex-messaging-core.jar

6. Copy these .jar files into the lib folder in your Rails app (keep this folder open, you’ll need the more of the .jars in a moment).

7. In your Rails app open up config/environment.rb and add the following to the bottom of the file:

Dir["#{RAILS_ROOT}/lib/**/*.jar"].each do |jar|
  require jar
end

Alright, thats pretty much all of the Ruby code for this simple example.  Now we need to use the Goldspike Rails plugin to modify our Rails app so that it can run in a Java server (like Tomcat or Jetty or Glassfish, etc)

8.  From a command line, go to the root of your Rails app and install the Goldspike plugin:

> ruby script/plugin install http://jruby-extras.rubyforge.org/svn/trunk/rails-integration/plugins/goldspike

9. WARify you Rails app using the following rake command:

> rake war:standalone:create

Assuming that Goldspike did its job, you should now have a folder called WEB-INF in the root of you Rails app.  We need to add a few file to this folder to get BlazeDS working.

10. Copy the .jars from BlazeDS\tomcat\webapps\blazeds\WEB-INF\lib into RoRBlaze\WEB-INF\lib

11. Copy the folder BlazeDS\tomcat\webapps\blazeds\WEB-INF\flex into RoRBlaze\WEB-INF

12. Open up the web.xml file in blazeds\WEB-INF and merges its contents into the web.xml file in RoRBlaze\WEB-INF.  Click here to see what the final file should look like.

13. Open up RoRBlaze\WEB-INF\flex\messaging-config.xml and modify it so that it looks like this (click to view the file).  The key thing to note here is that we added a messaging destination called “notifications”.  This is the destination that the Greeting controller publishes to and it is the destination that our Flex app will subscribe to.

14. Open up RoRBlaze\WEB-INF\flex\services-config.xml and modify it so that it looks like this (click to view the file).  The key thing to notice in this file is that we defined a streaming channel called my-streaming-amf that BlazeDS will use to push messages over a persistent, streaming HTTP channel.

That’s it for the Rails app.  Now let’s create the Flex app.

—–

1. Create a new Flex Project (File -> New -> Flex Project)

2. Fill in the rest as follows:

  • Project name: RoRBlaze
  • Application type: Web Application
  • Application server type: J2EE
  • Use remote object access service: check this
  • Root folder: RoRBlaze  (the root folder of your Rails app)
  • Root URL: http://localhost:8080/RoRBlaze/
  • Context root: /RoRBlaze
  • Output folder: RoRBlaze\public
  • Output folder URL: http://localhost:8080/RoRBlaze

3. Open up RoRBlaze.mxml and edit it like so:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application
	xmlns:mx="http://www.adobe.com/2006/mxml"
	layout="vertical"
	creationComplete="consumer.subscribe()">

    <mx:Script>
        <![CDATA[
          	import mx.messaging.events.MessageEvent;

            private function messageHandler(message: MessageEvent): void
            {
                pushedMessage.text = message.message.body as String;
            }
        ]]>
    </mx:Script>

    <mx:Consumer
    	id="consumer"
    	destination="notifications"
    	message="messageHandler(event)"
    	channelConnect="trace(event)"
        channelFault="trace(event)"
        fault="trace(event)" />

    <mx:TextInput id="pushedMessage" width="300"/>
</mx:Application>

That’s it for the Flex app.  Let’s test everything out.

—–

1. Open a terminal and go to the root of your Rails app.  Then use Goldspike to boot up your Rails app in a Jetty server:

> rake war:standalone:run

In a few short seconds your Rails app should  be up and running.

2. Launch the Flex app.

3.  Open a browser and enter the following URL: http://localhost:8080/RoRBlaze/greeting

You should see a single button that says “Send Greeting to Flex”

4. Click the button.

Upon clicking the button you should see the browser display “Greeting Sent” and you should see “Hello from Rails” appear in the text input in your Flex app.

That’s it.  Assuming that everything worked properly, the Rails app should have pushed an AMF encoded message to Flex using a persistent streaming HTTP channel created by BlazeDS.

One importatant thing to take note off is that this technique could be useful to you even if you aren’t planning on using Flex/Flash as your presentation layer.  You could use a Juggernaut style approach and push messages from Rails to an embedded Flash player whose only job is to pass those messages along to the browser.

This example demonstrates a very simple way to integrate Flex, Rails, and BlazeDS.  I think the ideal way to integrate these technologies would be to use the ActiveMessaging plugin for Rails, since both ActiveMessaging and BlazeDS have JMS adapters which they could use to integrate with a more robust messaging system like ActiveMQ.  If I can find some time in the near future, and if there is any interest, I’ll do a follow up post on this.


Nov 23 2007

as3Stomp – Project site and source code

Tag: AS3, ActionScript, ActiveMQ, ActiveMessaging, STOMP, Server PushDerek Wischusen @ 7:48 pm

A little while ago I posted about my ActionScript 3 implementation of the STOMP protocol.  Well, I am just now getting around to posting that I created a google project site and released the source.   This version is slightly updated from the one that was included in my example code in the previous post.

 If you have any questions about this project, or if you would like to contribute, please let me know.  Please post any bugs to this issue list.


Jul 28 2007

Publish\Subscribe Messaging with Flex and Rails using Apache ActiveMQ, ActiveMessaging, and STOMP

Tag: AS3, ActiveMQ, ActiveMessaging, Flex and Rails, Messaging, STOMP, Server PushDerek Wischusen @ 6:09 pm

This will be the first in a series of posts where I’ll cover how you can do publish\subscribe and other messaging methods with Flex and Rails using ActiveMQ, the Rails ActiveMessaging plugin, and the STOMP protocol to get them all communicating. In this post I will describe how to create a simple Flex consumer that receives messages from a Rails app that serves as the producer.

Before we get to that, let’s start with a brief description of the technologies involved. The following descriptions are from the technologies’ respective websites:

Apache ActiveMQ

Apache ActiveMQ is the most popular and powerful open source Message Broker.

Apache ActiveMQ is fast, supports many Cross Language Clients and Protocols and many advanced features while fully supporting JMS 1.1 and J2EE 1.4. Apache ActiveMQ is released under the Apache 2.0 License.

ActiveMessaging

ActiveMessaging is an attempt to bring the simplicity and elegance of rails development to the world of messaging. Messaging, (or event-driven architecture) is widely used for enterprise integration, with frameworks such as Java’s JMS, and products such as ActiveMQ, Tibco, IBM MQSeries, etc.

And, lastly the protocol that we’re going to use to tie everything together:

STOMP

The Stomp project is the Streaming Text Orientated Messaging Protocol site (or the Protocol Briefly Known as TTMP and Represented by the symbol :ttmp).

Stomp provides an interoperable wire format so that any of the available Stomp Clients can communicate with any Stomp Message Broker to provide easy and widespread messaging interop among languages, platforms and brokers.

Now that you know a little something about technologies that we will be using (I am assuming that you probably already know about Flex and Rails), let’s build something.

Prerequisites:

  • Ruby 1.8.6
  • Rails 1.2.3
  • Java 1.5.0_07+
  • MySQL (or any other database that works with Rails migrations)

Here are the source files if you would like to follow along.

Source Files:

Creating the Rails App

Let’s kick things off by creating the Rails producer app. It’s going to be a really small app called sales_report that is used to capture and distribute simple sales data.

1. Crack open the database of your choice and create a database called sales_report. For example,

$ CREATE DATABASE sales_report

2. Create the app

$ rails sales_report
$ cd sales_report

3. Generate your sale model

$ script/generate model sale

4. Open up the 001_create_sales.rb migration that you just created in db/migrate and add the following

  def self.up
    create_table :sales do |t|
      t.column :customer, :string
      t.column :product, :string
      t.column :quantity, :integer
    end
  end

5. Open up config/database.yml and configure it for your database. For example,

development:
    adapter: mysql
    database: sales_report
    username: root
    password: your_password_here
    socket: /tmp/mysql.sock

6. Run the migration rake task to create the sale table that you defined in migration file above.

$ rake db:migrate

7. Generate the sales controller.

$ script/generate controller sales index

8. For this application,we really just need to be able to produce new sales records, so Rails scaffolding will work just fine. Open up sales_controller.rb and make it look like this:

class SalesController &lt; ApplicationController
  scaffold :sale
end

9. That’s all for the basic Rails app. Now it’s time to start working with ActiveMessaging. So, let’s install the plugin and a couple of gems that it uses.

$ gem install daemons
$ gem install stomp
$ script/plugin install http://activemessaging.googlecode.com/svn/trunk/plugins/activemessaging

10. Now that we have everything installed, let’s create an ActiveMessaging processor. We don’t actually need the processor for this tutorial, but it generates some other files that we do need.

$ script/generate processor sale
create  app/processors
create  app/processors/sale_processor.rb
create  test/functional/sale_processor_test.rb
create  config/messaging.rb
create  config/broker.yml
create  app/processors/application.rb
create  script/poller

11. Open up config/broker.yml and configure the stomp adapter as follows:

development:
   adapter:
   stomplogin: ""
   passcode: ""
   host: localhost
   port: 61613
   reliable: false

12. Now open up config/messaging.rb and specify the destination for the queue, like so

ActiveMessaging::Gateway.define do |s|
  s.destination :sale_queue, '/queue/Sale'
end

13. Almost done. The last step for the Rails app is to create an Observer that watches the Sale model to see when a new sale is saved to the database and then publishes it to the queue that you just set up.

$ script/generate observer sale

14. Now edit app/model/sale_observer.rb as follows.

require 'activemessaging/processor'
class SaleObserver &lt; ActiveRecord::Observer
  include ActiveMessaging::MessageSender
  publishes_to :sale_queue
 
  def after_save(sale)
    record = sale.to_xml
    publish :sale_queue, record
  end
end

This class watches the Sale model. When a new sale record is saved to the database the after_save method is called. This method takes the new sale ActiveRecord instance converts it to XML and publishes it to the sale_queue.

15. Finally, boot up the server.

$ script/server

Installing ActiveMQ
Installing and running ActiveMQ is dead simple.

1. Just go and grab one of the latest snapshots from here.

2. Download it and unzip it.

3. Navigate to activemq/bin and run activemq.

4. If you need additional instruction, check out this page.

5. Once you have ActiveMQ up and running, proceed to the next section on building the Flex app.

The Flex App and the STOMP AS3 Client
To get Flex talking with ActiveMQ we are going to be using the STOMP protocol. When I first started looking into ActiveMQ I came across this ActionScript 3 STOMP client developed by Richard Jewson. I’ve since update the library substantially so that it implements the majority of the STOMP protocol. For now, you can get the source for the STOMP library by downloading the source for the Flex app. I am going to submitting this code to the STOMP project on codehaus.org, so in the future you will be able to grab updates from there.

For the Flex app we’ll just focus on the code that is needed to connect to ActiveMQ via STOMP and consume the xml that Rails is publishing. To makes things a bit easier, we’ll start with the completed Flex and just walkthrough the code. If you haven’t already download the source for the Flex app. To see what the Flex app looks like click here. As you can see it’s pretty much just a data grid that is used for displaying the sale info.

So, here is the important code, which is all inside the script tags in the Flex app:

[Bindable]
private var sales : ArrayCollection = new ArrayCollection();
 
private var stomp : STOMPClient = new STOMPClient();
private var queue : String = "/queue/Sale";
 
private function init () : void
{
	stomp.connect("localhost", 61613);
	stomp.subscribe( queue );
 
	stomp.addEventListener(MessageEvent.MESSAGE, handleMessages);
	stomp.addEventListener(ReceiptEvent.RECIEPT, handleReceipts);
	stomp.addEventListener(STOMPErrorEvent.ERROR, handleErrors);
 
}
 
private function handleMessages(event : MessageEvent) : void
{
	var incomingMsg : XML = XML(event.message.body);
	var processedSale : ObjectProxy = simplerXMLDecoder(incomingMsg);
	orders.addItem(processedSale);
}
 
private function handleReceipts (event : ReceiptEvent) : void
{
	trace ("Got receipt: " + event.receiptID)
}
private function handleErrors (event : STOMPErrorEvent) : void
{
	trace ("Error: " + event.error.body)
}
 
private function simplerXMLDecoder (x : XML) : ObjectProxy
{
	var xdoc : XMLDocument =  new XMLDocument();
	xdoc.ignoreWhite = true;
	xdoc.parseXML(x.toXMLString());
	var decoder : SimpleXMLDecoder =  new SimpleXMLDecoder(true);
	return decoder.decodeXML(XMLNode(xdoc.firstChild)) as ObjectProxy;
}

Here’s what’s going on in this code.

  • Up near the top we create a new STOMPClient
  • Directly below we specify the destination for the queue that we will be subscribing to, which is the same destination that we specified in messaging.rb above.
  • In the init() method, which is called when the application loads, we connect to the STOMP broker (ActiveMQ) and then subscribe to the queue.
  • We then set up listeners to listen for messages from ActiveMQ.

All of the real action is happening in the handleMessages method.

  • The handleMessages method gets called when the Rails app sends out the xml for a new sale.
  • When a new message is received we take the body of the message (which is the xml from Rails) and use the XMLDecoder class to turn it into a bindable ObjectProxy.
  • Finally, the new sale is added to the sales ArrayCollection, which is the data provider for the data grid in the Flex app.

Getting Everything Up and Running

Alright, now we are actually ready to run something. Assuming that the Rails app and ActiveMQ are still running, all that we need to do is launch the Flex app. You can either build the app yourself from the source files, or you can go in to the source files, open the bin folder and launch StompSalesReport.html.

Now, open a browser and navigate to http://localhost:3000/sales/new

You should see our spartan, but functional, scaffolded interface. Enter some product info and click Create.
Rails Sales Report

Now if you switch back to Flex app, you should see the following:

Flex Sales Report

Pretty exciting stuff. Immediately after the sale was saved to the database, the SaleObserver published it to the queue, where ActiveMQ pushed it out to the Flex app.

One last little tidbit. If you change the code in init() method in the Flex app so that it looks like this:

private function init () : void
{
        var ch : ConnectHeaders =  new ConnectHeaders();
	ch.clientID = "MYTOTALLYUNIQUECLIENTID";
	stomp.connect("localhost", 61613, ch);
 
	var sh : SubscribeHeaders = new SubscribeHeaders();
	sh.amqSubscriptionName = "MYSUBSCRIPTION";
	stomp.subscribe( queue, sh );
 
	stomp.addEventListener(MessageEvent.MESSAGE, handleMessages);
	stomp.addEventListener(ReceiptEvent.RECIEPT, handleReceipts);
	stomp.addEventListener(STOMPErrorEvent.ERROR, handleErrors);
}

By passing a client-id header on connect and a subscriptionName header on subscribe we create what is known as a durable subscriber.

If you compile the Flex app, launch it and then close it. Then go in back to the Rails app and create a new sale, relaunch the Flex app and you should immediately see the sale show up.


Whew! That’s it. This post was way too long. I am thinking that it may be easier to cover this stuff in a screencast. Let me know in the comments if you think a screencast would be a good idea.

As always, let me know if you have any questions.