+1 for the overall idea. I think, when it comes to device to server communication, we can follow two approaches based on whether it is a custom jax-rs based device type or a config based device type (if we are supporting those). For the former case, we can assume that the device type's jax-rs service has to implement relevant logic to process device updates and publish necessary data to DAS. For config based device types, we have to provide a generic endpoint to receive device updates, validate them against device schema and publish events to DAS.
Regarding the audit table, should we maintain such table within the product, or should we publish all auditing related events to DAS? On Tue, May 16, 2017 at 12:16 PM, Maninda Edirisooriya <mani...@wso2.com> wrote: > Hi, > > As this is the heart beat monitoring scenario I don't think location data > or other device status related information should be there with the > periodic message. As there are many devices in the system and because the > time interval of the heart beat signal should be minimized as possible (to > detect the failed devices as soon an possible) the message should be light > in weight as possible. Theoretically an empty single UDP packet is enough > to do the heart beating signaling. If we can implement some UDP event > receiver may be this heart beating can be used throughout the platform for > the purpose of monitoring server heartbeat. WDYT? > > Thanks. > > > > *Maninda Edirisooriya* > Senior Software Engineer > > *WSO2, Inc.*lean.enterprise.middleware. > > *Blog* : http://maninda.blogspot.com/ > *E-mail* : mani...@wso2.com > *Skype* : @manindae > *Twitter* : @maninda > > On Mon, May 8, 2017 at 12:35 PM, Ruwan Yatawara <ruw...@wso2.com> wrote: > >> Hi Everyone, >> >> I am working on $subject as part of the effort in trying to provide dig >> down analytics for devices. >> >> The resulting graph would look something like the following (Please >> disregard portion reading connected-unterminated), with the help of [1] and >> will give an would indicate whether the device in question was able to get >> back to IoT Server in a timely manner at the expected monitoring frequency >> specified. >> [image: Inline image 1] >> *Source: [2]* >> >> Whilst attempting this I noticed that we do not have an auditing >> mechanism in place to record important activities, as yet. If you take this >> flow, for example, the monitoring frequency is something configurable and >> will change from time to time. We need to know at which point the >> transition was made. >> >> Therefore I propose, that we come up with a central audit table to record >> system activities, like updates to platform configurations, in a central >> table. Each activity can have a logging code, and we can purge these >> records from time to time, based on data growth. >> >> I also propose that we, take out the option for users to enable/disable >> data publishing from the agent side, and make it implicit. The agent by >> default makes a call to the server to send device information, instead of >> making the device make another call to DAS to provide location information, >> we can derive the location information at the server side from the device >> information payload and push it to DAS. >> >> Please feel free to weigh in your thoughts. >> >> >> [1] - https://bl.ocks.org/mbostock/4063318 >> [2] - https://www.digi.com/resources/documentation/digidocs/ >> 90001150/reference/r_rep_device_connections.htm >> >> >> Thanks and Regards, >> >> Ruwan Yatawara >> >> Associate Technical Lead, >> WSO2 Inc. >> >> email : ruw...@wso2.com >> mobile : +94 77 9110413 >> blog : http://ruwansrants.blogspot.com/ >> >> https://500px.com/ruwan_ace >> https://medium.com/@ruwanyatawara >> >> www: :http://wso2.com >> >> > -- > You received this message because you are subscribed to the Google Groups > "WSO2 IoT Team Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to iot-group+unsubscr...@wso2.com. > For more options, visit https://groups.google.com/a/wso2.com/d/optout. >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
