Figure 1: Houdini architecture
customization, preferences, profile, policy management, rules
One main reason for the tremendous success of the Web is that it managed - since its early days - to establish a personalized relationship with its user. Wasn't the ``personal homepage'', the first Web killer app? At this point almost all web portals and web-based services offer some form of customization, from letting the end-user select what content to display and how, to storing end-user values (e.g., credit card information) to simplify future interactions, to providing alerts based on end-user requests. With the next revolution of the web based on the web service paradigm, will the infrastructure in place now be sufficient for customizing/personalizing the web services of the future? This short paper argues that the answer is a strong NO, and introduces an infrastructure that will be sufficient.
The customization infrastructure commonly used in today's web is value-based: the core logic of an application or service is essentially static, but end-users can insert personalized values to obtain customized behaviors. The prototypical example is an on-line newspaper, which lets the user indicate what types of and how many stories should be displayed on her ``front page''.
Consider now a composite web service of the future, which itself is formed from tens or perhaps hundreds of individual web services, that gather information from a myriad of sources and potentially invoke numerous side effects to fulfill an end-user's (or enterprise's) request. This is compounded in the context of ``converged'' services (i.e., services that combine web with telecom - e.g., voice calls, messaging). Because of the vast richness and variability in composite services of the future, if only value-based customization were supported, then an end-user would be overwhelmed when inputting all of her preferences. What we need is rule-based customization, whereby end-users can express their preferences at a higher, more generalized manner than possible with value-based customization. With rule-based customization, the preferences of the end-user can translate into rules which impact both values used by the service, and also portions of the core logic of the service.
To motivate the need for rule-based service customization, consider a scenario where a user is on a WAP-enabled phone and wants to find out the good restaurants in her current neighborhood.
The user sends a corresponding WAP request to a restaurant web site which needs to determine the user's current location so that it can send back a list of the five nearest restaurants. Hence, the web site sends a request to the telephony network, in particular, to the Gateway Mobile Location Center (GMLC), to determine the user's location. Based on the information the web site receives from the GMLC, it then generates the corresponding response to be sent back to the user. Because this service is location-based, using the user's favorite restaurants will not do in this case. The user wants to express her preferences in terms of type of cuisine, expected waiting time, price, method of payment accepted. (Most of this information is already available on the Web from web sites like zagat.com). It is also useful to incorporate preferences about current context, e.g., participants in the meal and their preferences, time of day, weather, when is next appointment on user's calendar, business or pleasure, applicable corporate policies, etc. In some sense, there is no end to the amount of customization that an end user might want to incorporate into a restaurant locator service.
Note also that customization should not infringe on the user privacy. In our example, the user is willing to provide access to her location information for the purpose of offering her a better service, not for tracking her whereabouts (e.g., Big Brother).
As we have seen, the infrastructure in place today is not sufficient for customizing the next generation of web/converged services. We now present a generic infrastructure called Houdini that can provide some privacy-conscious customization of services, where user data can be interpreted according to the user preferences while preserving user privacy through enforcement of access control.
In the following, a requester (e.g., another user or an application) will request some information about a given requestee (a user).
The core idea is to put a mediating policy infrastructure on top of one or more legacy (profile) data stores, to provide both data interpretation and access control. The motivation for such a solution is based on the following considerations.
(i) Context-dependent response to requests
(ii) Potential richness of requestee preferences
(iii) Centralized personalization and privacy protection when combining data from multiple sources
(iv) Low overhead and fast
(v) User-friendly provisioning
Fig. 1 shows the key elements of our framework. Central to the system is the Privacy-Conscious Personalization (PCP) engine, which interprets the ``static'' user data (data that changes relatively infrequently, in contrast, e.g., with data about a user's location).
Figure 1: Houdini architecture
The PCP engine incorporates three kinds of information in addition to the ``static'' data: (a) the requester context (i.e., who is requesting, what devices they are using, etc.); (b) the requestee context (what is their current situation, as indicated by their presence on the network or instant messaging system, their location, etc.); and (c) the requestee preferences for when her data should be revealed, to whom, and with what filtering or interpretation. More subtly, the preferences may include guidance on the requestee's view of the requester (e.g., is he a business colleague, a friend, a vendor, ...), the requestee's interest in the request and requester, and the requestee's current activity and availability (e.g., at work vs. with family, in high-priority meeting or doing background work, ...). Importantly, the PCP component includes a highly performant rules engine able to interpret policies expressed as Houdini rules.
A key challenging in developing the PCP framework is the choice of a rules language expressive enough to capture user preferences for this domain, while simple enough to support fast, predictable decision response times. The Houdini rules language supports production-style rules, arbitrary variables, and acyclic chaining. The language is strongly-typed and supports complex data types. The language is side-effect free, i.e., the evaluation of a rule only affects variables inside the ruleset. See [3] for more details, as well as for comparison with other rules-based systems (e.g.,ILOG [2]) as well as information about its performance (milliseconds for decisions).
Preference provisioning must be conceptually straight-forward for end users - since, otherwise, the vast majority of users will never bother to provision their preferences, and will lose many of the benefits of such services.
Although intricate rules will be used inside the policy infrastructure, end-users must be able to specify preferences by filling in tables and making simple selections. One technique for achieving this will be to support, for a single service such as restaurant locator, different preferences-provisioning interfaces for different classes of users (e.g., executives, college students, ...). The interfaces will show different choices (e.g., wine preferences to executives but not to high schoolers) and include different defaults (e.g., price range of $30-50 for executives, $5-10 for high schoolers). This will allow reasonable recommendations with minimal preference information for our restaurant locator service example. It is also important to support ``staged'' provisioning, to allow simple provisioning at one time and more refined provisioning later on.
Houdini uses a 3-layer approach (see Fig. 2) to support end-user self-provisioning of preferences: (1) A front end that presents a series of forms through which end-users can fill in blanks/mark check-boxes in order to express their preferences. (2) A family of relational tables and rule templates are associated with the forms. (3) The user preferences are mapped into tuples for relational tables and/or concrete rules constructed from the rule templates.
Figure 2: Self-provisioning via form-based interfaces
The Houdini implementation has been structured around a toolkit approach, where the toolkit contains the core functionality of loading/parsing/executing rulesets, with the application-specific portions (scheduling of events/processes/threads, communication with internal/external components) being layered on top of the toolkit to create the complete application. We have built a provisioning interface along the lines of Fig. 2 using HTML pages for the Selective Reach-Me/Presence service described in our earlier work [1]; see also [3].