W3C Workshop on
Device Independent Authoring Techniques
Authoring Device Independent
Portal Content
Luu Tran
Sun Microsystems, Inc.
luu.tran@sun.com
Abstract
Web portals integrate and aggregate information and applications. Several
standards are emerging from the Java Community ProcessSM (JCP)
[1]
and the Organization for the Advancement of Structured Information Standards
(OASIS) [2] that will define how portal servers
operate and how portal content is delivered. Authoring content for
portals typically involves developing HTML [3].
However, authoring content for a device independent portal requires
special attention. In particular, authors need to consider the relationship
between device independence and the personalization and aggregation features
of a portal server when developing device independent portal content.
Web Portals
A web portal is an entry point to a set of resources that an enterprise
wants to make available to the portal's users. For some consumer portals,
the set of resources includes the entire Web. For most enterprise portals,
the set of resources includes information, applications, and other resources
that are specific to the relationship between the user and the enterprise.
Commercial portals often provide membership management, personalization,
aggregation, security, integration, and search services.
Several standards bodies have begun work on developing portal standards.
The JCP [1] has established a Java Specification
Request (JSR) 168 [4] to define a set of Java
APIs for Portal computing addressing the areas of personalization, presentation
and security. This API is intended to be used to develop portlets that
are meant to be aggregated. OASIS [2] has
established a Web Services for Remote Portals (WSRP) Technical Committee
(TC) [5] to define an XML and Web services standard
that will allow the plug-n-play of visual, user-facing Web services with
portals or other intermediary Web applications. WSRP defines a set
of rules that portlet generated markup should follow so as to not break
the aggregated portal page.
A device independent portal is one that can be accessed from several different
web access mechanisms or devices. A device independent portal server
provides the platform for deploying device independent portals. Portal
servers often invoke pluggable components, known as portlets, to produce
content. Authoring device independent portlets often involves understanding
and leveraging two primary features of a portal server: personalization
and aggregation.
Authoring Personalizable Content
Personalization is a portal server feature which allows portal content
to be personalized or tailored for a particular user. Personalization
can be user or system driven. User driven personalization often involves
a user selecting preferences or setting configuration values that explicitly
determine what content is displayed or how that content is formatted. An
example of user driven personalization is a user selecting various portlets,
e.g. weather, stock quotes, and then configuring those portlets, e.g. setting
a location for weather or stock symbols for stock quotes. System driven
personalization often involves a process by which content is selected or
generated based implicitly on either user or system level configuration.
An example of system driven personalization is displaying an advertisement,
e.g. from a technology company, on the portal of users who might have interest,
e.g. who have selected technology company stocks in their stock quotes portlet.
Authoring device independent portlets often involves identifying the aspects
of a portlet that are personalizable and the associated personalization
parameters. Personalization parameters are either device independent
or device specific and either portlet independent or portlet specific. For
example, a user's name is both device independent and portlet independent,
while the number of mail messages to display on a given device is both device
specific and portlet specific. We have found that a useful authoring
technique is to group together portlet independent parameters so they can
be stored and configured in one place and shared across multiple portlets.
Likewise, we have found that another useful authoring technique is
to group together device independent parameters so they can be used for
delivery to multiple devices.
Authoring Aggregated Content
Aggregation is a portal server feature which allows portal content from
various disparate sources to be combined and presented to a user in a single
response. This is done by invoking portlets to produce content that
becomes a fragment of a document, e.g. an HTML [3] table cell or a WML [6]
card. The portal server wraps the fragments with the necessary markup,
e.g. table headers, buttons, links, etc., and combines the result into a single
document that is sent as a response to the access mechanism.
Authoring device independent portlets requires special consideration of
the limitations imposed by the aggregation process. Because a portlet
returns only a fragment and does not have control over the entire response,
the portlet author must be aware of how the portal server will wrap the fragment.
For example, will the portal server supply the HTML [3] <td></td> tags or the WML [6] <card></card> tags, or will the portlet
be responsible for supplying those? Also, because the fragment is
combined with other fragments, the portlet usually only has available to
it a fraction of the maximum response size of the access mechanism. The
portlet author must therefore be careful not to produce too much content,
or the portal server will be forced to either break up or omit the portlet's
content.
We have found it a useful authoring technique to break up portlet content
into multiple units for limited devices. The units consist of a minimal
summary screen that references one or more other screens for detailed content.
The references could be to other cards in a WML [6]
deck, or to URIs to request another response. An added benefit to
breaking up portlet content into these units is that several units can be
reused for multiple devices. Only when a particular unit of content
requires markup for a specific device does an author need to supply an alternate
unit to be used for other devices. With this technique, the granularity
of device independence becomes much finer and more tractable.
Sun ONE Portal Server
The Sun ONE Portal Server [7] is a complete portal
platform for deploying robust business-to-employee, business-to-business,
and business-to-consumer portals. The Sun ONE Portal Server provides the services
required to build portal sites, including user and community management, personalization,
aggregation, security, integration, and search. With the Mobile Access
add-on, the Sun ONE Portal Server addresses the personalization and aggregation
aspects of developing and deploying device independent portals.
References
[1] JCP: "The Java Community Process(SM) Program", http://www.jcp.org/
[2] OASIS: "Who We Are", http://www.oasis-open.org/who/
[3] W3C: "HTML Home Page", http://www.w3.org/MarkUp/
[4] JCP: "JSR 168 Portlet Specification", http://www.jcp.org/jsr/detail/168.jsp
[5] OASIS: "Web Services for Remote Portals (WSRP) TC", http://www.oasis-open.org/committees/wsrp/
[6] OMA: "Wireless Markup Language", http://www1.wapforum.org/tech/documents/WAP-238-WML-20010911-a.pdf
[7] Sun Microsystems, Inc.: "Sun ONE Portal Server", http://wwws.sun.com/software/products/portal_srvr/home_portal.html