Inter-portlet communication considered harmful

The title of this page is more a premise than a conclusion. By exploring the problem space, and some alternative possible solutions, I hope to suggest that there are better ways.

I was motivated to write this page by seeing an article about event-driven synchronization using Javascript (7), though I do not propose Javascript as the final solution but as a stepping stone.

Contents:

1. About Portals

See also: ProblemsWithPortals

What is a portal? From JSR-168 (1):

A portal aggregates content from a number of portlets. In their normal operating mode ("view" mode), which is the only mode a portlet is required to support, a portlet is specifically expected to generate markup (i.e. presentation) content (cf. (1), section PLT.8.1

In discussions with advocates of Portal technology, two key benefits have been described to me:

These may be quite important benefits in some contexts, but I also feel they are quite limited. And the technology that provides these benefits should also be limited in its impact on applications that are accessed using portals.

By way of a "sanity check", I keep in mind my very own dekstop "portal", which consists of a series of browser windows arranged in my computer desktop window. What does a portal provide that this does not?

I do not mean to suggest that these are immediate practical alternmatives to a portal server, but that they suggest alternative ways to achieve the same benefits. Furthermore, these alternative means are, by their very nature, working with rather than against existing web architectural principles. It seems to me that the whole portal technology endeavour is replicating technology that mostly exists already in existing World Wide Web software, in order to add a few marginal features. My goal here is to try to isolate some of those added features, and to suggest that it would be easier to concentrate on independent implementations that work with rather than displace existing Web software.

I would argue that the personalized aggregation of presentation and single sign-on functions could be separated. Then, the single-signon benefit would be available to systems that do not use content aggregation, and vice versa. But, probably more importantly, separating these concerns requires us to work more closely with existing web mechanisms to provide the kind of combined functionality offered by a Portal. I believe that a such a solution would be inherently simpler and more robust than current Portal implementations, by virtue of substantially re-using well understood and widely implemented standard Web components. Further, such an implementation strategy would allow better performance and scalability by offering greater choice concerning the locus of provision for various aspects of the service.

From here on, I shall focus on one aspect of portal technology, inter-portlet communication.

1.1. Inter-portlet communication

Current efforts in the world of portal-related standards propose to introduce a specification for inter-portlet communication (e.g. (9)). The only compelling use-case of which I am aware for this capability is the synchronization of multiple views of some shared underlying data. For example, a new query entered into a search request window might update results in a search results window.

In the world of non-web software development, this requirement has been addressed by the Model-View-Controller by explicitly structuring an application so that multiple views of some common data (model) are synchronized by a controller element that knows about the possible interactions between views. Inter-portlet communication is suggested as one way to achieve this in a portal framework, taking account of the fact that web applications are driven by the presentation component (i.e. the browser) rather than by the underlying application.

But this remains a requirement also for non-portal web applications. Would it not be better to devise a solution that works separately from any portal infrastructure? Such a solution would work equally well in an environment that happens to aggregate the presentation from multiple web resources. Is such a solution possible?

1.2. Porlets as application building blocks

A colleague has pointed out to me an example of library support for inter-portlet communication (8), which might be taken to indicate that (a) reasonable people may view portlets as a sensible building block for web applications, and (b) many of the concerns about complexity and overhead may be alleviated by using an existing library.

Firstly, I'd like to say emphatically that if a developer finds the easiest way to solve a particular problem is to build upon existing portal software, then I think that is a reasonable and sensible approach to solving that problem. My argument is with attempts to standardize inter-portlet communication for creating distributed web applications when much of the functionality can be provided by existing standards.

Taken in this light, my argument with (8) is in an early paragraph:

Given that portal technology exists to perform aggregation of presentation from multiple web applications, for me this paragraph exactly describes something that portals should not be expected to perform -- i.e. be an alternative MVC framework for building multi-view web applications. Essentially, inter-portlet communication used in this way acts as a "band aid" to patch over a fundamental architectural limitation of the technology upon which portals are based, viz. the web "pull" model for updating displayed information. A general solution to that problem, which I argue can be very much simpler than portal technology, could eliminate the need to extend portal frameworks into areas for which they are not well suited, and address many similar problems for non-portal web applications. (In addition to portal channel/view synchronization, I am aware of several specific non-portal applications with requirements that I believe can be addressed with a common mechanism: multimedia synchronization (cf. DMSP proposal to IETF), online web gaming, web-based control and monitoring, presence display in web browsers; I feel sure there are many more.)

In summary, my response to this kind of development is:

  1. The view-synchronization problem should be separated from the display aggregation problem, so that it can be implemented in non-portal environments. It may be that a portal provides support for synchronization, but a portal should not be required.
  2. The functional requirements should be analyzed to identify the minumum new functionality needed to achieve the desired result, while making maximum use of functionality that already exists. There are already plenty of protocols for sending information between processes, so we don't need another one. The small piece that I believe is missing is the means to notify a web client that new information is available. Beyond that, existing protocols can be used to perform the update.

2. Web view synchronization

How are we to arrange that multiple web views of some underlying data can be reasonably synchronized?

A problem is that web applications operate by "browser pull" rather than "application push". When an application has new data for a browser, it has no way to send it until the browser actually asks fo it. This is fundamental to web architecture, and is one of the reasons that the Web has proven to be so scalable, because it keeps un-needed complex state management out of the servers and other "interior" components of the Web. See also: (4). This is not to say there is no state in the Web, but such state is provided and managed as-needed by applications rather than by the common Web infrastructure. (By contrast, portal technology requires the Web portals to manage considerable amounts of state, which I posit is a source of much complexity in portal-based systems.)

Bearing in mind the cost of maintaining state, what is the minimum functional enhancement that is needed to provide multi-view synchonization? One very simple approach, requiring no state beyond what is already present in standard web software, is to have the browser automatically perform a periodic page refresh. While this (nearly) achieves the desired effect, it is ugly and horribly inefficient for pages that do not change. I think a minimum workable solution would be a way to deliver notifications to any browser that is viewing a page that is subject to update, and whose display is required to be re-synchonized when such an update occurs. Such a capability is not built into current web software, so it it realistically possible to achieve? Adding the event generation capability to server-side web applications is, I believe, a tractable proposition, and (given a suitable event propagation standard and implementation) would certainly be no more difficult than implementing inter-portlet communication for those applications. Adding the capability to browsers for responding to such event notifications is more problematic.

There is currently a lot of buzz around the topic of Ajax. Most modern browsers implement Javascript, and are capable of issuing asynchronous HTTP requests back to a server. It is almost certainly possible to implement an event receiving infrastructure in Javascript that is widely deployable on modern browsers. (I am currently developing such a capability for web-based building control system, as part of my work outside the University.) But using Javascript is not entirely without problems, notably security concerns, and using Javascript for the simple goal of forcing a page refresh might reasonably be regarded as a sledge hammer to crack a nut. But it could be made to work.

In this view, the role of a portal could be greatly simplified: state management concerns, other than the actual details of aggregating presentations from multiple Web sources, could be pushed "inwards" to the application, or "outwards" to the browser. Further, it could be that a browser side implementation of presentation aggregation could be employed, with portal aggregation a fallback for browsers that don't support this. Authentication and personalization persistence could be pushed in to ordinary web services using ordinary HTTP GET/POST requests. In the final analysis, a portal in this view should be little more than a regular Web proxy and a relay for event propagation.

3. A strategy for developing web-friendly multi-view applications

In the previous section, I suggest that the browser end of view synchonization could be provided by a simple event receiving implementation in Javascript, while recognizing that using Javascript is not the ideal solution.

This suggests a strategy for creating a standard for Web view synchronization:

  1. Define a simple event and event propagation model. (There is a fair amount of work been done in this area, so it should be possible to find a ready-made solution and simply adopt that, especially for the protocol; e.g. (5), Jabber presence notification (6), or something based on other existing instant messaging presence services. I believe there is also some relevant work related to web services choreography standardization.)

  2. Adapt or front-end applications to publish update events when the underlying model (i.e. data) is changed.
  3. Provide an HTTP server interface for (1).
  4. Implement an event subscriber/receiver library for (3) in Javascript.
  5. In the web-serving component of event publishing applications, include:
    1. a metadata header (HTML <meta> or similar) that identifies the source of any events used for indicating page updates

    2. Javascript code to monitor for events on the HTTP channel, using the HTTP interface from step 2. (The Javascript code should obtain event source information from the HTML metadata header.)

At this point, we should have a deployable view synchronization framework, albeit dependent on Javascript.

  1. optional: develop portal/proxy code to watch for event publication headers in requested resources, proxy those events, and update the event metadata accordingly. The motivation here is pure optimization, to allow intelligent caching and local updating of updatable views. Functionally, it should be a NOOP.
  2. adapt an existing open-source browser (e.g. Firefox) to use native event receiving mechanism, duplicating the functions of the Javascript code in native browser code. (Problem: there should be some way of disabling the Javascript code when the event handling is being performed by the browser. Maybe an Accept-events header?)
  3. Based on this experience, prepare IETF Internet Drafts and/or W3C submissions describing the protocols used and the expected application and browser behaviours.
  4. Also based on this experience, prepare Internet Drafts and/or W3C submissions describing the HTTP adaptation layer used for making the events available to browser-side Javascript.
  5. Engage with the Portal software and standards communities to show how the Portal-independent event propagation mechanisms can be used to implement inter-portlet communication (for those who still want such things). Independent implementations of the event propagation mechanisms within portal software should be sufficient to take the event propagation protocol profile onto an Internet standards track.

4. References

  1. http://jcp.org/aboutJava/communityprocess/final/jsr168/ - Portlet API specification (JSR-168)

  2. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp - WSRP OASIS TC page, links to specification

  3. http://shibboleth.internet2.edu/ - Shibboleth project

  4. http://lists.w3.org/Archives/Public/www-tag/2006Feb/att-0076/State.html W3C TAG draft finding on state - I think the discussion of state based on this document may have some bearing on the appropriate role of Portals in a web-based VRE environment. W3C TAG discussion starts here.

  5. http://www.codeontheroad.com/papers/draft-schwartz-apex-pubsub.html

  6. http://www.xmpp.org/specs/rfc3922.html

  7. http://ajaxpatterns.org/Distributed_Events

  8. http://wwwhomes.doc.ic.ac.uk/~mo197/portlets/portlet_messaging/

  9. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp

    • Cf. "Cross-Portlet Coordination SC: Chartered to define how portlets can react in a coordinated manner to user interactions with any portion of the overall application."

Note that Internet drafts expire after 6 months, or when they are updated. If the URIs are broken, try searching for the base Internet Draft name (e.g. draft-ietf-widex-requirements) using Google, or via the IETF search page at https://datatracker.ietf.org/public/idindex.cgi?command=search_id.


-- GrahamKlyne 2006-03-02 16:50:56

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.