Push and Pull in Application Architectures


Back in November, Lisa Dusseault put out a call for papers regarding an Apps Area Architecture Workshop to be sponsored by the IETF in February 2008. Since my "paper" is on push and pull (not push vs. pull, mind you), I figured it would be appropriate for me to post it on my blog so that folks could receive updated versions in the Atom format using their preferred push or pull technologies. Comments are welcome. This is the first draft and I reserve the right to modify it as I think more about the topic.

The Internet contains a great deal of information. Some of it is even interesting.

What is the best way for me to learn about or receive information that I might find of interest? There are two basic approaches:

  1. I go out to find it. We call this pull.
  2. Someone sends it to me. We call this push.

Debates rage eternally about the relative merits of pull vs. push, just as they do over the relative merits of Emacs vs. vi, chocolate vs. vanilla, and other religious topics. Can we shed more light than heat onto the choice of pull, push, or some combination thereof in application architectures? Let us try.

The classic example of a pull architecture is the World Wide Web, in particular HTTP. If I want to receive some information, I send a request to a web server and the web server responds by transferring the information to me. The same model holds true of FTP, where we even use the phrase "pull down a file" to describe the act of requesting and receiving the information of interest.

The classic example of a push architecture is electronic mail. You want to send me information that I will find of interest (say, a mortgage scam) so you generate a message that is pushed to me and spontaneously appears in a special interface I maintain to receive such important information. A similar architecture is used in instant messaging and other methods for effectively interrupting me.

As with everything else, folks have a tendency to polarize the discussion. But there is no reason why an application architecture must be either push or pull. Why can't it be both? Indeed, when an application is widely used, what emerges naturally is that technologists typically combine the push and pull approaches to get the best of both worlds. Here are some examples I'm familiar with (I'm sure there are many others):

The challenge of finding the right balance between push and pull is, I think, an issue for a wide range of application protocols: email (POP or IMAP plus SIEVE notifications), contact lists (à la XMPP rosters), file repositories (WebDAV when used for both file retrieval and change monitoring), calendaring (free/busy notifications and meeting changes), data syndication (whether to subscribe to or poll for Atom updates), and so on.

This mini-paper contains only my first thoughts on the subject. Further research and reflection are required...

Peter Saint-Andre > Journal