Pub/sub
Pub/sub (of ook Publish/Subscribe) verschilt van het request/response paradigma.
Request/response
Bij een request/response wordt een request gedaan voor data. Deze vraag komt aan bij de data owner, die op zoek gaat naar de data die gevraagd werd. Dit zou in praktijk kunnen betekenen dat de data owner een vraag van een gebruiker die door middel van een API tot bij hem kwam, via een query opvraagt in zijn database.
Eens de data owner zijn data gevonden heeft, stuurt hij deze terug. Dit is de response.
Publish/subscribe
In een pub/sub systeem, stuurt de data owner continu zijn meest recente data door naar een broker, waar de data verdeeld wordt naar iedereen die gesubscribed is op deze data. Dit verdeel process gebeurt automatisch.
Zie ook een analogie met een vrachtwagen en magazijn onderaan[1]:
Wanneer kiezen we welk paradigma?
Doorgaans wordt in grotere IoT systemen het pub-sub (broker) paradisgma verkozen. Waarom is dit?
Bij het Request-Response systeem, moet de client (zie voorbeeld hierboven) telkens vragen indien er een aanpassing was van de data[2]:
1: Client request: wat is de sensorwaarde? - Response: 2
2: Client request: wat is de sensorwaarde? - Response: 2
3: Client request: wat is de sensorwaarde? - Response: 2
4: Client request: wat is de sensorwaarde? - Response: 2
5: Client request: wat is de sensorwaarde? - Response: 5.5
In bovenstaand voorbeeld, moeten er bij de eerste 4 request telkens "lege ladingen" teruggestuurd worden naar de client: de data bleef ongewijzigd. Indien men wenst om op zeer hoge frequentie data te monitoren, kan er een probleem onstaan als veel clients dit tegelijkertijd doen: het systeem geraakt overbelast.
In het pub-sub systeem, wordt er enkel data-traffic uitgevoerd indien er effectief een verandering optrad in de data: dan pas sturen de clients hun "vrachtwagen" naar de broker om de nieuwe data binnen te trekken.