WEBVTT 00:06.100 --> 00:12.310 So guys, now let us try to understand another example regarding how notification chain works. 00:12.790 --> 00:18.550 Let us suppose that you have a software system and that software system is divided into different different 00:18.550 --> 00:21.160 modules or independent components. 00:21.190 --> 00:28.770 One of the component is publisher because it is in charge of some data source, right? 00:28.780 --> 00:35.050 So for illustration purpose, let us say that publisher is a module of a software component, which 00:35.050 --> 00:39.430 is the owner of some data source, let us say routing table, for example. 00:39.430 --> 00:40.150 Right. 00:40.770 --> 00:47.670 So any component which is in charge of some data source and in that data, some other component shows 00:47.670 --> 00:53.250 interest, then the component which is owning that data source is called a publisher. 00:53.700 --> 00:59.790 Whereas the rest of the components of the software systems, which shows interest in the data source 00:59.790 --> 01:02.640 owned by the publisher are called subscribers. 01:02.970 --> 01:09.330 So let us say that our software system has more number of independent components which are running independently. 01:09.330 --> 01:13.880 Let us say application one, application to application three and application four. 01:13.890 --> 01:14.610 Right. 01:15.340 --> 01:21.880 When I say components, you can assume that these subscribers and publishers are independent threads 01:21.880 --> 01:24.580 running in the context of the same process. 01:25.460 --> 01:28.370 Though, to implement a publisher subscriber model. 01:28.370 --> 01:29.990 It is not a constraint. 01:30.020 --> 01:35.810 The different components could be different software systems running in the context of different processes 01:35.810 --> 01:41.630 or running on different machines all together for the sake of simplicity to understand notification 01:41.630 --> 01:42.290 chains. 01:42.290 --> 01:48.140 We have taken an example in which the publisher and the subscribers are different components of the 01:48.140 --> 01:49.550 same software system. 01:49.550 --> 01:50.270 Right? 01:51.140 --> 01:58.850 Now let us say that the application one is interested in notification from the publisher related to 01:58.850 --> 01:59.510 the entry. 01:59.510 --> 02:03.260 122 .1.1.1 slash 32. 02:03.260 --> 02:04.050 Right. 02:04.070 --> 02:11.270 So in order to express interest the application, one will send subscription request to the publisher. 02:11.300 --> 02:12.170 Right? 02:12.680 --> 02:19.550 In this subscription request, the subscriber application one will convey the publisher that Hey publisher, 02:19.550 --> 02:23.810 I'm interested in the notification related to this entry. 02:24.170 --> 02:32.180 And whenever there is a change that is update, delete or modification of any type in this entry, please 02:32.180 --> 02:35.000 notify me using this function FA1. 02:35.000 --> 02:35.870 Right. 02:36.140 --> 02:43.010 So the moment the publisher get this subscription request, it will create an entry in its notification 02:43.010 --> 02:43.640 chain. 02:44.240 --> 02:51.930 In this entry, it will store the key in which the subscriber is interested, and it will also save 02:51.930 --> 02:54.210 the callback function of the subscriber. 02:54.210 --> 02:54.930 Right. 02:55.710 --> 03:02.010 Similarly, let us suppose that the application two also sends subscription request to the publisher 03:02.010 --> 03:09.990 and the application two is interested in the entry for 122.1 .1.2 32. 03:09.990 --> 03:10.800 Right. 03:11.160 --> 03:12.400 There is a typo here. 03:12.420 --> 03:17.760 Let us suppose that in this routing table this is entry number three and this is entry number four, 03:17.760 --> 03:18.480 right? 03:21.140 --> 03:29.270 So now let us suppose that Application three has expressed its interest in the entry number 122 .1.1.3. 03:29.300 --> 03:29.930 Right. 03:29.930 --> 03:36.560 And therefore it also do the registration with the publisher by sending the subscription request. 03:36.560 --> 03:37.370 Right? 03:40.700 --> 03:43.460 Application for is somewhat different. 03:43.490 --> 03:47.440 It is interested in all the entries of this routing table. 03:47.450 --> 03:54.050 That is, whenever there is a change or modification of any type in any entry of the routing table, 03:54.050 --> 03:58.850 subscriber application for is interested in notification, right? 03:58.850 --> 04:02.930 So it will again send a subscription message to the publisher. 04:02.930 --> 04:10.220 But in this subscription message, the application for will not specify any key right? 04:10.220 --> 04:14.030 Not specifying any key works as a wild card. 04:14.570 --> 04:20.690 So throughout this process you can see that subscribers have registered their callbacks with the publishers 04:20.720 --> 04:23.780 against the entries which they are interested in. 04:23.780 --> 04:24.500 Right? 04:24.500 --> 04:30.680 So this link list is called notification chain, which is maintained by the publisher, right? 04:30.710 --> 04:37.160 The publisher can add or delete nodes from this notification chain depending on the subscription or 04:37.160 --> 04:40.230 unsubscription request received from the subscribers. 04:42.400 --> 04:49.030 When publisher updates the entry in its routing table, the publisher simply iterates over the notification 04:49.030 --> 04:53.970 chain and invoke callbacks of subscribers matching the entry. 04:53.980 --> 04:54.670 Right? 04:54.670 --> 05:01.030 So, for example, let us suppose that publisher executes some logic due to which the publisher updates 05:01.030 --> 05:02.370 its routing table entry. 05:02.410 --> 05:09.220 Say 122 .1.1.3 and instead of 101, let us say it starts at zero. 05:09.790 --> 05:14.800 It simply means that this particular entry has been updated by publisher. 05:14.800 --> 05:21.490 So whenever the publisher updates any entry in its data source, it walks over its notification chain 05:21.490 --> 05:24.790 and find the matching entry, which is updated. 05:24.790 --> 05:25.570 Right. 05:25.570 --> 05:32.260 And now Publisher finds that there is a callback registered, so it simply invokes this callback functions 05:32.260 --> 05:39.760 and in this callback function it will pass the information regarding which entry is updated along with 05:39.760 --> 05:42.040 the rest of the information of the entry. 05:42.750 --> 05:43.470 Right. 05:44.490 --> 05:50.640 So it simply means that publisher will tell the application that, hey, application three, the entry 05:50.670 --> 05:59.630 number 122.1 .1.3 has been updated and the new updated values is the remaining attributes of this entry. 05:59.640 --> 06:00.420 Right? 06:00.720 --> 06:06.720 Similarly, in this example, the publisher also sees that there is no key at all in this notification 06:06.720 --> 06:07.710 chain entry. 06:07.740 --> 06:08.350 Right? 06:08.370 --> 06:13.230 It simply means that it do not have to worry anything about this key. 06:13.230 --> 06:19.140 And it doesn't matter that which entry in the routing table is updated, the publisher simply invoke 06:19.140 --> 06:25.800 the callback for four, meaning that it is notifying the application four about the update in its routing 06:25.830 --> 06:26.400 table. 06:26.400 --> 06:27.120 Right. 06:27.540 --> 06:32.760 So subscribers who have registered without key will be notified for all the updates. 06:32.760 --> 06:38.190 All updates means whenever any entry in the routing table changes the. 06:38.760 --> 06:44.070 The subscriber who have registered with the publisher with the wild card key will be notified. 06:44.070 --> 06:44.700 Right. 06:47.530 --> 06:54.490 So this is one example regarding how notification chain works, and this is a very simplified example. 06:54.760 --> 07:01.960 So now you should understand that how notification chains grow or shrink depending on subscription or 07:01.960 --> 07:05.340 unsubscription requests coming from the subscribers. 07:05.350 --> 07:11.530 So notification chain is a kind of chain or link list or a database which is maintained by the publisher, 07:11.530 --> 07:12.220 right? 07:12.220 --> 07:17.950 And for each data source, the publisher maintains a separate notification chain, right? 07:18.430 --> 07:24.520 If a publisher has multiple data sources, the publisher will maintain absolutely separate notification 07:24.520 --> 07:26.890 chains for each of its data sources. 07:26.890 --> 07:27.520 Right.