Your realtime PubSubHubbub hub in three easy steps

November 3 2011

2 comments 0
motif

The recently introduced PubSubHubbub module opened the door to server-push web-based integration with Mule. This approach, which is more resource friendly than the traditional pull integration that relies on polling resources, is currently gaining a lot of traction as is the industry is moving towards realtime and streaming web APIs.

In this blog, we’ll discover you how easy it is to roll out your own PubSubHubbub Hub in the cloud using iON, the Mule-powered integration Platform-as-a-Service, and MongoHQ, the MongoDB-powered Database-as-a-Service platform.

In short, we’ll do:

Mmmm, cloud math. Clear? Never mind, the fun part is that we’ll be up and running in less time it would take you to repeat this formula 10 times.  Three easy steps were promised, so here we go…

1. Create a database in MongoHQ

We need first to create a database in MongoHQ.

The above shows we’ve created a database named mule-push, where push stands for… server push and PuSH (the official acronym for PubSubHubbub, an acronym that is known as “push” by users of case-insensitive operating systems).

2. Create a Mule configuration

The next step consists in creating the Mule configuration. This is where XML happens.

The above is all you need. If you (visually) filter out the namespace declaration, what’s left is what really matters. This amounts to configuring:

  • The MongoDB Object Store, which is an adapter (provided by the MongoDB  connector) that allows Mule to persist internal objects in MongoDB. Notice how the username and password parameters have been externalized.
  • The PuSH hub, for which a few configuration parameters exist (cf. its user guide), but we’re only configuring its object store here to use the MongoDB-backed one and leave the other parameters to their default values.
  • A flow that binds an inbound HTTP endpoint to the PuSH hub. The hub will pick up the only configuration found in the configuration (the one just above it). Note that we’ve also externalized the port used in the HTTP endpoint. This is an iON requirement.

3. Deploy it to iON

Mule Studio is integrated with iON: so you get push-button deployment to the cloud right from your IDE. In order to deploy the above configuration, we need to package it in a Mule application, the same way we do it before deploying to a Mule standalone instance.


In Studio, we had to do the following before initiating a deploy to iON:

  • Create a properties file named mule-app.properties and add in there the MongoDB username and password. We’ve left out the HTTP port because its value will be provided by the iON runtime. Note that environment variables can also be configured through the iON console.
  • Imported the Mongo Connector and PubSubHubbub Module JARs and their dependencies. To be frank, this is the most tedious part of all, we know it and we’ll make it better (remember: MuleStudio is in beta).

With this in place, after the few seconds it takes the iON deployer to flex its muscles, the PuSH hub is up and ready!

Security – We haven’t applied any security to our hub.  A good approach would be to use one of Mule’s many security options to restrict access to the inbound HTTP endpoint to authorized users only.

Your hub in action

The iON console makes it easy to track the activity of our  hub. For example, the Dashboard view shows the requests that have been recently processed:

 

Turning back to the MongoHQ console, you’ll see that, after being used, the hub has created three (or four) collections:

These collections are:

  • FeedFetcherCache – used internally by Rome when it accesses RSS and Atom feeds,
  • TopicFeedEntryIds – used by the hub to keep track of the ID of a each topic feed entry when a publisher informs the hub that new content is available,
  • TopicSubscriptionCallbacks – used by the hub to keep track of the active subscriptions and their callback URIs,
  • SubscriberCounts – optionally used by the hub only when subscribed feeds provide a count of subscribers.

Note that the data itself is stored in an opaque format in these collections (Java serialization not JSON). This is because the object store persistence infrastructure the PuSH hub uses is generic and doesn’t try to adhere to any particular data representation. Dub it: no manual fiddling with data for you!

To realtime and beyond…

The ball is now in your court, go nuts and explore the realtime web. And please, do share your stories with us. We’d love to hear about the great stuff you’re doing with this.

Follow: @rossmason@mulejockey


We'd love to hear your opinion on this post


2 Responses to “Your realtime PubSubHubbub hub in three easy steps”

  1. Please consider porting this module to support mule 3.1x EE platform.
    Thanks

    • Grigory, Are you using PubSubHubbub on premise? I’ve been thinking about it more as a web pub sub technology, but I’d like to hear your use case.