(Classic) Building Personal Cloud OS Services

Cloud OS services typically manage data for the user and have an event interface in addition to a module interface. Phil Windley originally introduced the service pattern last January in a post on using Foursquare with KRL.

This pattern has been referred to in the past as a “manager” or even a “module” but neither of those terms capture the importance of this pattern. The pattern is properly described as a Cloud OS service. Referring to it as a module leads to confusion since modules don’t normally need to be installed in the user's personal cloud to be used, but a service does. The fact that a service is also a module is an implementation detail.

The component labeled the “personal data manager” (PDM) in Foursquare post is a perfect, small example of a PCOS service. The PDM service uses a combination of rules, functions, and entity variables to create an effective service for storing simple elements of personal data. Beyond simple storage, however, the service acts as a full-fledged actor in personal cloud because it listens for and emits relevant events. We review the design of the prototype PDM service below.  

PCOS Service Principles

To understand the pattern more fully, here are a few principles that guide service development and operation:

A PCOS service responds to and emits a defined set of events. These events can be thought of as a service protocol or API. Defining a service requires that both kinds of events and their respective attributes be specified. This allows other services and applications in the PCOS to take advantage of the service.

Services should avoid being leaves in the event hierarchy.This means that they should emit events to indicate any state changes that other services and applications might wish to be made aware of.

A PCOS service may also define a set of functions for interrogating the service. Services cannot modify their visible state in response to such an interrogation. Interrogation functions are made available to other applications and services via a module interface.

PCOS services usually maintain entity-specific state. In the case of the PDM service, the entity-specific state consists of personal data. The data stored by the service is dependent on the particular purpose of the service and is only made available through functional and event-based interactions as defined in the two preceding paragraphs. Services implemented with KRL persistent variables get entity-specific state without any effort by the programmer. If a service uses an external data store, the developer must take care to ensure that the service provides entity-specific state.

The key to understanding how a PCOS service is implemented in KRL is to realize that KRL rulesets create entity-specific closures over the persistent data declared within. Thus the rules and functions declared in the ruleset implementing the service automatically have access to a bundle of state for whichever user the service is running for.

PDM as a PCOS Service

Let’s review the design of the PDM service to see how this works. The PDM service has a rule, add_location_item, that is used to add a new location waypoint for the user. Theadd_location_item rule listens for the pds:new_location_available event.

rule add_location_item {
  select when pds new_location_available
  always {
    set ent:location{event:attr("key")} 
        event:attr("value");
    log "Saw " + event:attr("key") + " data";
    raise pds event new_location_item_added 
      with key = event:attr("key");
  }
}

Whenever such an event is raised, the rule does three things:

1. Stores the location variable in an entity variable.
2. Writes a log message
3. Raises a new event, pds:new_location_item_added

Most services will raise events as well as respond to them as shown here because that ensures they are actors in the PCOS. Other services or applications can respond to changes in the service state by listening for those events. For example, in this case, a reminder service might be listening for the pds:new_location_item_added event so that it can remind the user when they enter or leave a particular geofence. Notice that the reminder service isn’t responsible for processing the location data, just listening for a particular event.

Later, this item can be used by other applications through the get_location() function:

meta {
  name "Personal Data Manager"
  provides get_location
}

global { 
  get_location = function (k) {
    ent:location{k};
  };
}

A function, made available through the module interface (notice the provides pragma in the meta section) provides a convenient way for other applications and services to interrogate the data in the PDM.