Kennisportal
Kennisportal is een kennisplatform met een focus op de brede doelgroep Business en IT.

Social-Graphs. Waar zijn ze goed voor?

Tegenwoordig zie je allerlei soorten sites die verwante en of persoonlijke items tonen op basis van jouw eerder bekeken items of op basis van jouw zoekgedrag. De volgende voorbeelden komen je vast bekend voor:

  • YouTube toont populaire/gerelateerde films naar wat jij als gebruiker op dit moment bekijkt
  • Webshops laten items zien die jij ook leuk vindt, gerelateerd aan jouw geselecteerde item op dat moment
  • Social Media toont mensen die je wellicht kent of berichten/nieuwsitems die je misschien leuk vindt

En zo kunnen we doorgaan met voorbeelden, maar ik denk dat de redenering duidelijk is. Wat deze sites gebruiken is een implementatie van een social graph protocol. Deze blog gaat over de basiskennis van het graph protocol (en Microsoft- en Office Graph). Echter, voor degenen die geen idee hebben wat dit is, hierbij een korte definitie van het graph protocol:

“Een graph protocol maakt het mogelijk dat een site, pagina, gebruiker of elk ander object op een website/webpagina onderdeel wordt van een (social) graph, door machine learning, om een relatie tussen beide te tonen of in vergelijking met gebruikersinteractie.”

Om een algemeen idee te geven van enkele implementaties van het graph protocol:

  • Open Graph (Graph-protocol voor Facebook)
  • Google Pregel GraphX (Google-graph voor framework verwerking)
  • Azure AD Graph (Data uit Azure Active Directory)
  • Microsoft Graph (Data uit Office 365-componenten)
  • Office Graph (Data uit Office 365-componenten)
  • Yammer Enterprise Graph (Data uit Yammer)

Met betrekking tot het bovenstaande is misschien een beter voorbeeld om te vermelden dat Facebook is gestart met een social graph, namelijk Open Graph. Vervolgens implementeerde Microsoft een social graph in Yammer op basis van Open Graph: de Yammer Enterprise Graph. Na de implementatie in Yammer heeft Microsoft een sociale grafiek gemaakt via hun volledige Office 365-collectie, Office Graph.

In deze blog wordt ingegaan op Office-, Microsoft- en Azure AD Graph, omdat deze drie allemaal verbonden zijn met elkaar en elkaar aanvullen/substitueren (en ze zijn allemaal van Microsoft). Misschien heb je opgemerkt in de bovenstaande lijst dat het lijkt alsof Microsoft- en Office Graph hetzelfde doen. Verder in de blog wordt echter uitgelegd waar hier het verschil in zit.

Microsoft Graph versus Office Graph

Laten we beginnen met het bespreken van Microsoft- en Office Graph en hoe deze zijn verbonden met de Office-365-componenten.

Microsoft Graph versus Office Graph

Zoals het bovenstaande diagram aangeeft hebben beide graphs betrekking op alle Office 365-componenten via hun respectievelijke API. Deze API kan je ook rechtstreeks aanroepen aangezien ze allemaal ook een individuele ‘endpoint’ hebben.

Op het eerste gezicht lijken Microsoft- en Office Graph dezelfde gegevens te kunnen leveren, wat niet helemaal het geval is. Het grote verschil tussen beiden is dat Microsoft Graph meer functioneert zoals een rest-service voor toegang tot gegevens, terwijl Office Graph gebaseerd is op een social graph en voornamelijk onderlinge relaties in kaart brengt.

Office Graph

Office Graph is een framework dat inzichten biedt op basis van de gebruikers- identiteit en activiteit en -activity. Deze inzichten en relevante informatie worden gevonden met behulp van machine learning technieken. Office Graph is niet ontworpen voor gebruikerstoegang tot de data op zich, maar is ontworpen om alle inzichten en gegevens van Office 365-componenten beschikbaar te maken via andere applicaties. Denk bijvoorbeeld aan Delve als een dergelijke toepassing, die allerlei gebruikersinformatie en slimme inzichten geeft over het gebruik van Office 365. Dat wil zeggen: het tonen van populaire documenten, het geven van statistieken over reactietijden of simpelweg het tonen van personen waarmee je het contact bent verloren. In de Office Store staan tientallen andere applicaties die ook Office Graph implementeren.

De techniek achter Office Graph krijgt hier wat verdere uitleg, omdat het is geïmplementeerd als een social graph en niet zoals elke andere API. In een social graph zijn er drie belangrijke objecten; Actor (source node), Edge en Object (target node).

Actor, Edge en Object

De Actor is de bron van waaruit een relatie (Edge) tot stand wordt gebracht met de target (Object). De Edge is de belangrijkste factor hier, want deze bepaalt welke relatie wordt gelegd, wat het belang van de relatie is en wat voor type relatie het betreft. Houd in gedachte dat de target ook een Actor kan zijn, met een andere Egde aan een ander Object. Voorafgaande kan hieronder worden gezien in een weergave van een willekeurige social graph. Je kan ook variëren in hoe je het gewicht weergeeft, door de afstand tussen de clusters te vergroten of clusters te schalen om het relatieve gewicht ten opzichte van elkaar weer te geven.

Nodes

Microsoft Graph

In tegenstelling tot Office Graph is Microsoft Graph ontworpen om CRUD[1]-bewerkingen uit te voeren op de afzonderlijke Office 365-componenten via hun respectieve API en maakt deze beschikbaar via één enkel eindpunt (of hoe Microsoft het beschrijft: ‘One endpoint to rule them all’).

Het grote voordeel is dat je slechts één API hoeft aan te roepen en dat Microsoft Graph intern alle onderliggende authenticaties/verzoeken verwerkt. Het nadeel is echter dat het wat moeilijker is om te implementeren in een applicatie of te gebruiken voor ontwikkeling dan een losse API. De reden hiervoor is dat de verificatie voor Microsoft Graph, zoals je in het diagram kunt zien, is gebaseerd op het OAuth 2.0-protocol. Terwijl de respectieve API van de componenten het gebruik van basisverificatie toestaat (gebruikersnaam en wachtwoord in de HTTP-header).

Dit betekent dat je twee dingen moet overwegen; Of je nu meerdere componenten wilt gebruiken of slechts een of twee componenten en of dat debeveiliging cruciaal is. Als je slechts één onderdeel nodig hebt en beveiliging niet van groot belang is, kan je de overweging maken om alleen de component API te gebruiken in plaats van Microsoft Graph.

Als je besluit om Microsoft Graph te gebruiken kan je het endpoint benaderen op https://graph.microsoft.com/v1.0. Als je de  bekijkt, merk je al snel dat om toegang tot gegevens te krijgen de hoofdfunctionaliteit is en niet om inzichten en relaties te verkrijgen. Er zijn sommige functies zoals ‘krijg items trending om me heen’, maar dit soort functies zijn erg schaars. Dus het implementeert wel een stukje zoals een social graph, maar je zou kunnen zeggen dat het veel meer een API is dan een social graph.

Microsoft Graph versus Azure AD Graph

Aangezien je de Azure AD (Active Directory) Graph misschien niet kent, weet je wellicht ook niet waarvoor je deze gebruikt. Zoals de naam al aangeeft, het hoofddoel van de Azure AD Graph wordt gebruikt voor CRUD-bewerkingen met betrekking tot een Azure Active Directory. Denk bijvoorbeeld aan functionaliteiten zoals gebruikers-, groeps-, directory- en beleidsactiviteiten.

 Microsoft Graph versus Azure AD Graph

Hierboven zie je een grafische weergave van hoe je Azure AD kunt gebruiken in combinatie met een Office 365-component. In dit voorbeeld kan SharePoint Online het endpoint van Azure AD gebruiken om een gebruiker te verifiëren en autoriseren. Ook kan je de reeds gevulde lokale AD gebruiken voor Office 365-componenten. Dit kan worden bereikt met een Directory Synchronization server, waarmee de gegevens automatisch gesynchroniseerd worden met Azure AD.

Maar je kunt je afvragen wat dit te maken heeft met Microsoft Graph? Microsoft Graph heeft ook de mogelijkheid om acties uit te voeren op gebruikers, groepen en directory’s. Ze substitueren dus elkaars functionaliteit maar ze hebben ook nog wat complementaire functionaliteiten. Voor nu althans, omdat Microsoft beweert dat Microsoft Graph in de nabije toekomst alle Azure AD Graph-functionaliteit zal gaan implementeren.

Een aantal tussen beiden zijn (momenteel en met betrekking tot Microsoft Graph):

  • Ondersteunt meer directory-functies
  • Gebrek aan de mogelijkheid om OData $select query’s te maken
  • Ander applicatiebeheer (toewijzing aan gebruikers/groepen en OAuth-machtigingen)
  • Verschillende entiteitstypes
  • Registreren van Directoryschema-uitbreidingen
  • Groeperen (Batching)
  • Partner admin (met betrekking tot resellers en syndicators)

Gebaseerd op wat je wilt bereiken of welke functionaliteit je nodig hebt, kan je dus beslissen of je Microsoft Graph of Azure AD Graph wilt gebruiken.

De endpoint voor Azure AD Graph vind je op https://graph.windows.net/{tenant-identifier}. Wanneer je de endpoint functionaliteit bekijkt, merk je al snel dat er helemaal geen functionaliteit gebaseerd is op open graph.

Samenvatting

In dit artikel wordt de basisfunctionaliteit van Microsoft-, Azure AD- en Office Graph beschreven en waar mogelijk vergeleken. De belangrijkste conclusie is dat het drie autonome graphs zijn met (verschillende) functionaliteiten en doelen.

Microsoft- en Office Graph gebruiken dezelfde gegevens, maar zijn niet hetzelfde. De eerste is bedoeld om toegang te krijgen tot gegevens van – en CRUD-bewerkingen uit te voeren op Office 365-componenten via een enkel endpoint. Office Graph daarentegen is een implementatie van een social graph protocol en biedt inzicht in gebruikersinteractie en Office 365-gebruik door machine learning.

Terwijl het doel van Azure AD Graph voornamelijk het beheren van de Azure Active Directory is, is er nog steeds enige overlap met betrekking tot Microsoft Graph. Microsoft zal echter het verschil met betrekking tot Microsoft Graph gelijk gaan trekken.

Een ander belangrijk aandachtspunt is dat terwijl Microsoft- en Azure AD Graph beide de naam ‘Graph’ dragen, ze beiden meer een API zijn dan een (social) graph, zoals Office Graph.