rmb-rails 0.0.7 → 0.0.8

data/README

@@ -0,0 +1,30 @@
+
+= rmb-rails: RESTful Message Beans for Ruby on Rails
+
+= Introduction
+
+During a lengthy career in software development, and later as an enterprise architect, I saw a lot of message broker deployments in many large corporations.  These systems were used primarily to knit together disparate computing 'silos' into a single fabric, as primarily an integration tool.  The implementations varied significantly,  some were well engineered and managed, others were basket cases of poor planning.  One significant problem that was common in many of these deployments was the requirement to add broker subscriber behavior inside existing applications.  Many of these applications were single threaded (often written in COBOL) and had no real ability to construct a thread to wait on some subscriber.receive method.  This issue was resolved by a variety of means, many of which involved polling the subscriber queue periodically, picking up some or all of the messages waiting, and processing them through the application.  Polling does not scale well.  If the application had many worker instances, they all tended to compete with one another and together, consumed a lot of CPU time in polling loops.  If you slowed down the polling frequency, then you got latency problems where messages sat in the queue when the readers were sleeping.  The real solution was to construct some form of subscriber adapter that could inject messages into the applications' standard incoming data stream.  The Enterprise Java Message Bean is a good example of this kind of adapter.  Message arrival on a designated queue or topic caused the activation of a Message Bean within the EJB  container, allowing full participation in transactions within the container.  
+
+There is a real parallel between a Java EJB application and a Ruby-on-Rails application, and the Rails environment needs a method to get incoming message broker subscriptions injected directly into the main Rails data stream.  So, how can we convert an MQ message into an http request? The rubygem rmb-rails addresses this issue.
+
+= Theory of Operation
+
+As stated above, experience shows that polling a queue to pick up messages waiting there does not scale well.  I decided to create an infrastructure where daemon processes, called listeners, can connect to a specified message broker, receive messages from that broker, and then forward them on to a standard Rails controller using a standard Rails protocol.  In other words, the daemon listener processes act as browsers doing a form of file upload.  The receiving rails controller is built on standard REST principles, and fits easily into any Rails app.
+
+= Component classes
+* module RMB
+* class Properties
+* class ListenerClient
+* class ListenerMain
+* class Subscriber
+* class Submitter
+* class StompSubscriber
+* class MechanizeSubmitter
+
+= Installation
+
+= Usage
+
+== Copyright
+
+Copyright (c) 2009 Ken Burgett. See LICENSE for details.

data/README.rdoc

@@ -1,6 +1,29 @@
-= rmb-rails
+
+= rmb-rails: RESTful Message Beans for Ruby on Rails
 
-Description goes here.
+= Introduction
+
+During a lengthy career in software development, and later as an enterprise architect, I saw a lot of message broker deployments in many large corporations.  These systems were used primarily to knit together disparate computing 'silos' into a single fabric, as primarily an integration tool.  The implementations varied significantly,  some were well engineered and managed, others were basket cases of poor planning.  One significant problem that was common in many of these deployments was the requirement to add broker subscriber behavior inside existing applications.  Many of these applications were single threaded (often written in COBOL) and had no real ability to construct a thread to wait on some subscriber.receive method.  This issue was resolved by a variety of means, many of which involved polling the subscriber queue periodically, picking up some or all of the messages waiting, and processing them through the application.  Polling does not scale well.  If the application had many worker instances, they all tended to compete with one another and together, consumed a lot of CPU time in polling loops.  If you slowed down the polling frequency, then you got latency problems where messages sat in the queue when the readers were sleeping.  The real solution was to construct some form of subscriber adapter that could inject messages into the applications' standard incoming data stream.  The Enterprise Java Message Bean is a good example of this kind of adapter.  Message arrival on a designated queue or topic caused the activation of a Message Bean within the EJB  container, allowing full participation in transactions within the container.  
+
+There is a real parallel between a Java EJB application and a Ruby-on-Rails application, and the Rails environment needs a method to get incoming message broker subscriptions injected directly into the main Rails data stream.  So, how can we convert an MQ message into an http request? The rubygem rmb-rails addresses this issue.
+
+= Theory of Operation
+
+As stated above, experience shows that polling a queue to pick up messages waiting there does not scale well.  I decided to create an infrastructure where daemon processes, called listeners, can connect to a specified message broker, receive messages from that broker, and then forward them on to a standard Rails controller using a standard Rails protocol.  In other words, the daemon listener processes act as browsers doing a form of file upload.  The receiving rails controller is built on standard REST principles, and fits easily into any Rails app.
+
+= Component classes
+* module RMB
+* class Properties
+* class ListenerClient
+* class ListenerMain
+* class Subscriber
+* class Submitter
+* class StompSubscriber
+* class MechanizeSubmitter
+
+= Installation
+
+= Usage
 
 == Copyright
 

data/README.rdoc.txt

@@ -0,0 +1,30 @@
+
+= rmb-rails: RESTful Message Beans for Ruby on Rails
+
+= Introduction
+
+During a lengthy career in software development, and later as an enterprise architect, I saw a lot of message broker deployments in many large corporations.  These systems were used primarily to knit together disparate computing 'silos' into a single fabric, as primarily an integration tool.  The implementations varied significantly,  some were well engineered and managed, others were basket cases of poor planning.  One significant problem that was common in many of these deployments was the requirement to add broker subscriber behavior inside existing applications.  Many of these applications were single threaded (often written in COBOL) and had no real ability to construct a thread to wait on some subscriber.receive method.  This issue was resolved by a variety of means, many of which involved polling the subscriber queue periodically, picking up some or all of the messages waiting, and processing them through the application.  Polling does not scale well.  If the application had many worker instances, they all tended to compete with one another and together, consumed a lot of CPU time in polling loops.  If you slowed down the polling frequency, then you got latency problems where messages sat in the queue when the readers were sleeping.  The real solution was to construct some form of subscriber adapter that could inject messages into the applications' standard incoming data stream.  The Enterprise Java Message Bean is a good example of this kind of adapter.  Message arrival on a designated queue or topic caused the activation of a Message Bean within the EJB  container, allowing full participation in transactions within the container.  
+
+There is a real parallel between a Java EJB application and a Ruby-on-Rails application, and the Rails environment needs a method to get incoming message broker subscriptions injected directly into the main Rails data stream.  So, how can we convert an MQ message into an http request? The rubygem rmb-rails addresses this issue.
+
+= Theory of Operation
+
+As stated above, experience shows that polling a queue to pick up messages waiting there does not scale well.  I decided to create an infrastructure where daemon processes, called listeners, can connect to a specified message broker, receive messages from that broker, and then forward them on to a standard Rails controller using a standard Rails protocol.  In other words, the daemon listener processes act as browsers doing a form of file upload.  The receiving rails controller is built on standard REST principles, and fits easily into any Rails app.
+
+= Component classes
+* module RMB
+* class Properties
+* class ListenerClient
+* class ListenerMain
+* class Subscriber
+* class Submitter
+* class StompSubscriber
+* class MechanizeSubmitter
+
+= Installation
+
+= Usage
+
+== Copyright
+
+Copyright (c) 2009 Ken Burgett. See LICENSE for details.

data/VERSION

@@ -1 +1 @@
-0.0.7
+0.0.8

data/rmb-rails.gemspec

@@ -2,20 +2,23 @@
 
 Gem::Specification.new do |s|
   s.name = %q{rmb-rails}
-  s.version = "0.0.7"
+  s.version = "0.0.8"
 
   s.required_rubygems_version = Gem::Requirement.new(">= 0") if s.respond_to? :required_rubygems_version=
   s.authors = ["Ken Burgett"]
-  s.date = %q{2009-07-22}
+  s.date = %q{2009-07-23}
   s.email = %q{keburgett@gmail.com}
   s.extra_rdoc_files = [
     "LICENSE",
-     "README.rdoc"
+     "README",
+     "README.rdoc",
+     "README.rdoc.txt"
   ]
   s.files = [
     ".document",
      ".gitignore",
      "LICENSE",
+     "README",
      "README.rdoc",
      "Rakefile",
      "VERSION",

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification 
 name: rmb-rails
 version: !ruby/object:Gem::Version 
-  version: 0.0.7
+  version: 0.0.8
 platform: ruby
 authors: 
 - Ken Burgett
@@ -9,7 +9,7 @@ autorequire:
 bindir: bin
 cert_chain: []
 
-date: 2009-07-22 00:00:00 -07:00
+date: 2009-07-23 00:00:00 -07:00
 default_executable: 
 dependencies: []
 
@@ -21,11 +21,14 @@ extensions: []
 
 extra_rdoc_files: 
 - LICENSE
+- README
 - README.rdoc
+- README.rdoc.txt
 files: 
 - .document
 - .gitignore
 - LICENSE
+- README
 - README.rdoc
 - Rakefile
 - VERSION
@@ -41,6 +44,7 @@ files:
 - rmb-rails.gemspec
 - test/rmb-rails_test.rb
 - test/test_helper.rb
+- README.rdoc.txt
 has_rdoc: true
 homepage: http://github.com/explainer/rmb-rails
 post_install_message: