+
+
+
+
+
+
+ 
+
+ Certiorem is a PubSubHubub (PSH) implementation for ROME. It isn't an application, but an API for building each of the three components (Publisher, Subscriber and Hub) into your web apps.
+You can see an example webapp here.
Hubs take notifications, or "Pings" that tell it the content of a feed has been updated, fetch the feed, then notify each of the subscribers of the change. As you will begin to see, Certiorem is very much about "Composition" of classes. The Hub class is a prime example of this.
+Looking at the example webapp we see:
+
+ @Provides
+@Singleton
+public Hub buildHub() {
+ FeedFetcher fetcher = new HttpURLFeedFetcher(new DeltaFeedInfoCache());
+ Hub hub = new Hub(new InMemoryHubDAO(), new UnthreadedVerifier(), new UnthreadedNotifier(), fetcher);
+
+ return hub;
+}First we construct an instance of FeedFetcher, from the Fetcher subproject. This will be used to fetch feeds from remote hosts. There are a number of implementations for FeedFetcher and FeedInfoCache in the Fetcher project. Please look there for info on what is what.
+Next we need a HubDAO implementation. This is a DAO for managing Subscriber and SubscriptionSummary classes. Here we are using an in-memory DAO, which like the HashMapFeedInfoCache will evaporate if we restart our web application. A JPA implementation for persistence is also available, but incomplete at time of writing.
+Next we need two implementations of network client interfaces: a Verifier, and a Notifier. The Verifier calls back to the Subscribers and verifies their subscribe/unsubscribe operations. A Notifier is used to send updates to to the clients. There are two basic implementations of these provided: A ThreadPool* and Unthreaded* version of each. The thread pool version uses a ThreadPoolExecutor to run queues of outbound calls. The Unthreaded version of each, makes the network calls in-line with the request to the hub. These are suitable for environments like Google App Engine where spawning threads from servlets is absolutely verboten.
+There are other constructors that contain lists of restrictions for what the hub will support: acceptable topic feeds, ports, protocols, etc.
+The hub here is just a business logic class. In order to have a functioning hub, we need a servlet exposing the Hub. In the "web" package, there is an abstract servlet you can use to do just this. In the Guice wired example, we simply create a servlet with an injected Hub implementation.
+@Singleton
+public class HubServlet extends AbstractHubServlet {
+
+ @Inject
+ public HubServlet(final Hub hub){
+ super(hub);
+ }
+}
+//... in the ServerModule...
+
+serve("/hub*").with(HubServlet.class);We can now include a <link rel="hub"> value in our feeds and publish notifications of changes.
This is perhaps the easiest thing to do. The Publisher class will take various combinations of URLs and SyndFeeds and send the appropriate notification. If your SyndFeed contains a <link rel='sel' /> and <link rel='hub' /> you can just pass the SyndFeed object. Otherwise, you can use the URL strings where appropriate.
+The example couldn't be simpler:
+Publisher pub = new Publisher();
+try {
+ pub.sendUpdateNotification("http://localhost/webapp/hub", "http://localhost/webapp/research-atom.xml");
+} catch (NotificationException ex) {
+ Logger.getLogger(NotifyTest.class.getName()).log(Level.SEVERE, null, ex);
+ throw new ServletException(ex);
+}Once this notification is sent, the hub will make a request to the feed and notify the clients of new entries.
To set up a feed subscriber, you need to go through a process very much like setting up a Hub. First, create the Subscriptions class by composition:
+@Provides
+@Singleton
+public Subscriptions buildSubs(){
+ Subscriptions subs = new Subscriptions(new HashMapFeedInfoCache(), new AsyncRequester(),
+ "http://localhost/webapp/subscriptions/", new InMemorySubDAO());
+ return subs;
+}First we need a FeedInfoCache implementation. This will be updated as notifications come in, so in your web app, you want to make sure this is shared with the FeedFetcher implementation you are using to read feeds. Next you need a Requester, this is a network class that makes subscription requests to remote hubs. Next, a URL prefix for where the callbacks will live. This really means the URL to the SubServlet that is resolvable externally. Finally, a DAO for storing and retrieving Subscription objects.
+As in the Hub, we need a wrapper servlet to call into the Subscriptions class
+@Singleton
+public class SubServlet extends AbstractSubServlet {
+
+ @Inject
+ public SubServlet(final Subscriptions subscriptions){
+ super(subscriptions);
+ }
+}
+
+// In the ServerModule...
+serve("/subscriptions/*").with(SubServlet.class)Now if we want to subscribe to a feed, we get a reference to the Subscriptions object, and pass in either the SyndFeed (with appropriate rel="hub" and rel="self" links) or simply a couple of URLs:
+ subs.subscribe("http://localhost/webapp/hub", "http://localhost/webapp/research-atom.xml", true, -1, null, new SubscriptionCallback(){
+
+ public void onFailure(Exception e) {
+ e.printStackTrace();
+ }
+
+ public void onSubscribe(Subscription subscribed) {
+ System.out.println("Subscribed "+subscribed.getId() +" "+subscribed.getSourceUrl());
+ }
+
+ });Here we pass in the URL of the Hub, the URL of the feed, a boolean indicating we want to make the subscription request synchronously, the lease seconds we want to keep the subscription for, a null cryptographic secret, and a Callback invoked when the subscribe request completes.
+
+
+
+
+
+
+
+ Certiorem is an implementation of the PubSubHubub protocol for ROME.
+It is dependent on ROME and ROME-Fetcher for the base implementations, and will provide standard plugins for Propono to allow for publish eventing, where applicable.
+ +The first part of Certiorem is a basic set of scaffolding classes that can be used to create a PSH notification hub. Initially, this will include a non-guaranteed delivery hub, with standard implementations suitable for deployment on most JavaEE application servers or Google App Engine. It is intended that there should be at least one simple, drop in WAR file, utilizing JavaEE classes that can work in a default configuration for various standard web containers. Subsequently, each of the classes in the PSH implementation up through the primary Controller class use constructor-time composition/configuration so that the user/developer can easily construct a custom configuration of the Hub.
+For web-based applications that use ROME-Fetcher, an extended push-notified store wrapper that will update based on callbacks from a Hub of change notifications. This will include a highly configurable callback servlet to write into the Fetcher cache as changes are made. Additionally, the system should support (semi-)real time notifications of changes in the form of a listener that exectutes in a TBD thread state relative to the callback servlet. This should be packaged as a simple JAR with no more deps than fetcher that defines the callback servlet, and automagically does subscribes where link=rel appropriate.
This should be a simple API call to notify a Hub of changes to topics. Again, this should provide real-time notifications either synchronously or asynchronously. Importantly for Asynchronous notifications, they should block subsequent change notifications pending a notification to the Hub.
+References:
+ +http://grack.com/blog/2009/09/09/parsing-the-pubsubhubbub-notifications/
It is still mostly a rough sketch, but the big outlines are there:
+There are three main packages: pub, sub and hub.
+The pub package is basically just a single utility class for pushing notifications to a hub.
+The hub package contains the Hub class. This is a general business controller that is intended to allow you to build a servlet around it with a very, very thin veneer, but you could also use it to drive an XMPP or JMS version too. It is basically built by composition of a number of classes, for which there are some default implementations: A Verifier, which makes the callback to verify new subscriptions, the HubDAO which stores the current subscriptions and subscriber statistics, and a Notifier which actually sends notifications to the subscribers. There are a couple of implementations of each of these (though the JPA HubDAO is still in process). Mostly the implementations for the Verifier and Notifier support threadpooling or no-threads (for App Engine use).
+I have just started sketching out the sub package, but it basically has a "Subscriptions" class that will take in notifications (using the same "thin veneer" pattern that the Hub class uses). It is also constructed with some impls: A SubscriptionDAO that stores you current subscription information, a FeedFetcherCache that holds the received data, and a Requester that makes the subscription requests to hubs.
+I am hoping to have a basic end to end example working sometime in the next week or so, but if anyone wants to look over what is there, feel free.
+
+
+
+
