The publish/subscribe Internet

The power of event-driven messaging is coming to Web services

By Jon Udell

InfoWorld |

If Web services were just "CORBA with angle brackets," there would be nothing revolutionary about the idea. Don't get me wrong, remote procedure calls over the Internet -- using HTTP as a universal transport and XML as a universal data representation -- beat the pants off CORBA, RMI (Remote Method Invocation), and DCOM (Distributed Component Object Model). I never accomplished much with those earlier technologies. Using XML-RPC and then SOAP, I've cooked up simple but useful applications based on a witch's brew of operating systems, application servers, and scripting languages. So I'm the last guy to kick sand in the face of SOAP as an RPC protocol. It's easy, universal, and productive. What's not to like?

Well, as much as we pretend otherwise, the Internet isn't one giant LAN. It works remarkably well much of the time, but variable latency and sporadic failures are no longer exceptions, they are the rule. HTTP's statelessness was the first major adjustment to this new reality. Hit the InfoWorld home page, and your browser will make a dozen separate requests of our server. If a few of those fail, it'll keep trying until it finally assembles the whole page.

Of course, why were you hitting our site in the first place? Presumably to find out about topics that interest you. Since you've got better things to do than poll the site to find out what's new, we publish feeds that you can subscribe to in order to be notified when updates occur. If you're reading this column, you've subscribed to one of those feeds, in the form of an e-mail newsletter. (There are others[1] as well.) You might also be using an RSS (Rich Site Summary) newsreader to follow one of our syndicated XML newsfeeds[2,3,4,5]. These are all simple examples of a publish/subscribe services architecture. As pub/sub and asynchronous messaging get baked into the Web services stack, things are going to get a whole lot more interesting.

For example, Radio UserLand -- the software that powers my InfoWorld Weblog[6] -- has pub/sub capability. The Radio UserLand newsreader can register an XML-RPC callback procedure with a newsfeed-publishing server. Thereafter, the server notifies the newsreader when it has new items, so the newsreader need not poll the server.

The pub/sub idea was also woven deeply into Microsoft's HailStorm. The .Net My Services (now back-burnered, but not forgotten) are really just network-based data stores -- My Lists, My Categories, My Contacts. Each offers an XML-based API that supports registration for change alerts. A developer would use an XPATH expression to define the set of elements in a HailStorm document that would trigger alerts if changed. Any authenticated user of the document would then be automatically notified of the changes.

Pub/sub is standard fare in the world of message-oriented middleware. Tibco was an early innovator, but with IBM's MQSeries, Microsoft's MSMQ, and the Java Message Service (supported by IBM, Sonic, Sun, BEA, and others), pub/sub is now routinely offered as an alternative to point-to-point messaging.

Meanwhile a new generation of middleware vendors -- such as Kenamea and KnowNow -- have brought pub/sub messaging down to the desktop. Using their kits you can subscribe a cell in a spreadsheet, or a paragraph of an HTML document, to a topic that's managed somewhere out in the cloud. When an event is posted to that topic, such as a stock ticker update or the approval of part of some business process, it routes directly to the hotspot in the spreadsheet or document. Macromedia's Flash Communication Server MX makes Flash clients capable of the same kind of thing.

Queued messaging, also known as store-and-forward, is part of the "loosely coupled" architecture now envisioned for Web services. Pub/sub is based on queues, but it's not just about point-to-point communication. Events published to a topic may fan out to many recipients. And those events can be almost anything you can think of: a user clicking a button, a temperature rising above a limit, an appointment landing in a calendar.

The Web services stack doesn't yet prescribe a standard way to implement pub/sub. But Microsoft's proposed WS-Routing and Sonic Software's plan to weave JMS support into the Apache Axis engine are a step along the road. Meanwhile, there are lots of ways to skin the cat, and it's a good idea to get familiar with them. Remember when GUI programming came along, with its notion of an event loop that didn't really control anything but reacted to everything? Programming in a world of distributed Web services is going to be a lot like that.