Personalizing the user's experience relies on data about the user. Within the system, this data is represented as so called context objects (simple POJOs) stored in a ContextCollection. The ContextCollection is made available to all components requiring access to context objects.

In a personalized web application, the ContextCollection is filled with all objects relevant for processing the request prior to actually processing the request. Relevant context data may be located in disparate sources (for example, internal CRM systems and external social community sites), thus a simple way to collect and combine this data is required. This is the responsibility of the ContextCollector. The ContextCollector can be invoked by either a Spring Web MVC handler interceptor that is installed in all handler chains requiring context data, or a servlet filter. For this purpose, the implementations PersonalizationHandlerInterceptor and PersonalizationServletFilter are provided. In the following, it is assumed that the ContextCollector is set up as a handler interceptor, if not stated otherwise.

The request flow

The sequence diagram below shows an example of how context objects are retrieved and provided for further manipulation and decision making. In general, for every request all context objects for the active user are loaded. These objects can be used, for example, to select content to be rendered or keep track of the pages the user visits. After request processing is finished, changed context objects are written back to their source. The ContextCollection is then cleared.

Figure 4.3. ContextObject usage

Loading Contexts

For each request, the ContextCollector asks each of its ContextSources to load its context objects and place them into the ContextCollection of the active user.

Each ContextSource retrieves part of the user's context objects. For example, the CookieSource checks if a specific cookie is available in the current request. If it is, the value of the cookie is decoded into a context object and put into the ContextCollection collection. If not, a new and empty context is created.

Using Contexts

Contexts objects can be read and modified throughout request processing. For example, the contexts can be used to determine which content to show to the user or to capture user behavior (see the Section 4.5, “Working With Scoring”).

Storing Contexts

After request processing, each ContextSource gets the chance to persist the contexts objects it is responsible for.

Supplied ContextSources

CoreMedia Adaptive Personalization comes with a set of ContextSources ready to be used in your project. See Section 5.3, “Supplied Context Sources” for a table of all delivered sources.

A ContextSource typically requires a context name and a ContextFactory or ContextCoDec instance to be appropriately configured. The name is used as the key under which the context object is stored in the ContextCollection. Make sure these names are unique to prevent replacing context objects added by other sources. The ContextFactory or ContextCoDec is used by the source to create new context instances and serialize as well as deserialize a context.