InfoQ

News

InfoQ Article: Introduction to ActiveMessaging

Posted by Obie Fernandez on Feb 28, 2007 11:00 PM

Community
Ruby
Topics
Ruby on Rails,
Programming
Tags
Stomp,
ActiveMessaging,
JMS
Andrew Kuklewicz, the maintainer of the ActiveMessaging (also called a13g for short) project gives a comprehensive and informative introduction to his open-source framework, which enables enterprise messaging technologies to be easily integrated with Ruby on Rails applications. ActiveMessaging is getting support from noted industry leaders such as James Strachan and Jon Tirsen.

ActiveMessaging is especially interesting to Rails developers in the enterprise, because through its support for Stomp and StompConnect it allows easy interoperability with Apache's ActiveMQ messaging server and any other enterprise messaging server that supports JMS.

Our easy-to-follow introductory article assumes basic knowledge of Ruby on Rails and messaging concepts, and has code samples and all the instructions you need to get started using ActiveMessaging.

Read InfoQ's Introduction to ActiveMessaging today.

17 comments

Reply

Great article! by James Strachan Posted Mar 2, 2007 2:57 AM
Performance/Throughput? by Stefan Tilkov Posted Mar 2, 2007 1:39 PM
Re: Performance/Throughput? by Andrew Kuklewicz Posted Mar 2, 2007 4:35 PM
Now, we can only push the messages to the views by hemant kumar Posted Mar 6, 2007 2:52 PM
Re: Now, we can only push the messages to the views by Andrew Kuklewicz Posted Mar 6, 2007 11:06 PM
Re: Now, we can only push the messages to the views by hemant kumar Posted Mar 18, 2007 3:56 AM
Re: Now, we can only push the messages to the views by Alex MacCaw Posted Jul 25, 2007 4:43 AM
Re: Now, we can only push the messages to the views by Alex MacCaw Posted Sep 7, 2007 10:49 AM
Re: Now, we can only push the messages to the views by James Strachan Posted Mar 7, 2007 3:24 AM
Re: Now, we can only push the messages to the views by hemant kumar Posted Mar 18, 2007 3:56 AM
Re: Now, we can only push the messages to the views by James Cook Posted Mar 26, 2007 9:13 PM
Re: Now, we can only push the messages to the views by Francis Chong Posted Jul 10, 2007 2:37 AM
Excellent! by Zieke Lee Posted Mar 25, 2007 6:18 AM
Re: Excellent! by Andrew Kuklewicz Posted Apr 5, 2007 12:41 PM
Re: Excellent! by Zieke Lee Posted Apr 15, 2007 9:13 AM
Errors by Denis Labelle Posted Apr 26, 2007 7:36 PM
Re: Errors by Denis Labelle Posted Apr 27, 2007 5:45 PM
  1. Back to top

    Great article!

    Mar 2, 2007 2:57 AM by James Strachan

    Thanks for a great article Andrew! ActiveMessaging really rocks (as does Rails, Stomp and ActiveMQ :). Keep up the good work! James LogicBlaze Open Source SOA

  2. Back to top

    Performance/Throughput?

    Mar 2, 2007 1:39 PM by Stefan Tilkov

    Excellent article. Are there any benchmarks/performance figures yet?

  3. Back to top

    Re: Performance/Throughput?

    Mar 2, 2007 4:35 PM by Andrew Kuklewicz

    good question - the straight answer is I haven't seen or or run any such test myself. If anyone else has, I would be very curious to hear about it. So I don't know exactly what the a13g overhead is, or how it scales. I have a feeling this may depend much more on your message broker, and then what you do in the message processor. These kind of tests are a bit tricky as you are testing the network, the broker, the box, etc. That said, it would be good to design a benchmark, perhaps based off the work done at ActiveMQ. I can say that anecdotally, I find the processing of the message to take longer than the overhead in dispatch - we even do synchronous messages from our java app to our rails app and back. One other nice thing is that you can run multiple instances of the poller process, so with N number of pollers all listening to the same queue, you in theory have as much scalability as you have processing power, and depending on the efficiency of the broker dispatch. Cheers, Andrew Kuklewicz

  4. Back to top

    Now, we can only push the messages to the views

    Mar 6, 2007 2:52 PM by hemant kumar

    This work is awesome, and all we need is a way to push these messages to the browser, so that browser doesn't poll for it. any ideas on this?

  5. Back to top

    Re: Now, we can only push the messages to the views

    Mar 6, 2007 11:06 PM by Andrew Kuklewicz

    I only know one non-polling based way to push to the browser, and that is the Juggernaut project. Personally I am very tempted to mess with the juggernaut http://juggernaut.rubyforge.org/ solution, I just haven't had an excuse. From what I understand it involves a separate "push server" that sits between a rails server app, and the flash apps on the browser. I see no reason a processor in a13g couldn't send a message to the juggernaut push server that would then get pushed up to the browser - if you give it a try let me know - it looks awful cool.

  6. This work is awesome, and all we need is a way to push these messages to the browser, so that browser doesn't poll for it. any ideas on this?
    We've had that part solved for a while using a cometd style integration using ActiveMQ and Jetty... http://activemq.apache.org/ajax.html In benchmarks for customers we've had a single process handling 14,000 concurrent users James LogicBlaze Open Source SOA

  7. Well Andrew, I have checked out Juggernaut inside out and actually have implemented by own push server.But the problem is, it can't bypass firewalls and worst of it NATs. This is a big hurdle in my opinion. Without solving above issues Juggernaut won't get mass adoptation.

  8. Are we talking Java?

  9. Back to top

    Excellent!

    Mar 25, 2007 6:18 AM by Zieke Lee

    Would you please take a look at the table messages, I have got mysql> select * from messages; +----+--------------+---------------------+ | id | body | received_date | +----+--------------+---------------------+ | 1 | Hello World | 0000-00-00 00:00:00 | | 2 | testDateTime | 0000-00-00 00:00:00 | +----+--------------+---------------------+ FIELD received_date, it supposed to be DateTime at which message were generated. Please take a look at on_message

  10. James, is that "cometd style" or api/protocol compliant cometd?

  11. Back to top

    Re: Excellent!

    Apr 5, 2007 12:41 PM by Andrew Kuklewicz

    Yeah, there is a one letter typo, I sent in a fix for this before the article was published, but guess it didn't make it into the article.

    def on_message(message)
      logger.debug "PersistMessageProcessor received: " + message
      my_message = Message.create(:body=>message, :received_date=>DateTime.new)
    end 
    
    should be
    :received_date=>DateTime.now
    not
    :received_date=>DateTime.new
    Cheers, -Andrew Kuklewicz

  12. Back to top

    Re: Excellent!

    Apr 15, 2007 9:13 AM by Zieke Lee

    perfect, a toast !

  13. Back to top

    Errors

    Apr 26, 2007 7:36 PM by Denis Labelle

    Hello all, I followed along with the example, however when posting the message from the view, the server outputs the following message (infinitely, it would appear):

    transmit failed: undefined method `length' for # transmit failed: undefined method `length' for # transmit failed: undefined method `length' for # ...
    My poller runs fine:
    Loading D:/dev/ruby/Mess/app/processors/application.rb Loading D:/dev/ruby/Mess/app/processors/persist_message_processor.rb => Subscribing to /queue/PersistMessage (processed by PersistMessageProcessor)
    I don't see a message in either the poller console, or the activemq console. I changed the broker.yml configuration to look at denis:61613 instead of localhost because when activemq starts, it states:
    ... INFO TransportServerThreadSupport - Listening for connections at: tcp://denis:61616 INFO TransportConnector - Connector openwire Started INFO TransportServerThreadSupport - Listening for connections at: ssl://denis:61617 INFO TransportConnector - Connector ssl Started INFO TransportServerThreadSupport - Listening for connections at: stomp://denis:61613 INFO TransportConnector - Connector stomp Started INFO TransportServerThreadSupport - Listening for connections at: xmpp://denis:61222 INFO TransportConnector - Connector xmpp Started ...
    Any ideas? Thx, dl

  14. Back to top

    Re: Errors

    Apr 27, 2007 5:45 PM by Denis Labelle

    er, nevermind I overlooked 1 line in my controller, rather than def new @message = params[:message] ... end was def new @message = Message.new(params[:message]) ... end

  15. For pushing message in COMET style, you may use AjaxMessaging http://code.google.com/p/ajaxmessaging/

  16. Hemant: Not true, Juggernaut can use port 443 which is open on most firewall (used for https).

  17. Juggernaut can bypass firewalls in that it can use ports commonly open on a firewall, such as 443. I'm not sure how NAT poses a problem, the port just gets forwarded to a internal server.

Exclusive Content

Rationalizing the Presentation Tier

Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.

Agile Project Management: Lessons Learned at Google

In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.

AtomServer – The Power of Publishing for Data Distribution

In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.

An Introduction to Virtualization

It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.

REST Anti-Patterns

In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.

Choosing between Routing and Orchestration in an ESB

In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.

Enterprise Batch Processing with Spring

Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.

User Story Estimation Techniques

Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.