So now if we step into the StepStone story, StepStone revolves around a patient named Charlie and how Charlie is leveraging soda and devices in the home to provide a better quality of life and interaction with his health care provider. So a common activity whenever you start to introduce devices into the home or to build on the StepStone story would be to introduce a new device to manage as well as a back-end application that would process this new set of information. Right, sort of that provisioning of a new node in the overall network, if you will, or a new device in the overall system. Right, right. And so for the scenario, we're not going to handle the provisioning side of it, but we'll show how those bundles can be easily started and provide a minimal impact to the application that's already up and running. So the applications, as we view them, we'll start a new one up and it'll automatically register itself with the simulator and it'll automatically register itself with the UI in the back-end. So what we'll do is we'll start with an edge server that will be in the home configured with a blood pressure monitor. And the first step would be to add a new device into that. Well, so first, we'll show the blood pressure monitor. We'll start up the back-end and show how messages flow between the blood pressure monitor and the back-end and how we can view the data. And the next step would be to actually start that new bundle for a weight scale and see how that registers itself with the simulator and also starting the back-end application and registering it with the UI while it's still running. So for the purposes of the demo, we're going to use a device simulator to generate the messages that you would typically receive from a physical device. Okay. So the first step is we'll go into the workspace for the edge and we have a pre-configured configuration
2:03for a simulated device. So we'll go ahead and start that up. If we take a look, so that automatically pops up the device simulator. Right. And we can see that there's a blood pressure application available. So if we click that, we can enter in changes to that and generate a reading that will get sent to the edge server, which is run on OSCI, and call a web service in the back-end. Right. So let's go ahead and start the back-end. So this is like a little Equinox runtime that you started up here? Yes. This is an Equinox runtime in Eclipse, using Eclipse. Right. That makes sense. So in our other workspace, which we have our back-end code, we'll start up the OSCI configuration for the demo bundle. Once that's started, we'll go over to the Seppstone page and refresh that. And we can see that right now, in this web application, there is one blood pressure device that's available. Right. And that's the simulated device that we started up at first, right? Well, so this is the back-end view of data related to that device. So the device actually connected to the edge, and then the edge forwards these readings to the back-end. So there's a database, which we're using Derby on the back-end. Uh-huh. And so basically, once that message comes across, the web service stores the data in the Derby database, and then this provides a presentation of that to you. Oh, okay. Right. So these are several readings that I took earlier today when testing. So if we toggle back over to the device simulator, we'll bump this up to 120, and share reading.
4:13So then we can toggle to our edge, and see that a reading was received, a message was filled, and the LA web service agent sent the message to the back-end. Right. And we can see that the blood pressure and the parameters were what we entered in. So if we go over to the console in the back-end, we can see that we received the web service for this communication, and indeed, it does match the parameters we passed from the edge. Right, right. So what we've seen is one of the edge essentially sending to the central database, if you will, the centralized SOA. Right. Absolutely. So if we click on the blood pressure and restart the page, we'll see that our new reading was stored. Great. So the next thing we would do is now we want to add the new device. And so to simplify the scenario, there are a number of different ways you can handle provisioning or installing new bundles into OSGI. So for this, we just didn't start them. So they're there, and they've been installed, and the assumption is some provisioning tool was used to do that. Right. So if we go back into the edge, we take a look to see what bundles are out there. You can see that the wait simulator, and the wait API, and the wait application. So we'll go ahead and start all four of those up. Okay. 24. So you essentially looked up the, I guess, the IDs of the different bundles that were ready
6:17to be used in the runtime there and just started them up, right? And now I'm guessing we'll be able to see sort of new devices or new things when we go to the web screen there. Well, so we'll see new, so we're on the edge right now. So we'll see new devices in the device simulator. Okay. Right, right. If we go over to the device simulator, we see that we haven't restarted the device simulator, but we had a new wait application register itself. Right, right. So now we can click on the wait device. So before we send data over, we need to make sure that we have a back-end application to handle that. So we'll go back to the back-end, and we can go ahead and take a look here and see that we have a back-end data wait bundle that receives that data and also stores the web page and table to present that information. Right. So instead of starting it from the console here, there's an admin UI instead of stone. If you look at the bundles, the device bundles that are available. So we'll go into that admin server list. And we can see that the back-end data wait bundle is there, and it's resolved, but it's not started. So what we'll do, and we verify that in the console. We'll go ahead and update that guy, and we see that the state has changed to active. We can also verify that it was started in the OSGI run. So we see the data wait has started. Right, right. Now if we go back to the page, we see that a new device application has been registered in the UI. Right, for wait. Yeah. So there's already some data in the Derby database from testing earlier today.
8:17What we'll do is we'll go ahead and send that, a new reading from this newly started device. Send our reading. And similar to before, we can see that the SOAP envelope is created. Right. So a web services agent sends the message, and the parameters are sent across. So if we toggle over, we can see that that message was received through the web services communicator, and the values match. So if we go look at the back end and refresh the page, we'll see that the new reading was passed in. Right. One important thing to note is we didn't stop the runtime or any of the other bundles that were running. We were able to dynamically deploy a new device to both the edge and the back end server. Right. And while this was a pretty simple demonstration, once you start adding in more complex scenarios and remote deployments and provisioning, this becomes a very scalable platform for environments with dynamic applications. Right. Yeah, that was one of the impressions I had of the sort of why you guys were interested in OSGI for it was a large part being the sort of dynamic nature of things, right? That you can't expect people to restart servers or something like that when they deploy something new. And not to mention that there's a whole bunch of different devices or edges that might be out there, and you need more of a system that can manage hot deploying things, if you will, and hot undeploying them, to use an older term for it. But, yeah, I mean, that is a good demonstration of how you can dynamically add things, and, you know, I would hope to, you know, take them away as well. So it seems like, if I understand correctly, so you have various devices that you might have, and they sort of talk to a centralized edge server, if you will, or device or something. And that's kind of like the aggregator of a grouping of devices things. And then that edge server is responsible for talking to the more centralized sort of like SOA server somewhere.
10:17And the other thing is it provides a way to distribute some of that logic down to the edge. So if you combine events between devices, so if you only want to know perhaps something when a temperature reading is above a certain value, you can push that down to the edge, and you're not always talking to the enterprise to pass that information. Right, right, you can sort of add filters down there, if you will, or other things like that, so you don't waste precious resources in the centralized area. Right, right. So it provides a way to distribute that logic. Right, right. Yeah, that sounds good. So as far as the sort of generalized use of it, so you have the SOTA framework, right? And so the SOTA framework is just kind of that idea of the device, the edge server, and the centralized SOA thing, right? And the application that we were looking at that we were seeing was using it for medical device monitoring for sort of in-home things, as we saw in that Charlie video, right? Right. So it sounds like, you know, you don't have to be necessarily in the medical area to need something like this. You just, if there's some problem that you have that involves, you know, those three segments of information flow to and forth, it might be a handy architecture for you. Right. So the StepStone initial reference implementation was built around a healthcare scenario, but the same tooling and the same concepts could cross industry into energy and utilities, home automation, or other areas as well. Right. And do the devices, do you think they actually need to be physical devices, or could they be sort of software things as well? So it depends on the device. Right. Some devices are more low-level, which require using, you know, tooling such as DeviceKit,
12:17whereas other devices have a, I guess, a higher-level API. Oh, right. The thermostats that have simple web services available that you can talk to them over web services. Yeah, yeah. Those can still apply and be integrated into the SODA. But in general, the idea of the SODA thing is that you will have these sort of embedded devices out there. You can just, for example, use it for just computer-to-computer networking. Or, I mean, I guess maybe you could, but the intention is that it's embedded devices you use it for. Yeah, so that's typically the problem space we've been trying to address. So, like, what was the site that people could check the stuff out on? So, if you go to www.eclipse.org forward slash O-H-F forward slash compliance forward slash SODA. And that will provide you links to SAT, DeviceKit, SODA, the StepStone Reference Implementation, and then there are a number of other tooling projects available out there as well. Well, that sounds great. Well, thanks for taking the time to show us this. It was pretty exciting. Okay, great. Well, thank you for your time. Sure thing.