Introduction to the MUSIC Context System - Tutorial 6

Continuing in the next section of the "OSGi and MUSIC Context" series of tutorials, we here introduce the basics of the MUSIC Context System. The MUSIC Context System [1] is an OSGi component which provides automated management for multiple, dynamically-available context providers and consumers. As an OSGi component, the MUSIC Context System exports two services:

• IContextAccess
• IContextManagement

The former provides an API for accessing context information both synchronously and asynchronously. Furthermore, it allows for the use of the Context Query Language (CQL) [2]. The latter, provides more advanced access to the internals of the context management component, allowing external components, such as the Distributed Context Management System to function (make context remotely available in this case).

To install the MUSIC Context System, you first need to build or download the corresponding JAR file. You can build the latest version from source code (using Maven), or you can download a recent version of it from here: "music-context-0.2.1.0-SNAPSHOT.jar".

Once you build (or download) and install this JAR file, you can notice a few installed services, as illustrated in the following console output:

osgi> install file:music-context-0.2.1.0-SNAPSHOT.jar
Bundle id is 7

osgi> start 7

osgi> ss

Framework is launched.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.2.R34x_v20080826-1230
1       ACTIVE      org.eclipse.equinox.ds_1.0.0.v20080427-0830
2       ACTIVE      org.eclipse.equinox.util_1.0.0.v20080414
3       ACTIVE      org.eclipse.osgi.services_3.1.200.v20071203
4       ACTIVE      RunnableProvider_1.0.0
5       ACTIVE      RunnableConsumer_1.0.0
6       ACTIVE      CLI_Client_1.0.0
7       ACTIVE      music-context_0.2.1.0-SNAPSHOT

osgi> services (objectClass=org.istmusic*)
{org.istmusic.mw.context.cache.IContextCacheService}={component.name=context.cache, component.id=5, service.id=28}
Registered by bundle: file:music-context-0.2.1.0-SNAPSHOT.jar [7]
Bundles using service:
file:music-context-0.2.1.0-SNAPSHOT.jar [7]
{org.istmusic.mw.context.cqp.IContextQueryService}={component.name=context.query, component.id=4, service.id=29}
Registered by bundle: file:music-context-0.2.1.0-SNAPSHOT.jar [7]
Bundles using service:
file:music-context-0.2.1.0-SNAPSHOT.jar [7]
{org.istmusic.mw.context.IContextAccess, org.istmusic.mw.context.IContextManagement}={component.name=context.manager, component.id=3, service.id=30}
Registered by bundle: file:music-context-0.2.1.0-SNAPSHOT.jar [7]
No bundles using service.

As you can see here, there are three sub-components defined in the context bundle:

• Context Cache
• Context Query [processor]
• Context Manager

This architecture is also depicted in the following figure:
As shown in this figure, the "Context Manager" is the central component, utilizing the services offered by the other two components. For instance, the "Context Cache" component, provides a simple storage service, that is used by both the "Context Manager" and the "Context Query Processor". The latter, offers the CQL service, which is used by the "Context Manager" whenever it needs to handle CQL queries.

From an client-side point-of-view though, what matters are the two services offered by the "Context Manager" and which were mentioned already. In the following, we show their exact definition and briefly explain what they are used for.

The IContextAccess service

As mentioned already, the context access service is used for allowing external components, deployed in OSGi, to leverage the capabilities of the context system. The interface (API) of this service is shown in the following listing:

/**
* This is the main point of interaction with the context service (and the
* context system in general). Any context client requiring to interact
* with the context system can achieve it through this interface.
*/
public interface IContextAccess
{
/**
 * Provides synchronous access to the specified context data. It returns
 * the last context element stored only.
 */
public IContextElement queryContextLastElement(IEntity entity, IScope scope)
        throws ContextException;

/**
 * Provides synchronous access to the specified context data.
 */
public IContextDataset queryContext(IEntity entity, IScope scope)
        throws ContextException;

/**
 * Provides asynchronous access to the specified context data.
 */
public void queryContext(IEntity entity, IScope scope, IContextListener listener)
        throws ContextException;

/**
 * Provides synchronous access to the context data.
 */
public IContextDataset queryContext(final IContextQuery query)
        throws ContextException;

/**
 * Provides asynchronous access to the context data. The provided context
 * listener is asynchronously contacted once the results of the given
 * IContextQuery are available.
 */
public void queryContext(IContextQuery query, IContextListener listener)
        throws ContextException;

/**
 * Provides asynchronous access to the context data. By providing a the
 * IEntity and the IScope of the required data, the provided
 * IContextListener reference is asynchronously notified of context
 * changes in the specified entity-scope pair automatically.
 */
public void addContextListener(IEntity entity, IScope scope, IContextListener listener)
        throws ContextException;

/**
 * Provides asynchronous access to the context data. This method is used
 * along with the #addContextListener(IEntity, IScope, IContextListener) method
 * in order to allow unregistering of a context client from a particular
 * entity-scope pair.
 */
public void removeContextListener(IEntity entity, IScope scope, IContextListener listener)
        throws ContextException;

/**
 * Provides the ability to the context clients to specify which context
 * types they require (i.e. because an application was launched, requiring
 * additional context types). The identification of a type is done in terms
 * of a doublet comprising of an IEntity and a IScope.
 *
 * When registered as needed, a context type is monitored by the
 * context system be means of activating an appropriate context sensor (if
 * available). When multiple sensors are available providing the same
 * context type, then the system might decide to activate only one or more
 * of them, based on the resource availability and the quality of the
 * available sensors.
 *
 * Registering the same (Entity,Scope) doublet twice does not throw an
 * exception and does not result in any noticeable change.
 */
public void addNeededContextType(IEntity entity, IScope scope, Object requestor)
        throws ContextException;

/**
 * Provides the ability to the context clients to specify which context
 * types they do not need anymore (i.e. because an application was shut
 * down). The identification of a type is done in terms of a doublet
 * comprising of an IEntity and a IScope.
 *
 * Unregistering a non existing (Entity,Scope) doublet does not throw an
 * exception and does not result in any noticeable change.
 */
public void removeNeededContextType(IEntity entity, IScope scope, Object requestor)
        throws ContextException;
}

As defined in the comments of the corresponding methods, these methods are used to either explicitly request a specific context type, or register a query (formulated in the CQL language [2]) for processing. As the context system needs to be aware of the runtime context needs of the individual applications, it either registers the applications' needs implicitly or it allows for them to express them explicitly (using the last two methods). More details about the functioning of each method can be found in the Javadocs of the "IContextAccess.java" interface.

The IContextManagement service

Unlike context access, the context management service aims for other components which aim at improving or complementing the functionality of the context system. For instance, a component can be used to distribute the local context information across a predefined set of nodes. Another example is of a component which connects to the context system in order to access and visualize relevant information.

In order to enable this kind of functionality, the context management service provides methods which allow to access information about the needed and the provided context types of the node. The interface of the service is illustrated here:

/**
* Provides management-level access concerning the internal state of the MUSIC
* context system.
*/
public interface IContextManagement
{
  /**
   * Returns a set of EntityScopePairs which correspond to the currently
   * required context types.
   */
  public Set getCurrentRequiredContextTypes();

  /**
   * Registers for asynchronous notification of when a new required context
   * type (i.e. EntityScopePair) is added or removed.
   */
  public void addRequiredContextTypesListener(IContextManagementListener listener);

  /**
   * Un-registers from asynchronous notification of when a new required
   * context type (i.e. EntityScopePair) is added or removed.
   */
  public void removeRequiredContextTypesListener(IContextManagementListener listener);

  /**
   * Returns a Set of EntityScopePairs which correspond to the currently provided
   * context types.
   */
  public Set getCurrentProvidedContextTypes();

  /**
   * Registers for asynchronous notification of when a new provided context
   * type (i.e. EntityScopePair) is added or removed.
   */
  public void addProvidedContextTypesListener(IContextManagementListener listener);

  /**
   * Un-registers from asynchronous notification of when a new provided
   * context type (i.e. EntityScopePair) is added or removed.
   */
  public void removeProvidedContextTypesListener(IContextManagementListener listener);

  /**
   * Returns a set of EntityScopePairs which correspond to the currently
   * required context types from remote sources.
   */
  public Set getCurrentRequiredRemoteContextTypes();

  /**
   * Registers for asynchronous notification of when a new required remote
   * context type (i.e. EntityScopePair) is added or removed.
   */
  public void addRequiredRemoteContextTypesListener(IContextManagementListener listener);

  /**
   * Un-registers from asynchronous notification of when a new provided
   * context type (i.e. EntityScopePair) is added or removed.
   */
  public void removeRequiredRemoteContextTypesListener(IContextManagementListener listener);

  /**
   * Allows external entities (such as the "Distributed Context Manager") to
   * raise ContextChangedEvents.
   */
  public void contextChanged(ContextChangedEvent event);
}

The methods of this service allow direct (synchronous) and indirect (asynchronous) access to three context types:

• Required Context Types: Those context types that are needed by the currently deployed (i.e., started) applications
  
• Provided Context Types: Those context types that are provided by the currently deployed plug-ins (context sensors and context reasoners)
  
• Required Remote Context Types: Those context types that are needed locally (by the deployed applications) but which are not offered by any of the locally deployed plug-ins

The last method allows for other components (besides the context system and the plug-ins) to generate context events.

In the following tutorials, we will describe the architecture of the context plug-ins, and how a component-based application can be designed to exploit context information from the context system.

[1]. Nearchos Paspallis, Romain Rouvoy, Paolo Barone, George A. Papadopoulos, Frank Eliassen, Alessandro Mamelli, A Pluggable and Reconfigurable Architecture for a Context-aware Enabling Middleware System, 10th International Symposium on Distributed Objects, Middleware, and Applications (DOA'08), Monterrey, Mexico, Nov 10 - 12, 2008, Springer Verlag LNCS 5331, pp. 553-570

[2]. Roland Reichle, Michael Wagner, Mohammad Ullah Khan, Kurt Geihs, Massimo Valla, Cristina Fra, Nearchos Paspallis, George A. Papadopoulos, A Context Query Language for Pervasive Computing Environments, 5th IEEE Workshop on Context Modeling and Reasoning (CoMoRea) in conjunction with the 6th IEEE International Conference on Pervasive Computing and Communication (PerCom), Hong Kong, 17–21 March 2008, IEEE Computer Society Press, pp. 434-440