Ressourcenmodell

Jegliche Art von Daten stellt das Live Framework als Ressourcen zur Verfügung, welche von LOE über eindeutige URIs angeboten werden. Eine Ressource wird dabei durch einfache Entities (und typisierte Properties auf diesen) oder Collections von Entities dargestellt, mit welchen kein Verhalten assoziiert ist und die via HTTP abgerufen werden können. Dieses Entity-/Collection-basierte Ressourcenmodell hat den Vorteil, dass es komplett agnostisch gegenüber jedem Kommunikationsprotokoll und jeder Art von Repräsentation ist. Neben den eigentlichen Mesh-Daten stehen noch weitere Informationen als Ressourcen bereit, z.B. das eigene Live-Profil (Profiles), Profile von Kontakten (Contacts), Informationen über Mesh-Geräte (Devices) und mehr, worauf an dieser Stelle nicht näher eingegangen werden soll.

Als Daten angebotene Ressourcen bilden eine kleine Klassenhierarchie im Mesh. Auf höchster Ebene stehen dabei Mesh-Objekte (Typ: MeshObject). Diese bilden einen grundlegenden Container für Daten im Mesh, wobei mehrere Typen von Mesh-Objekten unterschieden werden können. Beispielsweise wird jede Applikationsinstanz als eigenständiges Mesh-Objekt gespeichert. Das Mesh-Objekt stellt dabei den Gesamtkontext der jeweiligen Anwendung dar, in dem alle Daten der Applikation gespeichert werden. Auch Dateiordner im Mesh werden auf höchster Ebene als Mesh-Objekt gespeichert, so dass Daten solcher Dateiordner grundsätzlich gleich behandelt werden können wie Daten einer Mesh-Applikation. Darüber hinaus bleibt es Entwicklern überlassen, eigene Typen von Mesh-Objekten zu erstellen und damit das vorgegebene Ressourcenmodell zu erweitern. Ein Mesh-Objekt ist derzeit auch die fundamentale Einheit hinsichtlich Synchronisation und Datenaustausch. So ist es nicht möglich, nur Teile der Daten eines Mesh-Objekts (also z.B. einer Anwendung) mit anderen auszutauschen. Bezüglich einer Applikation wie MeshPhotoShare bedeutet dies: Entweder wird die gesamte Applikationsinstanz mit all ihren Daten für andere Nutzer frei gegeben oder gar nichts.

Silverlight-Applikationen, die direkt im Mesh eingebunden sind, haben darüber hinaus die Einschränkung, dass sie standardmäßig nur auf ihr eigenes Mesh-Objekt zugreifen können (wie gesagt: Die Applikation ist das Mesh-Objekt), jedoch nicht auf andere Mesh-Objekte (was bei meshbasierten .NET-Anwendungen auf Clientseite hingegen möglich ist). Dies ist eine starke Limitierung und erlaubt beispielsweise MeshPhotoShare derzeit nicht, frei gegebene Fotos anderer Nutzer einzubinden (diese würden in einem separaten Mesh-Objekt liegen). Bei den Entwicklern des Live Frameworks wird diskutiert, ob eine weniger restriktive Regelung angebracht ist und welche Use Cases unterstützt werden sollen. An dieser Stelle wird sicher noch einiges getan werden …

In einem Mesh-Objekt selbst ist eine Collection von Daten-Feeds (Typ: DataFeed) enthalten. Auf dieser feedbasierten Ressource können CRUD-Operationen ausgeführt werden, weiterhin beziehen sich Änderungsmitteilungen (change notifications) von Daten in einem Feed immer auf den Feed selbst. Für viele Anwendungen wird es nicht nötig sein, mehrere Daten-Feeds zu speichern. Andere Anwendungen wiederum werden diese Abstraktion zu nutzen wissen, im Kontext von Fotos könnten beispielsweise mehrere Foto-Alben verwaltet werden, und ein Foto-Album könnte einem Daten-Feed entsprechen. Mehrere Daten-Feeds sind daher sinnvoll, wenn einzelne Daten (z.B. Fotos) gruppiert und gemeinsam angesprochen werden sollen. In MeshPhotoShare besteht nur die Notwendigkeit für einen Daten-Feed, um Fotos darin ungeordnet ablegen zu können. Dieser Feed muss beim allerersten Start der Applikationsinstanz angelegt werden, wobei dieser Prozess in Listing 1 verdeutlicht wird.

Über den zuvor geladenen MeshApplicationService hat man direkten Zugriff auf die DataFeeds der Applikation (des Mesh-Objekts). Zunächst wird überprüft, ob die Feed-Collection leer ist. Ist dies der Fall, so wird ein neuer Feed mit dem Titel „MeshPhotoFeed“ angelegt und mittels Add() der DataFeeds-Collection hinzugefügt. Schlussendlich muss auf dem MeshApplicationService die Methode Update() aufgerufen werden, um die Änderungen im Mesh bekannt zu machen.

1. private MeshApplicationService _meshApp;
2. private DataFeed _photoFeed;
4. // legt einen neuen Daten-Feed im Mesh an, wenn noch keiner vorhanden ist
5. private void InitMeshFeed()
6. {
7. if(_meshApp.DataFeeds.Entries.Count() == 0)
8. {
9. _photoFeed = new DataFeed("MeshPhotoFeed");
10. _meshApp.DataFeeds.Add(ref _photoFeed);
12. _meshApp.Update();
13. }
14. }

Listing 1

Ein Daten-Feed selbst enthält dann die eigentlichen Dateneinträge (Typ: DataEntry). Diese stellen die kleinste Einheit zur Speicherung von Daten dar und beinhalten Mechanismen, um applikationsspezifische Daten darin abzulegen. Hierauf wird der folgende Abschnitt im Zusammenhang mit MeshPhotoShare eingehen.