DISAS: a DISelect-based Middleware for Building Adaptive Systems Lorenzo Gallucci1, Mario Cannataro1,3, Luigi Palopoli1,2, and Pierangelo Veltri3 1
EXEURA S.r.L., Italy, 2DEIS–University of Calabria, Italy, 3University of Catanzaro, Italy.
Abstract. The paper presents DISAS, a middleware software that can be used to enable adaptation in existing web-based applications and legacy information systems. The proposed system provides an intermediate layer between the user and the data source that monitors system conditions, intercepts content streams, and adapts them on the fly, leveraging emergent World Wide Web Consortium standards, such as DISelect and CC/PP. DISAS has been fully implemented using two approaches: as a filter that transparently adapts hypermedia coded in well-formed XML with embedded DISelect adaptation rules, and as a tag library that allows DISelect constructs calls to be merged into active pages like Java Server Pages.
1 Introduction The Adaptive Hypermedia (AH) research field is on the stream from many years: an Adaptive Hypermedia System (AHS) models features of the users, client devices and network conditions, and applies such models to adapt various visible aspects of the system to the user [2, 3]. The basic components of an AHS are the Application Domain Model (DM), the User Model (UM) and the Adaptation Model (AM). The DM describes the hypermedia basic contents and concepts. It considers the different sources that affect the adaptation process and allows modeling them into application’s data. The UM describes the user’s characteristics and expectations in the browsing of hypermedia. User models or profiles are generally distinguished into overlay models, which describe a set of user’s characteristics (typically represented by a set of attribute-value pairs), and stereotype models which indicate the user’s belonging to a group. The AM contains the adaptation rules that are used to adapt content coming from the DM with respect to the expectations and constraints expressed by the UM. Adaptation rules are related to: (i) content selection, i.e. selection of parts of hypermedia to be presented to the user, (ii) content adaptation, i.e. manipulation of information fragments, and (iii) link adaptation, i.e. manipulation of the links presented to the user. An AHS continuously monitors user’s activity, network conditions, and client characteristics, to build the UM. When a page is selected, using the adaptation rules contained in the AM and leveraging the features of the DM (e.g. an information frag-
ment which is available with different sizes and informative goals) it is able to adapt the selected content with respect to the UM. Although AHSs are useful in many domains, when using them to make adaptable existing applications or legacy information systems, a hard problem arises: applications often need to be rewritten or adaptation rules are difficult to apply to current data. This is particularly true for e-government and e-democracy services that more and more are developed in public administrations by leveraging existing legacy applications, and need to provide adaptation, since they have to face internal and external users having different profiles, various terminal type and different network conditions. The paper presents DISAS (DISelect Adaptive System), a piece of middleware software that can be used to enable adaptation in existing applications and information systems. The main idea of the proposed system is to provide an intermediate layer between the user and the data source that monitors system conditions, intercepts content streams, and adapts them on the fly. Main characteristics of DISAS are the continuous detection of network and user’s terminal features and the dynamic adaptation of the contents based on DISelect constructs [7]. The impact on content description is maintained low by leveraging emerging standards for expressing user device capabilities, such as CC/PP [10], and for describing device independent content selection, such as DISelect. The characteristics of DISAS make it suitable for different application scenarios: other than classic adaptive systems where the final users are humans, the system can be used to automatically generate different kind of contents. As an example, developing applications for mobile devices such as smart phones requires sending contents and code in different formats. For instance, considering the Java Micro Edition platform (Java ME) [14], the JavaCard [15] and JavaPhone [16] technologies offer specialized Java APIs for executing Java programs on, respectively, smart card and phones. The same happens for terrestrial DVB (Digital Video Broadcast) content delivery [17]. For instance, the Multimedia Home Platform (MHP) [18] can provide two kind of delivery, DVB-HTML and DVB-J, that are interpreted on the user Set Top Box. Adapting contents for such scenarios requires a dynamic generation of contents that can be a mix of code (e.g. Java Xlet [19]) and multimedia data. The rest of the paper is organized as follows. Section 2 describes emerging standards to build adaptive systems. Section 3 presents requirements, architecture, and a running prototype of DISAS. Finally, Section 4 briefly describes related works and Section 5 concludes the paper.
2 DISelect: Content Selection for Device Independence Recently, there has been an effort in the World Wide Web (W3C) community to define a standard for the modelling of the contents of an AHS. The W3C Device Independence Working Group defined the Content Selection for Device Independence (DISelect) W3C Working Draft that specifies a syntax and a processing model for general purpose content transformation (filtering as well as manipulation) on an XML document [7, 11, 12].
A DISelect document is an XML document in which content pieces are merged with special transformation constructs (i.e. XML tags and/or special attributes), which a DISelect processor must take into account when presenting content to a user. Transformations are driven by expressions; general expressions are used in content manipulation (e.g. generation of values computed w.r.t. actual user profile), while content filtering needs boolean expressions. A term in a DISelect expression can be a constant, a function, or a variable (local to the XML fragment in which it appears). Functions in a DISelect expression are evaluated with respect to a reference environment (e.g. the User Model variables), which includes at least device parameters and may include variables related to network conditions. The Composite Capabilities/Preferences Profile (CC/PP) is a W3C Recommendation that allows expressing user device capabilities and user preferences, according to a shared structure and vocabulary of terms stored in RDF format [10]; it can be used to guide the adaptation of content presented to that device. Moreover, author-defined variables can describe other user’s profile parameters such as user’s class. Figure 1 shows a fragment of content selection DISelect code that produces a non empty result when screen width, i.e. a CC/PP value, is greater than 800 pixels. 800”>
Shown only when screen width is greater than 800 pixels.
Fig. 1. An Example of DISelect Code Containing a Content Selection Construct DISelect and CC/PP are the basic building blocks to develop novel and standardaware adaptive web portals: DISelect can be used to realize the adaptation rules, whereas CC/PP can be used as reference framework to manage data and metadata needed to realize adaptation.
3 DISAS: DISelect Adaptive System The main requirement for building an adaptive web system is to support adequately the evolution of an existing web application towards an adaptive one, via addition of a limited number of modules and progressive insertion of adaptation constructs into previously non-adaptive pages. As a consequence, the following objectives have been followed in the design of the proposed system: y to develop an automatic user profile detection software which could be easily integrated in a web system; y to design and develop a component, able to work “behind the scenes”, whose role is to mix content adaptation subparts into an adapted hypermedia;
y
to allow a developer to write content adaptation rules in dynamic web pages (e.g. Java Server Pages - JSP), without worrying about details on information source for user profile data used in rules, as well as on adaptation core. Following these requirements, a working prototype of an adaptive web system library called DISAS (“DISelect Adaptive System”) has been fully implemented. The system, built upon a set of standard Sun™ Java2 Enterprise Edition components, is based on the XAHM model [5] and follows the W3C Device Independence Working Group recommendations [11]. DISAS sits between a Web-based Information System and a standard web browser (i.e. the user), and is able to: 1. automatically and dynamically detect characteristics of the user’s terminal (e.g. browser and computer capabilities) and user’s context (e.g. geographic location, available network bandwidth, etc.), in a CC/PP compliant way ; additional user preferences can be statically defined; 2. deliver the contents of an Information System, expressed as XML documents containing DISelect code, to the user device, by applying a filtering engine that processes DISelect code and adapts contents with respect to user devices capabilities and user profile. The Profile Manager (see Figure 2 and Figure 3) supports user profile testing, reading and storing, and collects such user data in a user’s session store named Profile Store. Such profile management core can be seamlessly integrated in most J2EE applications. In particular, it: y detects, collects and stores a sketch of measured user profile parameters, such as user agent capabilities, network bandwidth, etc., employing a corresponding profile manager agent running on the client side; y makes available to the DISelect adaptation engine values taken from the user profile, reading them from the Profile Store; Content adaptation and delivery is implemented by using two complementary approaches (see Figure 2): 1. in the former, the DISelect Engine transparently adapts hypermedia coded in wellformed XML with embedded DISelect adaptation rules. In particular, a DISelect adaptation J2EE filter (DISelect Filter) processes only well-formed XML data containing DISelect tags, but is capable to apply the full DISelect model. It is used when Information System content is available as well-formed XML and every piece of information has to be computed; 2. in the latter, the DISelect Engine exploits a significant subset of DISelect rule language for non-XML coded hypermedia (such as HTML 4.0 code, JS or CSS), by means of a JSP DISelect tag library. The library allows DISelect constructs calls to be merged into active pages (e.g. JSP) other than in XML content. Thus also JSP code flow can be adapted, possibly skipping some JSP computation based on user profile values.
Profile manager (client)
Profile manager (server)
Profile store
User agent (browser) Client side
DISelect engine (taglib or filter) Server side
Fig. 2. Main Components of DISAS 3.1 User Profile Detection and Content Delivery Strategies in DISAS To accomplish adaptation of content, a dedicated agent has to combine adaptable hypermedia (i.e. XML documents with embedded DISelect rules coming from an Information System or a web application), with user and terminal information. Adaptation of content is performed on some circumstances such as first page load, user profile change or forced redisplay. Two operations modes are possible: responsibility of adaptation is either entirely left to “user agent”, or performed by the server. In the first scenario, the user profile itself is detected and monitored on the client side only and is not shared with the web server. This operating mode implies that the code to perform adaptation is either provided by the user agent itself, or mixed into the HTML page by the web application. In the former case, for each browser an appropriate code must be made available, as a plug-in or “built-in”, possibly providing better performances and shorter response times than in the latter case, where a platform-independent code, executable from HTML pages, is needed and, thus, a client-side scripting language as the not-so-fast Javascript has to be used. So, the former solution for client-side processing is not viable in the mid term (due the heavy load imposed on the browser authors), while the latter requires both libraries for performing efficiently XML transformations inherent to DISelect constructs, and a fast Javascript runtime, which is not always the case, especially for handheld devices. In DISAS we adopted a rather different approach, following the second scenario (server-side adaptation): y the page gets adapted before the server sends it to the client, thus content transformations can be carried out one time only on the server side (e.g on page load);
y
as usual, client side (web browser) detects user profile parameters, but related information is stored only on the server; y due to network delay, only most recent parameters are available, instead of current parameters, which would be the case in a “pure client-side DISelect” approach. At any time, a snapshot of latest measured parameters is available; this is updated at discrete times, i.e. when, in response to a page load request, DISAS considers profile information as unreliable (e.g. too old or incomplete). Hence, the user profile detection logic has to be automatic and as much unobtrusive as possible, to avoid breaking user’s experience. In DISAS the profile detection logic is both automatic and unobtrusive, since it is based on a small piece of Javascript code (carefully designed to run on a broad range of browsers), which the client runs in response to server’s solicitation. 3.2 DISAS Architecture Figure 3 shows the DISAS architecture and information flows between software modules. DISAS uses a classical three tiers architecture: the client layer contains the user agent (browser) and part of the Profile Manager; the adaptivity layer implements adaptation rules and profile management; and the adaptable web application provides content to be adapted, employing DISelect constructs. The information flow between layers is described in the following based on the path followed by an example HTTP Request (“/a”): 1. a dedicated component (“Profile validation”) in the Filters sub-layer must check if a fresh profile is available for the user (getting it from “Profile store”); 2. if good profile information is not found, “Profile validation” invokes “Profile tester generator” in the Servlets sub-layer, which returns to the client a “Profile tester”, able to communicate with “Network test counterparts”, in order to determine user profile parameters, finally sent to the “Profile saver”; 3. if good profile information is available (or just after “Profile saver” executed), the requested servlet or JSP is invoked (“Servlet or JSP page for /a”). If the requested URL is mapped through DISAS filter, the corresponding servlet is expected to generate well-formed XML with DISelect instructions, suitable for XML transformation; y JSP pages can take advantage of “DISelect taglib” to anticipate some transformations or to have the execution of some code subjected to the truth value of boolean expression involving information from user profile; y additionally, complex, recurring DISelect patterns can be coded into “Task-specific tag libraries”, which can be employed to simplify writing of JSPs;
Web browser GET /a
Profile tester
Adapted page
Profile tester generator
Filters
DISelect Filtering (XSLT)
Profile validation Network test counterparts
DISelect taglib
Servlets
Profile saver
Task-specific taglibs
Tag libraries
Adaptivity layer Data Profile store
Adaptable web application
Servlet or JSP page for /a [DISelect-enabled] Web Server J2EE-compliant (Tomcat, WebSphere, …)
JSP code
calls
HTML(+JS) page Adaptivity layer component
supports generates
Fig. 3. Detailed Architecture and Information Flow in DISAS
3.3 DISAS Prototype The DISAS prototype is built on a set of components whose design and packaging allows merging them easily in a Java2 Enterprise Edition (J2EE) web application. Compliant J2EE web container is needed for correct operation; prototype’s functionality has been tested on Tomcat 5.5.12, WebSphere 5.1, JBoss 3.2.7 and JBoss 4.0.1. To enable DISAS on an existing application, three steps have to be carried out: (i) copy DISAS’s components (core JARs and their dependencies, plus some resources) in appropriate locations (mostly WEB-INF/lib) (ii) define start-up configuration information in web application metadata (file WEB-INF/web.xml) (iii) map pages that have to be processed by DISAS to filter components. The adaptation subsystem ensures that properly mapped pages always get, automatically, a fresh user profile information set. On those pages, DISAS is able to recognize DISelect constructs which can access user profile information in order to carry out a significant subset of the content transformations offered by DISelect, i.e. content selection and content manipulation/generation. In particular, two kinds of constructs can be used to express content selection: y simple (on/off) selection, expressible via sel:expr attribute, when content fragment is a simple XML node, via sel:if element otherwise;
y
selection of zero, one (in matchfirst mode) or more (in matchevery mode) members among a set of content fragments, using sel:select combined with sel:when and sel:otherwise subelements. Obtaining content manipulation/content generation (e.g. insertion of values computed from user profile parameters using arbitrary expressions) is possible with either sel:value tag, or using attribute value templates (AVT), i.e. attributes whose value is a DISelect expression enclosed in braces. Given such a restricted set of features, one may consider expressive power of DISAS very limited, but some additional aspects, coming as well from DISelect, have to be considered on this subject: y a DISelect code is able to define arbitrary “variables” in which partial results can be stored (via sel:variable tag, with attribute name); moreover, the value of a “variable” can change over time (via sel:variable with attribute ref), as in traditional imperative languages and in contrast to rules holding for variables in similar manipulation languages for XML, such as XSLT; y the “content” embedded in content selection rules can be also a “meta” content, i.e. an XML fragment which comprises other content selection/manipulation constructs as well as tags to manipulate variables. While this set of services (automatic profile detection and seamless connection to basic content selection and manipulation) is obviously low-level, their availability enables building of more advanced services. This is exactly the role covered by taskspecific “taglibs”: capturing higher level adaptation constructs (“idioms”) in JSP tag definitions, translating them into lower level DISelect constructs.
4 Related Works and Future Trends Many Adaptive Hypermedia Systems have been developed in these last years, as those described in [2, 3, 4], and usually they are based on proprietary models and constructs for expressing device characteristics, application domain and adaptation rules. To our knowledge DISAS is one of the first attempts to develop an AHS middleware fully compliant to the emerging W3C standards. As discussed previously, both content transformation and profile detection take place in response to specific requests. Content transformation is triggered by a user requesting a page, user parameter detection is started on the client side when the Profile Manager decides to refresh profile information. In other words, no persistent client agent exists in DISAS that can re-trigger DISelect transformation or autonomously start measurements on user parameters. The availability of a persistent client agent that works asynchronously with respect to the server and to user requests could give many benefits, among them: y automatic re-adaptation of the page in response to a change in some of the user parameters; y continuous update (“tracking”) of quickly varying parameters, such as network speed or lag. The approach to transfer some processing activities, such as detection and adaptation, to the client, produces the so called Rich Internet Applications (RIA), that are a
cross between web applications and traditional desktop applications, transferring some of the processing to the client. The term "Rich Internet Application" was introduced in [1] although the concept was also know under different names such as X Internet and Rich Clients [6]. Usually, RIA applications: y run in a web browser or client agent; y run locally in a secure environment called a sandbox; y can be occasionally connected to the network/server. Such an approach is an emerging trend in developing web-based applications and could become a trend for future adaptive web systems; nevertheless, writing such rich client agent would be a challenge, which involves: y communicating with the server via asynchronous HTTP calls hidden to the user; such problem can be faced by using a technology commonly called AJAX (Asynchronous Javascript And XML), see [8]; y passing over compatibility issues between browsers, severe on Javascript, dramatic when it comes to manipulate directly HTML Document Object Model. Another trend we envision is the evolution of DISelect toward more abstract standards and libraries, able to offer adaptation models and language constructs more close to the hypermedia designer and author. Although DISelect formalism has good expressive power, it is low-level, so, in order to build complex adaptive web applications with DISAS or similar systems, a significant deal of work has to be carried out in finding recurring patterns (“idioms”) in real world applications, capturing them at an abstract level, then developing specialized tag libraries. Using DISAS or similar adaptation engines, additional tag libraries could be developed, to make easier and less error prone the process of writing DISelect code tailored to specific scenarios or tasks.
5 Conclusions Introducing content personalization in web-based applications requires a clear modelling of the contents to be adapted (application domain), of the technological and environmental constraints (network and devices), as well as of the goals of personalization (user model), and of the adaptation rules (adaptation model). Such steps are especially difficult when adaptation has to be taken to existing applications, such as public administration legacy systems. The paper presented DISAS, a middleware software that allows to enable adaptation in existing web-based applications and information systems. Its main characteristics are the automatic detection of network and user’s terminal features, the dynamic adaptation of the contents with respect to such quantities, and the implementation and adoption of emerging guidelines and standards. The DISAS system has been successfully used to enable adaptation in different services provided by the project “Intelligent and adaptive tools supporting e-Government and e-Democracy initiatives” developed to supports e-government and e-democracy initiatives in local (decentralized) Public Administrations in Italy.
Acknowledgements This work has been partially supported by the project “Intelligent and adaptive tools supporting e-Government and e-Democracy initiatives” funded by MIUR. Authors are grateful to Alfredo Cuzzocrea and Andrea Pugliese who worked on the XAHM model, and to Giulio Acati, Tina Dell’Armi, Egidio Giampà, Angelo Rafeli, and Pasquale Rullo, who worked on the first version of DISAS.
References [1]
Allaire, J. (2002). Macromedia Flash MX—A next-generation rich client. Macromedia White Paper. March 2002. Retrieved January 10, 2006, from http://download.macromedia.com/pub/flash/whitepapers/richclient.pdf. [2] Brusilovsky P (2001) Adaptive hypermedia. User Modeling and User Adapted Interaction, Ten Year Anniversary Issue, 11 (1/2), 87-110. [3] The Adaptive Web (Special Issue on). Comm. of the ACM 45, 5, May 2002. [4] M. Cannataro and A. Pugliese, A Survey of Architectures for Adaptive Hypermedia, in Mark Levene and Alexandra Poulovassilis (Eds.), Web Dynamics, Springer Verlag, May 2004. [5] M. Cannataro, A. Cuzzocrea, A. Pugliese, “XAHM: an Adaptive Hypermedia Model based on XML”, The Fourteenth International Conference on Software Engineering and Knowledge Engineering (SEKE’ 02), July 15-19, Ischia, Italy, ACM Press 2002. [6] Duhl, J. (2003). Rich Internet Applications. IDC White Paper. November 2003. Retrieved January 10, 2006, from http://www.macromedia.com/platform/whitepapers/idc_impact_of_rias.pdf. [7] Lewis R., Merrick R. (eds) (2005). Content Selection for Device Independence (DISelect) 1.0. W3C Working Draft. 2 May 2005. Retrieved January 10, 2006, from http://www.w3.org/TR/2005/WD-cselection-20050502/ [8] Paulson, LD. (2005). Building Rich Web Applications with Ajax. Computer. 38 (10), 14-17. [9] SoftComplex (n.d.). Tigra scripts. Retrieved January 10, 2006, from http://www.softcomplex.com/. [10] W3C CC/PP. (1999). Composite Capability/Preference Profiles (CC/PP): A user side framework for content negotiation. 27 July 1999. Retrieved January 10, 2006, from http://www.w3.org/TR/NOTE-CCPP/. [11] W3C Device Independence. (2003). Authoring Techniques for Device Independence, W3C Working Draft. 6 November 2003. Retrieved January 10, 2006, from http://www.w3.org/TR/2003/WD-di-atdi-20031106/. [12] W3C Device Independence Working Group. (n.d.). Device Independence. Access to a Unified Web from Any Device in Any Context by Anyone. Retrieved January 10, 2006, from http://www.w3.org/2001/di/.
[13] W3C WAI. (1999) Web Content Accessibility Guidelines 1.0. 5 May 1999. Retrieved January 10, 2006, from http://www.w3.org/TR/WAIWEBCONTENT [14] The Java Platform, Micro Edition (Java ME), http://java.sun.com/j2me/ [15] JavaCard Technology, http://java.sun.com/products/javacard/ [16] JavaPhone Technology, http://java.sun.com/products/javaphone/index.jsp [17] Digital Video Broadcasting Project, http://www.dvb.org/ [18] Multimedia Home Platform, http://www.mhp.org/ [19] Getting Started with Inter-Xlet Communication (IXC), http://developers.sun.com/techtopics/mobility/personal/ttips/ixc/
