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<http://www.sureuniversal.com/> On Thu, Aug 9, 2018 at 2:48 PM, Ondrej Tomcik <ondrej.tom...@kistler.com<mailto: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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9832): https://lists.iotivity.org/g/iotivity-dev/message/9832 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] -=-=-=-=-=-=-=-=-=-=-=-
