One of the most important aspects of personal clouds, as we envision them, is their ability to federate. Without federation, personal clouds are as interesting as a computer without a network connection. Federation is a fancy word to describe what comes natural to people: operating in a collective manner according to conventions or standards. In human terms, we call this being social. Neighborhoods, cities, clubs, and lots of other groups are federations of a sort.

In computer terms, federation usually refers to the interoperability of something: a network, a chat system, and so on. The Internet, for example, is a federation of networks that interoperate. One of the trends that seems inexorably at play in computer systems is the move from centralized solutions to distributed ones. We find it easier to build centralized systems first, but eventually we figure out how to decentralize them because that leads to not only better scaling and performance, but also greatly increased flexibility. Federation is the key idea that allows loose collections of decentralized systems to work in concert in pursuit of a common goal.

The programming model we discussed earlier is specifically designed to allow federation so that multiple personal clouds can participate in a collective solution to a problem. The magic that makes this possible is already built into the PEN: events, salience, and channels.

Personal event networks federate by subscribing to events from other PENs. Event channels play a key role in event subscription. When one PEN wants to subscribe to the events of another, it supplies an event channel and any other information that the publisher needs to complete the subscription. KRL has built-in features for sending events to subscribers.

An Example: On Call Teaching Assistants

To illustrate the use of event subscription for federation between personal clouds, consider the following problem. I have two teaching assistants (TAs) for a class I teach at BYU. (There are some large classes that have dozens.) The TAs are usually in the building, but not sitting at the TA cubicle. They are happy to be "on call" and answer student questions almost any time if they don't have to sit in the cubicle away from their usual desk. The solution is an application that allows students to text a single "class number" and request a meeting. Normally we might build that application as a stand-alone Web site, but personal clouds provide an opportunity to "think differently" about the solution.

The following diagram shows how we approach the problem. The system is made up of multiple, federated personal clouds. There is one for the class and one for each TA or instructor who wants to participate.

The PEN in the class' personal cloud¹ contains a ruleset called the "On-Call TA Dispatcher" (dispatcher). As its name implies, this ruleset listens for incoming text messages and dispatches the requests to any subscribing TAs by raising a schedule:inquiry event. The TA clouds each have an "On Call" ruleset that is listening for that event.

The scenario is straightforward:

1. The student sends a text to the class phone number requesting an appointment.
2. The dispatcher sees the event caused by the incoming text message and dispatches the schedule:inquiry event to any subscribing PENs.
3. The oncall ruleset in the TA's PEN, responds to schedule:inquiry events by checking the TA's calendar.
4. If the calendar indicates that the TA is currently on call, then the oncall ruleset raises a notification:status event inside the PEN.
5. The notify ruleset sees the notification:status event and sends a text to the TA indicating a student wants to meet.
6. If the TA is able to meet, she responds to the text.

Note that more than one TA might see the on-call request. Any TA who receives a notification and is available to meet merely responds to the text and the student is notified that help is on the way. If no TA is on call, the dispatcher ruleset tells the student that no one is on call right now.

Event Subscription

Let's explore the details of event subscription by looking at a little KRL. Subscribing to events requires that the subscriber (i.e. the TAs) provide an event channel and other information to the event publisher (i.e. the Class). Event channels have an identifier, called the event channel identifier (ECI) that uniquely identifies the channel. The ECI is sufficient information to send an event from one PEN to another. To keep things simple, imagine the ECI and other information are stored in an array like so:

teaching_assistants = 
   [{"name":"Phil",
     "phone":"801362XXXX",
     "eci":"072a3730-2e9a-012f-d2da-00163e411455",
     "calendar":"https://www.google.com/calendar/..."
    },
    {"name":"John",
     "phone":"801602XXXX",
     "eci":"fc435280-2b60-012f-cfeb-00163e411455",
     "calendar":"https://www.google.com/calendar/..."
    }
    ...
   ];

Given this subscriber list, the rule that dispatches events to the teaching assistants is fairly easy to write. The rule is selected when the PEN sees a schedule:inquiry event:

rule dispatch {
  select when schedule inquiry
    foreach teaching_assistants setting (ta)
      event:send(ta,"schedule","inquiry")
          with attrs = {"from" : event:attr("From"),
                        "message": event:attr("Body"),
                        "code": math:random(99);
                        };
      }
      always {
        raise explicit event subscribers_notified on final
      }
}

Notice that this rule loops over the teaching_assistants subscriber list using a foreach and uses the action event:send() to send the schedule:inquiry event to each TA in the list. When the rule is complete (note the on final guard condition in the postlude), it raises an event called subscribers_notified so that any final processing can be done. The event:send() action raises events to subscribing networks in parallel.

Federation through Subscription

The preceding example shows how multiple personal clouds, running an event-based cloud OS can federate to accomplish a simple task for their owners. The class has a personal cloud that is running rulesets to manage the class' business. The TAs each have clouds running rulesets to manage their business. These networks are owned and managed by different people. And yet, through subscription, the student finds an on-call TA to help them with their problem. Federation has allowed these various clouds to cooperate in solving a problem.

There are a few things to point out:

• None of the rulesets know about the others. They are connected by through salience in a loosely coupled manner.
• The behavior of the rulesets isn't specialized to an individual. The rulesets are general purpose. All the personal data is retrieved from the personal data manager installed in the personal cloud.
• The subscriptions are made using event channels that create a one-to-one link between networks. This protects against SPAM and other communications abuses. The relationship can be revoked as easily as it is created without affecting other relationships. The subscriber (TA) controls what events it sees by managing event channels.
• Any network that wants to see the schedule:inquiry events from the class personal event network must subscribe to them. The publisher (Class) controls who sees the events by managing the subscription list.
• With the exception of the oncall ruleset, the TAs would likely have different rulesets installed in their PEN. For example, each TA could have a different notify ruleset installed as long as they each understood the notification event.

Federation arises from the properties of the programming model that we discussed earlier. Most important among these are event channels and salience. Event channels provide a way for PENs to communicate securely and privately. Salience ensures that events are routed to the rules that need to see them regardless of their source.

Through event subscription, personal clouds can cooperate to automate interactions that in other circumstances would necessarily be driven by the actions of their users. The On-Call TA use case supplies several examples:

• The TAs don't have to check anything to see if students are waiting. The system merely notifies them when they are.
• Personal data like the TA's own calendar modifies the overall behavior of the system.
• TAs can subscribe or unsubscribe as they start work or leave employment without the students or other TAs needing to change anything.
• TAs are notified in the manner they choose, based on their personal preferences and the rulesets they've activated.
• The TAs are represented in the interaction by a system they control. This may not be important in this scenario, but could matter a great deal in other scenarios, like those involving commerce.

Federation turns personal clouds into automated assistants. A personal cloud becomes a personal valet that thinks about you—your needs, your quirks, your life. Rather than having to get involved in all the gritty details of how things get done, you're in a position of just making go—no go decisions, like the TAs in the example above. As a new category of personal cloud apps are written to take advantage of federated personal clouds, this new form of cloud-based personal assistant will soon become as indispensable as a smart phone is today.

---

¹ Don't let the term personal throw you off. We use personal to refer to the idea that each event network is being operated on behalf of a specific entity—in this case, the class. I think personal event network sounds much better than entity-specific event network.