Thursday, May 28, 2009

Transparent Client-Server PubSub implementation details

For those of you interested in source code, here are the links to the implementation of my prototype of a transparent publish-subscribe system between client and server:

  • three new URLs are "exposed":
  • /event/forward accepts events published on the client and publishes them on the server
  • /event/bind send the information about which events the server would like to subscribe to to the client
  • /event/listen is a comet connection which is used to transfer events published by the server to the client
  • lib/bespinserv/pubsub.js implements the actual pubsub mechanism in the server.
  • a java.util.concurrent.locks.ReentrantLock() is used to implement the lock for the comet implementation. This was taken and slightly modified from the ServerJS comet example.
  • Whenever a subscription is fired on the server, the event queue (and thus the associated client) is saved in a global variable (remember JS is single threaded) so that when the server does a publish we know where to send the event.
  • Multicast publishes are not supported.
  • Upon "/event/bind" the client creates stub event subscriptions which forward the actual event to the server using /event/forward
  • The client connects to /event/listen. Once it returns the client publishes the returned event and starts listening again immeditately.
Please excuse the messed up indentation, I was using a new editor (not bespin :).

I'm personally not convinced that this architecture should be used because the beauty of REST goes away. On the other hand, I feel that the artificial border between client and server does not make sense for some applications and thus it is great if it goes away. Opinions?

No comments: