Inter-portlet communication considered harmful
(Personal opinion; work-in-progress.)
(First draft: very rough.)
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.
1. About Portals
See also: ProblemsWithPortals
What is a portal? From JSR-168 (1):
- A portal is a web based application that (commonly) provides personalization, single sign on, content aggregation from different sources and hosts the presentation layer of Information Systems. Aggregation is the action of integrating content from different sources within a web page. A portal may have sophisticated personalization features to provide customized content to users. Portal pages may have different set of portlets creating content for different users.
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:
- Single sign-on
- Persistent personalization of content
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?
Single sign-on. A sign-on in one browser does not immediately provide access to content from the other browser windows. But modern browsers do go some way: they can remember login details and provide them as defaults when returning to a previous page. This is, of course, something quite different from single sign-on, but the practical effect in my experience is much the same: I can access protected pages more easily. Further, I can see no reason why a web browser could not be Shibboleth-enabled (Shibboleth (3) being a popular system for federated authentication, with Shibboleth 2 use of constrained delegation used to pass authentication tokens to Shibboleth-aware Web applications.)
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:
- You want to build an application out of several interacting portlets (e.g. a portlet which presents a list or index, and a number of portlets which display information about the selected item)
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:
- 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.
- 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.
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
This suggests a strategy for creating a standard for Web view synchronization:
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.)
- Adapt or front-end applications to publish update events when the underlying model (i.e. data) is changed.
- Provide an HTTP server interface for (1).
- In the web-serving component of event publishing applications, include:
a metadata header (HTML <meta> or similar) that identifies the source of any events used for indicating page updates
- 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.
- Based on this experience, prepare IETF Internet Drafts and/or W3C submissions describing the protocols used and the expected application and browser behaviours.
- 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.
http://jcp.org/aboutJava/communityprocess/final/jsr168/ - Portlet API specification (JSR-168)
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp - WSRP OASIS TC page, links to specification
http://shibboleth.internet2.edu/ - Shibboleth project
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.
- 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."
4.1. Other related documents
http://www.w3.org/TR/scxml/ - W3C: State Chart XML (SCXML): State Machine Notation for Control Abstraction
http://www.ietf.org/internet-drafts/draft-ietf-widex-requirements-02.txt - Widex requirements (Widget Description Exchange)
http://www.ietf.org/internet-drafts/draft-stirbu-widex-framework-01.txt - Widget framework
http://www.ietf.org/internet-drafts/draft-stirbu-widex-beep-00.txt - Widex over BEEP
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