Let's talk about Foglets as one exemplar for a Geo distributed programming system. And so the idea is that in Foglets, you want to automatically discover a computation elements that are close to where you are, and you want to elastically deploy the resources and collocate applications. Like I said IoT platform could be used for multiple applications in the same time. You want to collocate application components on different fog nodes, and you want to have a hierarchy of computations elements. You have to provide ability for communication and a storage capabilities. And so you need a proprietary apis for that. So that's something that you have to do. And the idea is simply this that if you have a logical application hierarchy and you know the computational requirements of the different components of an application. This is the application pipeline that goes all the way from capturing an image, to object detection, to target tracking, to detecting faces for instance. And then recognizing faces and maybe doing say spatial temporal analysis to figure out the track of an individual through a space or a vehicle through the space and so on. This is sort of the application pipeline, then you can figure out for each one of these components. What is the quality of service requirement? And you can decide where exactly want to place it, whether you want to place it close to the edge, or somewhere in the middle, or all the way in the cloud. So these are things that you want to do and that's sort of the idea behind the programming infrastructure called Foglets. That is trying to take the applications requirement and map it into where it should be placed in the computational hierarchy. Because of the continuum of computational elements going from the edge of the network to the cloud and you want to exploit all of that in providing the quality of service guarantees that you want. And you also have to worry about resource adaptation because as I said, computational elements, the sensor sources themselves could be moving and/or they could be bursty needs depending on what is going on in several different applications. So you have to provide for resource adaptation. So these are all the tenets of the Foglets programming model and you can think of it as a platform, as a service programming model for the internet of things. And the design goals are simplicity, scalability, and context awareness. Meaning, I want to be aware of where I am in the network hierarchy, I want to be aware of where I am in terms of location, geolocation. And what are the resources available at a geolocation and and what are the capabilities that are available in the in the fog nodes? These are all things that you want to provide in the Foglets programming module. And it of course assumes that there is a fog computing infrastructure that is, just like you have infrastructure as a service in the cloud, similarly if you have infrastructure as a service available at the edges, then I can take advantage of that and implementing or executing this programming model. The application model in Foglets is that, I mentioned already that this idea of a dag is very powerful, data flow graph that represents your computations very powerful. And I even showed that even in this example that I showed you earlier, basically what you have is a computational graph here, right? In terms of what's going on with the data that is coming in. You can think of a foglet application as consisting of distributed processes a in a data flow graph. And there is a hierarchy in terms of the processing needs of every node in the computation graph as well as quality of service requirements. And each process may cover a specific geographical region for instance. So if you're thinking about monitoring traffic in an area, then all the vehicles in a particular geographic area, maybe covered by fog resources that are close to that and similarly fog resources that are close to this area may be covering the vehicles in those region. So those may be the tenets of the application model, so you can think of it being two axes, one is the location axis and the other is the network hierarchy axis. And if you go up in the network hierarchy axis, you have more computational resources, but you also have to incur more latency penalty. And so that is something that you have to take into account in thinking about mapping applications in the fog lifts programming model. So the foglet API for app development allows an application programmer to say well, here is an application which is the task flow graph, certain quality of service properties associated with that. And what Foglets will do it as a way of figuring out where in the computational hierarchy it wants to place the different application components commensurate with the quality of service requirements. And when a sensor starts generating data, then it is going to communicate with the parent that is near it, the fog resource that is near it. And if the the sensor source moves to a different location, then it starts communicating with a different parent. And all of that is automatic in the API, in the Foglets programming model. The app developer just has to give the quality of service requirements and all of these details of mapping it initially, as well as migrating the application components is part of the programming infrastructure of Foglets. And what I'm going to do is I'm going to give you a little bit of insight into what goes on under the covers in Foglets without getting into a lot of detail. But if you're interested, I'll point you to the papers as well as point you to Enrique who is done a lot of this work. So one of the things that that needs to happen is a sensor source has to discover and deploy an application component to process the sensor data that it is generating. And so in order to do that, in the Foglets infrastructure, there is a discovery server and you can query the discovery server and get the set of fog nodes that are near where your sensor sources. And once you have that, then you can actually ask all of these guys, do you want to host my application component? And this is not something that the application is doing but the runtime infrastructure is doing, saying that there's a sensor source and I have an application component that needs to be put somewhere. And it is querying this nearby fog notes and then and then you're going to get a response back. And maybe one guy says yes, I can take you on. And if it says it can take it on, then we're going to put that into this particular fog node as a chosen node and from the registry server, it can get the application component that corresponds to processing this guy. And that's going to be located in to this because dynamically, you have to discover what is the application component that you need in order to run the sensor processing? And that is something that you can get from the registry. And once you have that, then you're ready to do business, you can run the application for processing the sensor. And it says I can accept your request and from here on this guy is going to be doing communication with the chosen parent now as a result of this protocol. And there are communication primitives that are available for sending information up and down in the API of Foglets. So the Foglets API for communication is sending information up and down as well as laterally between the fog nodes that said that you can do. So this is the way we can laterally send information between the fog nodes as well. And what happens is that similar to the mapreduce programming model where you have these empty functions, map and reduce which the application is developed. In a similar manner Foglets gives you a whole bunch of handlers, what should happen when a message comes to a parent node? What should happen when a message comes to a child? And these are the handlers that the programmer, the application programmer has to fill in and that'll be used by the Foglets runtime infrastructure on a need basis as the application executes. So those are the communication API that's there and similarly there is API available in the Foglets for context awareness. And for instance, you can query your location where you are from the infrastructure and which level of the fog infrastructure you're working at. And what is the capacity of the particular fog node that you're working on? And what is the resources that are available at that at that fog node? So these are the things that are available for context awareness. Another thing that is needed in this environment is that you're continuously generating events that are related to your particular application. You need a persistent event store that you can keep these events in and Foglets has a spatiotemporal object store. And every object in the object store has a key, a location, and time and an interpreted data that goes with it. So you can get input on this object store and depending on what is going on in the application, the elements of the objects will be moved around. I'll talk about that in a minute. Of course capability is very important. Let's say that there's a whole bunch of sensors that are communicating with a particular parent and becomes overloaded. Then you want to offload some of this sensory processing, that again issomething that is automatically managed in the infrastructure. So for instance, I could decide that some of these sensor processing should be moved to PN node and that is transparent to the application. So in other words load balancing based on geo-location is automatically taken care of in the Infrastructure. And when you do that, you also have to move some of the application context. I mentioned that there is a spatiotemporal store at every fog node. And if some of the sensor processing has been moved to this guy, then it might need some of the context to be moved from the previous fog node to this node. All of that is being taken care of under the covers in the programming model. When you do this migration, you want to join and at that point what you're doing is you are trying to find out what may be an appropriate node that I can join. And I might get an except from one guy or sometimes, when I try to to join a particular node, it might say well, there are too many things going on at my node already, I'm over the capacity. And you might get a reject, and if you get a reject, then you may have to find some other fog node that is nearby that you can connect to. So all of this is being done under the cover by the runtime system. Similarly, one of the things that that you may want to do is with mobile sensors. You may want to migrate application components proactively because you recognize that this vehicle is moving in this direction. And therefore from latency point of view, sensor processing is better done by a fog node that is closer to where it is. So you want to do this migration either because of for load balancing reasons or because of the mobility of the sensor or the application components and all of that is is taken care of by the runtime infrastructure. So it may be associated with a particular parent but it's finding out what may be potential neighbors that it can talk to by talking to the registry server. And based on that, it choose the best neighbor to migrate to and once it decides that, it can migrate to that. And after that, all of the computation is going to be with this. Originally it was talking to this guy, but now it is migrated over here based on the mobility of the sensor. And so at that point, it can change the parent to say that from now on, you're my parent, I'm going to be communicating with you. And by the way, this guy knows who the previous parent used to be, and therefore if there is some context information that has to be fetched from that, it knows where to get it from. So all of this is built into the infrastructure. So in summary, the Foglets framework, it's trying to alleviate the pain point for domain experts and mobile sensing application could be vehicle tracking or self-driving cars and so on. And what it does is it does quality sensitive placement of the application components and also deals with multi-tenancy of the application components on the fog nodes. And it automatically worries about discovering and deploying the application components and migrating the application components on a need basis.
