Pushlets: Send events from servlets to DHTML client browsers

Discover how pushlets, a servlet-based notification mechanism, enables server-side Java objects to call back JavaScript code within a client browser.

Page 3 of 3

Web presentations can also be useful for call centers, banks, or help desks. For example, when I phone in with a question, a call-center agent may guide me to URLs with solutions, offers, or other information.

Community tools

Community tools include various applications where multiple users can join a live session. I originally had a prototype of the framework where I created a multiuser session as a collection of HTTP Session objects. I plan to extend the pushlet framework with such capabilities. For now, I have a simple Web chat and what I call WCQ (in Dutch this sounds almost like "We Seek You"), a simple ICQ-like desktop window where you can monitor the presence of friends. Other applications in this area include live forums and shared document editing.

The consequences of using pushlets

Like any other mechanism or design pattern, pushlets present obvious advantages and disadvantages when compared with Java-based applets that use messaging or RMI/CORBA client callbacks.

Advantages

  • Direct integration with DHTML within the browser: data generated by the server can be immediately integrated into the page content of the browser. Therefore, all the layout capabilities of DHTML can be directly applied. With RMI or CORBA it is difficult to integrate the applet with its containing Web page.
  • Standard HTTP port and protocols: messaging and RMI or CORBA use dedicated ports that may not work through firewalls, and browser security restrictions may prevent callbacks or data receipt over UDP.
  • Low client weight: Java applets with RMI/CORBA often make the client heavier in startup and resource consumption; pushlets don't.
  • No extra server: messaging and RMI/CORBA often require a dedicated server product or at least a registry running RMI. pushlets can, in theory, run on any servlet engine, using functions such as connection management and multithreading (which may be a disadvantage, as well, as seen below).
  • Small protocol overhead.

Disadvantages

  • Cross-browser DHTML: some effort is required to make cross-browser DHTML libraries that work in all browser versions on all platforms.
  • Scalability: when hundreds of clients connect through pushlets, they may hog resources such as threads and sockets. On this scale it would be better to serve pushlets off a dedicated servlet server optimized for this type of HTTP usage. However, scalability is also an issue with CORBA callbacks.
  • Web-server issues: a Web server is usually not designed for long-lived connections. One solution is the same as that applied above under Scalability. For large-scale applications, a pushlet applet client that receives notifications as UDP messages may be used. The HTTP request is then used only for subscription.
  • Proxy buffering: As one reviewer of the pushlet concept pointed out, some proxy servers may buffer HTTP data.
  • Quality of service: the server gets no direct confirmation that the event has been processed successfully.

Further work

I am further testing the viability of pushlets. The pushlet framework is a generic Publish-Subscribe pattern, with HTTP-based pushlet clients as a special case. I am developing the framework with the following extensions:

  • Additional client receiver-protocols such as TCP and UDP. One interesting possibility is calling an applet that receives UDP messages from within the pushlet frame on the client. That would mean we don't keep the HTTP connection. In general, clients will subscribe with a HTTP request on which they indicate through which protocol (TCP, UDP, RMI, HTTP-stream, or HTTP POST) they want to receive events and in which format (XML, Java-serialized objects, and so on). The address of the receiver is specified, where required. For example, to receive XML-formatted stock events through UDP on port 5001, the request would look like this:

    http://www.fluidiom.com:8080/servlet/pushlet?subject="/stocks/aex"&format="XML"&protocol="UDP"&port="5001"
    

    With UDP a lease time needs to be specified (since the server would never know when the client leaves). If the lease is not renewed within this time, the server will drop the client.

  • Additional client sender-protocols. Currently, events are generated internally or through the postlet by using the HTTP POST request. Additional protocols such as RMI, TCP, and UDP may be applied.

  • Subject state. Currently, a subject is just a hierarchical string. A client that subscribes gets no history that may have built up -- a chatroom discussion, for example. In a next version subjects become first-class objects, so that when clients subscribe they may implicitly get the current state or may explicitly request the state.
  • Multiuser. although some multiuser applications are possible, there is no multiuser session control on the server. In earlier versions I experimented with combining multiple HTTP sessions into a multiuser HTTP session.

Conclusions

In this article we have covered quite some ground: server-side Java, servlets, DHTML, design patterns, and a framework. In its essence the pushlet technology is very simple, and, given its advantages and disadvantages, it may serve as an alternative to RMI or CORBA for certain Web applications.

The pushlet framework is in its early stages and being evaluated by a number of users. You may visit the pushlet Website through http://www.justobjects.nl to see how development is progressing, to run examples, and to download the framework source. Since I have planned it as an open source project, you are welcome to participate in development and review.

Just van den Broecke of Just Objects (http://www.justobjects.nl) is a freelance architect, developer, and trainer specializing in object-oriented design, distributed Java, and Web technology. His Java projects range from banking applications to multiuser multimedia tools for performing artists (http://www.keyworx.org). He believes Java is most effectively applied when combined with other technologies such as dynamic HTML and XML.

Learn more about this topic

| 1 2 3 Page 3