Collaborative Portlets - Summer Term 2005
DescriptionPortals are Web-based applications aggregating content from various sources and displaying it to the users via standard Web-browsers. This project especially focussed on the creation of collaborative portlets. These gather information from collaborative applications (e.g., presence awareness from instant messaging, or activity from shared workspaces) and provide it within a portal's context.
Figure 1. The overall architecture of Java-based portals. They consist of a portal Web application (left box), a portlet container (middle box), portlets (right boxes), and their communication interfaces.
Java-based portals are comprised of a portal Web application, a portlet container, portlets, and their connecting interfaces (cf. Figure 1). Information chunks are brought together by portlets, which are pieces of code conforming to the Java Portlet API (JSR 168). They produce their part of the portal’s content as a so-called markup fragment (cf. Figure 2). One or more portlet fragments make up a portal page. Portlets are run and managed inside the portlet container, which communicates with the portal Web application.
Figure 2. A portlet delivers a fragment which is presented inside a portlet window on the portal page. The window shows the portlet’s title and offers controls for maximizing (M), minimizing (m), editing (E) as well as a facility for help (H).
The Collaborative Portlets project portlets mainly aggregate information from the CML’s TikiWiki (a wiki server) and BSCW (a shared workspace server). Starting with a summary about all projects at the CML (cf. Figure 3), the information is presented to the users in an unified view, which provides drill down and roll up functionality in order to obtain more or less details on a particular subject (cf. Figure 4). Information presented shows current online states of lab members and various views of project activity (e.g., changes to TikiWiki pages, adding or editing documents in BSCW).
Figure 3. The portal’s overview page. Here, infomation can be found about ongoing projects and currently online users.
Figure 4. A more detailed project view offers information about project members and recent project activity aggregated from TikiWiki and BSCW.
Besides an HTML representation of the portal content in the users’ browser, the system offers RSS (Rich Site Summary; a standard XML-based format to represent short information (e.g., headlines) together with hyperlinks where to obtain more details) feeds to use the aggregated information via content syndication or in feed readers (i.e., other third party applications supporting the RSS format may retrieve information about the CML).
Figure 5 depicts the project’s overall architecture. There are about 40 software sensors retrieving information from the TikiWiki and the BSCW servers. TikiWiki sensors use the JDBC (Java Database Connectivity) to directly access TikiWiki tables in its database. BSCW sensors leverage BSCW’s XML-RPC API to retrieve events and address book data. All sensors are controlled by the Harvester system service that forwards the gathered data in a generic format to the SensBase infrastructure that has been implemented with the CML Sens-ation platform. Portlets retrieve information from SensBase via XML-RPC and present it to the users by accumulating and aggregating specific values. They run inside an Apache Pluto portlet container, the Portlet API’s reference implementation. Pluto’s portal driver is used as simple portal Web application.
Figure 5. Behind the scenes: the Harvester system service gathers information from about 40 sensors from TikiWiki and BSCW via their APIs and fowards it to our SensBase infrastructure. Portlets retrieve and combine information chunks and present them in the user’s web browser.
PeopleTom Gross (Supervisor)
Christoph Oemig (Supervisor)