Perspectives Technical Documentation

In Figure 4 we have a context instance C, a role instance 1 and a role instance R. Now 1, having a perspective on a user role type 2, adds an instance of 2 to the context( n)ote how we jump opportunistically between the type- and instance level). Obviously, the instance of 2, being new in the context, has no prior information about it. So the burden falls upon 1 to send all deltas necessary to recreate C and R locally, to 2. In the figure we’ve shaded the structural parts that are to be sent to 2.

Figure 4. The yellow circle represents a peer added to the context C by user 1. Both peers have a perspective on role R.

This works by handling one by one all perspectives the new peer has on the context. Handling here means: run the queries that provide the objects of the perspectives while jotting down all context and role instances that are passed by the query evaluator. For example: for 2 to arrive at role instance R, the evaluator passes C. In a similar vein all property values are collected. For each of these structural elements, the original deltas that created them are sent to 2.

Consider a webshop in Perspectives. The visitor, deciding to browse the virtual shelves, creates a shopping basket (a context instance). It will contain himself, as (prospective) client, so he can see inside it, but otherwise it will be empty. He will then proceed to add articles to it in some way (presumably by dragging roles representing those articles over it).

Finally, he decides to really buy these articles. Only now will he reveal his identity to the shop, by dragging a representation of a sales person onto the basket.

This situation is covered by the example in the previous paragraph, where user role type 1 is the client, R represents the articles and 2 the sales person.

Let’s increase the complexity of the case by involving the webshop’s financial controller. This role must have access to all shopping baskets to retrieve the financial information from it. We assume the sales person and the controller are roles in the webshop context.

Now, the controller does not need to be an enumerated role in the basket context. We can easily compute this role once the sales person has been added to the basket: we just follow the path from the sales person role in the basket to its filler as employee in the shop, to the shop context itself and then to the controller role.

Obviously, the PDR of the client should disclose some information to the financial controller. But how? It has no access to the web shop context. See Figure 5.

Figure 5. The webshop. The sales person is added to the basket © containing the articles ®. The Controller is a calculated role in the basket (represented by the dotted line). NOTE: this model is not final: see Figure 7.

As a matter of fact, this situation can be handled by the same mechanism of passing on we’ve defined above. In short: the Client is aware of the Controller role and includes it in the deltas it sends to the Sales Person. Thus, the Sales person (or rather the PDR for the peer that ultimately fills Employee) passes these deltas on to the Controller. The Employee has all information to compute the Controller.

But there is a catch we’ve glossed over. How does Client know he cannot address Controller directly, and how does he know he can reach Controller through Sales person?

This would happen if the user graph were like Figure 6. But Sales person does not have a perspective on Controller; Employee does.

Figure 6. The user graph we would like to derive from Figure 5.

It takes some reasoning to derive Figure 6 from Figure 5. We start with the observation that Controller is a calculated role in the basket ©. We then should note that the user graph represents connections between PDR installations. This is because there is a one-to-one correspondence between User roles of PerspectivesSystem and a PDR – intentionally, PerspectivesSystem represents the PDR. So because Sales person is filled by Employee (and Employee is filled, in the end, by User) we may include the perspective of Employee on Controller in our user graph.

We will not implement this reasoning. Instead, we restrict ourselves to perspectives on roles in the context. Hence, we require a perspective of Sales person on Controller (as a calculated role of Basket). See Figure 7.

Figure 7. An improved version of Figure 5. The perspective of Sales person to Controller has been added (and we’ve omitted the perspective of Employee on Controller for cosmetic reasons; there may be reasons to have that perspective that fall outside this example).

It is straightforward to derive the user graph in Figure 6 from this model. Should the model lack this perspective, the system should warn that synchronization will be incomplete.

What if the new peer has a perspective on something the user who adds him cannot see? Think about a soccer club with multiple youth teams. A parent enlists her daughter and the clubs’ administrator assigns her to a team. The teams’ trainer then provides her with the training schedule etc. We can model this as shown in Figure 8.

Figure 8. A soccer team © with external role (E) and a Schedule role. The Administrator adds the Player (yellow) to the team and sends the blue items to her. The trainer receives the new player and sends the schedule (green) to her.

The situation is like in Figure 3, but with an extra user role (Trainer) and an extra thing role (Schedule). As the Trainer has a perspective on Player, Administrator sends deltas to Trainer so he can update his local database with the new Player.

However, we can see in the picture that the Administrator cannot send the Schedule to the new Player: he has no perspective on it.

Instead, his PDR makes use of the connection of Trainer to Player. But, unlike in Figure 2, he cannot send a delta along that path – because Administrator has no information on the Schedule instance. However, his PDR can reason about Schedule instances (using the model). So instead of sending a concrete delta with details, he sends a type level delta to the Trainer. This type level delta contains both the Schedule role type and the path to Player from Trainer. We call this type of delta an InformNewPeerDelta.

Trainer, upon receiving a InformNewPeerDelta, verifies if he can find instances of Schedule in his database. He can and therefore creates a delta on the instance level and sends it to Player.

Several caveats here:

In the above, we’ve dealt with perspectives as if they only concern roles. However, usually a perspective pertains to properties as well. So instead of merely asking whether the new peer sees the same role, we should ask about properties, too.

Here it is useful to introduce the concept of the difference between two perspectives. Let’s conceive of a perspective as the combination of a role type and a set of properties: <R, props>.

We define P1 minus P2 as follows:

Let’s start by subtracting from a perspective of the new peer (let’s call that P1). For each perspective P2 of the user that adds the new peer (the initiator), we subtract it from P1. If the difference is P1, it is of no use to us. If the (property set of the) difference is empty, we can inform the new peer completely from the PDR of the initiator. If the difference is a non-empty set of properties, we’ll have to enlist the help of other peers.

Remember we can only make use of peers who are on a path between the initiator and the new peer!

For such a peer, we evaluate one by one his perspectives. From such a perspective we subtract the difference we obtained above. If the result is empty, we’re done. Otherwise we’ll have to take the remaining difference and try another peer, until we’re done.

The above algorithm ends with either a set of peers, each combined with a partial perspective to send to the new peer, or with the conclusion that synchronization cannot be complete, it does not give the best result in the sense that we’ve enlisted the help of more peers than needed. This can be fixed easily but is computationally more intensive.

But there is another issue. Consider this situation: the initiator can send the object of a perspective and some properties, but not all. Another peer need only send the rest of the properties. How do we do that?

We’d need to make clear exactly what the peer doesn’t need to send. That is not trivial. Properties may reside anywhere on the role telescope. The initiator may have sent part of that telescope, while the peer needs to send a further part, that bears the required properties (and those fillers require their contexts too!).

I see no easy way to communicate, to an enlisted peer, what he doesn’t need to send. So as it stands, we accept that enlisting a peer to complete a perspective for a new peer involves overhead for both that peer and the new peer (who’ll receive some role- and context information more than once (this is not a problem in the sense that handling a delta is an idempotent operation; there is no difference to the state if it is added more than once)).

Finally, a really complicated case that combines aspects of what we’ve seen above. With a stretch we extend our soccer example by including a Trainer Assistant, who is in the know of the Schedule, while Trainer himself has no access to it (unlikely, but just for the sake of the example assume it is so). Moreover, Administrator has no direct perspective on Trainer Assistant.

This requires Administrator to send an InformNewPeerDelta along a user path to Trainer Assistant. The path is via Trainer. See Figure 9.

Figure 9. An extension of the situation given in Figure 8. The Trainer now has an Assistant. Trainer cannot see the Schedule, but Assistant can.

Administrator must instruct Assistant with an InformNewPeerDelta, so includes the path from himself to Assistant in it: (Trainer, Assistant) (see Figure 10). The new Player instance is included as the final destination. And the Assistant perspective on the Schedule is included, so Assistant knows what to send to Player. We assume the Assistant perspective on Schedule covers that of Player.

Figure 10. The user role graph for the model in Figure 9.