Meanwhile, on the server the following Java code is running in a thread:

while (!Thread.currentThread().isInterrupted())
{
    Collection sessions = serverContext.getScriptSessionsByPage("/dwr/gi/index.html");
    ScriptProxy proxy = new ScriptProxy(sessions);

    Corporation corp = corporations.getNextChangedCorporation();
    proxy.addFunctionCall("OpenAjax.publish", "gidemo", "corporation", corp);

    int timeToSleep = random.nextInt(2500);
    Thread.sleep(timeToSleep);
}

This simply finds the people viewing this page and creates a ScriptProxy to allow us to push JavaScript to these users. The ScriptProxy is a feature of DWR 2.0 enabling DWR 2.0 to dynamically generate JavaScript from a Java API. This is done at runtime rather than compile time, so we can use it to remote control many browsers. This makes it very easy to write things like chat applications, or anything particularly dynamic. Messages are sent to clients across using DWR's "Reverse AJAX" capability.

We then ask the corporation's object for a Stock price change, and publish this to the Open Ajax Hub.

That's it. Pretty simple.

For the full source to all the files, including the TIBCO GI project files, see the source in the .war file download for DWR 2.0.

Other AJAX Controls
Changes to Java Objects are sent to DWR 2.0's Reverse AJAX connection, and converted to JavaScript by DWR. In this case, the converted objects are wrapped in the OpenAjax Hub's publish method so that when the pushed code arrives at the client, the OpenAjax Hub publishes the data to a message topic name. The JavaScript Objects, such as the TIBCO GI matrix GUI component, are coded to listen for new information on that topic and, in turn, handle the new information when it arrives.

Conclusion
The solution above demonstrates how easy it can be to implement powerful systems based on sound publish and subscribe architectural principles. Further, the decoupled nature of the publish and subscribe style implementation enables one piece of a system to be added or replaced without effecting other parts. Accordingly, this approach is highly applicable to mashup and AJAX portal scenarios. As shown, beyond the basics of using the emerging publish and subscribe standards of the OAA Hub to connect reusable client-side components, technologies, such as DWR 2.0's Reverse AJAX and TIBCO's just released Ajax Message Service for highly scalable real-time data over HTTP, are enabling publish and subscribe events to occur across the network. Accordingly, one can begin to think not of an HTML page in a browser connected to a server across a network, but instead the AJAX application running in the browser being in the same event cloud as the server, publishing to and subscribing from streams of information mediated by event bus architectures on the client and on the server, and, accordingly, enable you to build more powerful AJAX solutions.

OpenAjax Hub for Interop
Two months ago in New York, immediately following AJAXWorld East 2007, the OpenAjax Alliance met and held its first InteropFest where a handful of the more than 75 industry members of the nascent AJAX standards organization demonstrated their technologies working in context of the first specification project of the alliance - the OpenAjax Hub (OAA Hub). If you haven't been watching the evolution of this specification targeted at enabling AJAX libraries and controls to be interoperable, it's rather interesting that at the core of the OAA Hub is a publish and subscribe event and message bus leveraging the tried and true interoperation approaches typical of server-side integration strategies, but instanced on the client side.

Why is a "pub/sub" system at the core of the standard interoperation strategy for AJAX? With increasingly sophisticated AJAX software, mashups, and composite applications being built today, the pub/sub strategy makes developing such things simpler. Consider that when you have a system consisting of more than one part, and especially in such systems that may grow and change over time like mashups, portals with AJAX portlets, or composite applications, instead of writing procedural code for each part of the system that needs to work with another (which as you CS majors know, leads to the classic "n-squared" integration complexity problem), it's far more efficient to implement a system for receiving, then dispatching events and messages so that one part can publish an event through the intermediary pub/sub hub, and then other parts that need information from that system can implement specific listeners that subscribe to, receive, and handle the events and messages.

As opposed to the more primitive DOM events such as onclick, onkeydown, onmouseover, and the like, typically these types of events and messages are associated with "application-level" concepts such as like "userLoggedIn", "newCustomerCreated", or "addNewStockSymbol".

Figure 3 compares a system with five parts directly linked to each other in a point-to-point fashion with a system implemented in a publish/subscribe message bus architecture.

Architecting your AJAX applications using publish and subscribe techniques enables each part of the system to be decoupled from the others, and thus to be built and managed as distinct units. This modularization not only facilitates greater reuse and more efficient team development, but also helps you to avoid creating the hairballs of code typical of point-to-point architectural approaches to application systems. The more elements in a system, the most complex and expensive adding to and maintaining the system becomes in point-to-point architectures when compared to publish/subscribe bus architectures.