Thanks, Ondrej. Just to clarify what I meant by the "server state". My question was not about the connectivity, but rather the actual state of the resources. Say, the "OCF Server" is a Light device. To know if the light is ON - I can query via GET.
But I may also need to: 1. React on the server side on the change of the state (light ON / OFF) - without having an OCF client connected. 2. Keep the history of the state changes (for analytics or whatever) The question is how I can solve those requirements. Is there a productized interface to receive cross-account notifications on the resource state changes? Regards Max. On Thu, Aug 9, 2018 at 4:15 PM, Ondrej Tomcik <ondrej.tom...@kistler.com> wrote: > Hello Max, > > Thanks for your message. > > > > Please see my inline comments. > > > > > > > > *Ondrej Tomcik **:: **KISTLER **:: **measure, analyze, inovate* > > > > *From:* Max Kholmyansky [mailto:m...@sureuniversal.com] > *Sent:* Thursday, August 9, 2018 2:58 PM > *To:* Tomcik Ondrej > *Cc:* iotivity-dev@lists.iotivity.org; Scott King < > scott.k...@fkabrands.com> (scott.k...@fkabrands.com); Max Kholmyansky ( > m...@sureuniversal.com); Gregg Reynolds (d...@mobileink.com); Kralik Jozef; > Rafaj Peter > *Subject:* Re: [dev] OCF Native Cloud 2.0 > > > > Hi Ondrej, > > > > Thanks for sharing the design. > > > > It seems like the design document is technology agnostic: it does not > mention any specific technology used for the implementation. Yet you > mention that the implementation is in progress. Does it mean that the > technology stack was already chosen? Can you share this information? > > Yes, this document is still technology agnostic. Soon we will introduce > selected technology stack. Or let’s say roadmap for supported technologies. > > Implementation is in the golang, but technologies like message broker / db > / event store are being evaluated. But the goal is to not force users to > use certain db or broker. It should be generic and user should be able to > use what he prefers. Or use cloud native service. > > > > > > I have 2 areas in the document I would like to understand better. > > > > *1. OCF CoAP Gateway* > > > > If my understanding is right, this component is in charge of handling the > TCP connectivity with the connecting clients and servers, while all the > logic is "forwarded" to other components, using commands and events. Is it > right? > > Yes. This allows you to introduce a new gateway, for example HTTP one, and > guarantee interoperability within the Cloud across multiple different > devices. > > > > It will be helpful to get an overall picture of the "other" components. > > Other components, or let’s talk about implementation: ResourceService, > AuthorizationService (sample will be provided but should be user specific), > ResourceShadowService and ResourceDirectoryService (these two might be just > one service). > > > > > > You mention that the "Gateway" is stateful by nature, due to the TCP > connection. What about the other components? Can they be stateless, so the > state will be managed in a Data Store? This may be helpful from the scaling > perspective. > > ResourceService is stateless, might be probably deployed also as lambda > function (evaluating). AuthorizationService is user specific, > ResourceShadow and ResourceDirectory are the read side, they might use just > in-mem db, during start filled from event-store. > > > > *2. Resource Shadow* > > > > If I got it right, the architecture assumes that the cloud keeps the > up-to-date state of the server resources, by permanently observing those > resources, even if no client is connected. Is it right? > > I assume that by client you meant OCF Client. Yes, you’re right. > > > > Does it mean that a "query" (GET request) by a client can be answered by > the cloud, without need to query the actual server? > > Yes > > > > Will there be a mechanism to sore the history of the server state? What > will be needed to develop such a functionality? > > You mean online / offline? It will be stored, complete history is stored. > Each Gateway, in this implementation OCF CoAP Gateway has to issue the > command to ResourceAggregate (ResourcesService) to set the device online / > offline. As it is aggregate, you have whole history what has happened. Each > change to resource is persisted. Including device status – online/offline. > > > > > > > > The last point... If I got it right, the only way to communicate is via > TCP connection using TLS. This may be good enough for servers like smart > home appliances, and clients like mobile apps on smartphones. But there is > also a case of cloud-to-cloud integration: say, voice commands to be issues > by a 3rd party cloud. In the cloud-to-cloud case, I doubt it's a good idea > to require the overhead of a TCP connection per requesting user. Is there > any solution for cloud to cloud scenario in the current design? > > Of course, cloud to cloud, or let’s say you have cloud deployment, where > one component is the OCF Native Cloud and another one is your set of > product services. You are not communicating with the OCF Native Cloud > through the CoAP over TCP. You’re issuing directly GRPC requests and > including the oauth token. Please check sample usage : > https://wiki.iotivity.org/coapnativecloud#sample_usage > > > > > > > > > > Best regards > > > > Max. > > > > > > > > > -- > > Max Kholmyansky > > Software Architect - SURE Universal Ltd. > > http://www.sureuniversal.com > > > > > > > > > > > > > > > > > > > > On Thu, Aug 9, 2018 at 2:48 PM, Ondrej Tomcik <ondrej.tom...@kistler.com> > wrote: > > Dear IoTivity devs, > > > > Please be informed that the new Cloud 2.0 design concept is alive: > https://wiki.iotivity.org/coapnativecloud > > Your comments are warmly welcome. > > Implementation is in progress. > > > > BR > > > > *Ondrej Tomcik **:: **KISTLER **:: **measure, analyze, inovate* > > > > > > > > -- > > Max Kholmyansky > > Software Architect - SURE Universal Ltd. > > http://www.sureuniversal.com > > > -- Max Kholmyansky Software Architect - SURE Universal Ltd. http://www.sureuniversal.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9835): https://lists.iotivity.org/g/iotivity-dev/message/9835 Mute This Topic: https://lists.iotivity.org/mt/24238274/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
