Re: [Architecture] Proposed Device Operations Flow of CDM
All, We've been working on this architecture for a long time now. Lets have a comprehensive review on Friday. I've already sent out the invite. On Mon, Nov 24, 2014 at 7:00 AM, Shan s...@wso2.com wrote: Hi all, Just to add some points . That depends on whether an agent is involved or not 3 criteria : 1 agent based 2 agent less 3 hybrid ( this is also based on feature ) If u look at Android It is 1 iOS 3 Windows 2 ( there is another option ) Some iot device its 1 Any Cpe device its 2 since for example routers use tr069 Things we need to consider 1 enrollment , de-enrollment (ui or non ui based , active or passive , ownership) 2 DM 3 transport 4 device stream Also the dmml - a new markup language to define the device feature which can be defined at the client agent or at the server based on os , platform , version . This can be based on some combination as well. The first one is based on the device itself the use case for that is an arduino which has some sensors connected . Sent from my iPhone On Nov 22, 2014, at 10:41 PM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi Sameera, I am not exactly getting the point. It should be because I am not exactly aware of the actual use case of Windows and iOS. Do you mean that they are using different transport (or connectivity) protocols? Regards. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Sat, Nov 22, 2014 at 9:29 PM, Sameera Perera samee...@wso2.com wrote: Hi Dilan On Windows and iOS we need to use the specific protocols and rely on the OS to execute the command. This is why we have to use this approach. (Sent from a mobile device) On 22 Nov 2014 19:29, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi All, Why do we need to construct a Platform-specific-payload at the server level? Cannot we just send the Platform-independent-payload to the device agent and invoke the corresponding feature operation at the client side? I might not be right because I am not exactly aware of all the use-cases. Appreciate if some valid use-cases can be provided on this regard. Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Tue, Nov 18, 2014 at 8:32 AM, Harshan Liyanage hars...@wso2.com wrote: Hi Dilan, Yes. you are correct. Thanks, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Tue, Nov 18, 2014 at 7:20 AM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi Harshan, This is with reference to the two merging options that you have mentioned in your previous reply to the thread. As I understood, with the 1st Option: You suggest to [1] convert platform-independent-payload to platform-specific-payload, save it and when another request comes in, [2] convert the platform-specific-payload back into its platform-independent-form and merge it with the platform-independent-payload for the new request and [3] convert that back to a platform-specific-payload. (Please correct me if I am wrong) So with this option, you suggest not to save a platform-independent-payload for the pending requests and deal with it only at run-time. As I understood, with the 2nd Option: You suggest to [1] Keep the platform-independent-payload saved along with its platform-specific-payload and when ever another request comes in, [2] Get the existing platform-independent-payload and merge it with new platform-independent-payload of the incoming request, save it and [3] Convert that to a new platform-specific-payload and overwrite the existing platform-specific-payload with the new one. (Please correct me if I am wrong) Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Mon, Nov 17, 2014 at 8:16 AM, Harshan Liyanage hars...@wso2.com wrote: Hi, *Platform-specific payload *is the actual payload which will be delivered to the device when the device contacts the server for pending-operations. *Platform-independent *form is used to construct the *Platform-specific payload * communicate device operations internally within CDM. For example when an user sends a device operation using CDM web-console, *platform-independent *message will be sent from the console - CDM API - CDM Core - Device-platform bundle. Then the *device-platform bundle *will use it to construct the *platform-specific payload.* But there might be situation where some device operation payloads might not delivered to the device when another operation for that device comes-in. IMO in such cases its not good to have many pending *platform-specific payloads *for a single device. If we are to
Re: [Architecture] Proposed Device Operations Flow of CDM
Hi All, Why do we need to construct a Platform-specific-payload at the server level? Cannot we just send the Platform-independent-payload to the device agent and invoke the corresponding feature operation at the client side? I might not be right because I am not exactly aware of all the use-cases. Appreciate if some valid use-cases can be provided on this regard. Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Tue, Nov 18, 2014 at 8:32 AM, Harshan Liyanage hars...@wso2.com wrote: Hi Dilan, Yes. you are correct. Thanks, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Tue, Nov 18, 2014 at 7:20 AM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi Harshan, This is with reference to the two merging options that you have mentioned in your previous reply to the thread. As I understood, with the 1st Option: You suggest to [1] convert platform-independent-payload to platform-specific-payload, save it and when another request comes in, [2] convert the platform-specific-payload back into its platform-independent-form and merge it with the platform-independent-payload for the new request and [3] convert that back to a platform-specific-payload. (Please correct me if I am wrong) So with this option, you suggest not to save a platform-independent-payload for the pending requests and deal with it only at run-time. As I understood, with the 2nd Option: You suggest to [1] Keep the platform-independent-payload saved along with its platform-specific-payload and when ever another request comes in, [2] Get the existing platform-independent-payload and merge it with new platform-independent-payload of the incoming request, save it and [3] Convert that to a new platform-specific-payload and overwrite the existing platform-specific-payload with the new one. (Please correct me if I am wrong) Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Mon, Nov 17, 2014 at 8:16 AM, Harshan Liyanage hars...@wso2.com wrote: Hi, *Platform-specific payload *is the actual payload which will be delivered to the device when the device contacts the server for pending-operations. *Platform-independent *form is used to construct the *Platform-specific payload * communicate device operations internally within CDM. For example when an user sends a device operation using CDM web-console, *platform-independent *message will be sent from the console - CDM API - CDM Core - Device-platform bundle. Then the *device-platform bundle *will use it to construct the *platform-specific payload.* But there might be situation where some device operation payloads might not delivered to the device when another operation for that device comes-in. IMO in such cases its not good to have many pending *platform-specific payloads *for a single device. If we are to deliver multiple payloads that might introduce an additional overhead in network. In such situations what I suggest is to merge the new payload with the existing payload. To do that we have two options. 1. Use the existing *platform-specific payload * merge it with the new operation request 2. Use the *platform-independent *form merge it with new operation request (platform-independent form) construct a new payload Going through the 1st approach will be harder because then the device-platform bundle will have to have the all the conversion logic need to convert payloads ( *platform-independent - platform-specific * *platform-specific - platform-independent). *In some platforms converting back the *platform-specific payload* might not be possible because the device-platform bundle might use a 3rd party library to do the conversion. So we had to opt out 1st approach. If we follow the 2nd approach, CDM server itself can do the merging of the operation requests because it does not need any platform-specific knowledge to do so. Then the merged *platform-independent payload *can be send to the device-platform bundle to get the corresponding *platform-specific payload.* For do that we need to save the *platform-independent payload *along with the *platform-specific payload.* This approach will reduce the workload of device-platform implementer, which will make easier integration of new platforms. Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Mon, Nov 17, 2014 at 5:59 AM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi All, This is just to clarify things. With reference to defining
Re: [Architecture] Proposed Device Operations Flow of CDM
Hi Dilan On Windows and iOS we need to use the specific protocols and rely on the OS to execute the command. This is why we have to use this approach. (Sent from a mobile device) On 22 Nov 2014 19:29, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi All, Why do we need to construct a Platform-specific-payload at the server level? Cannot we just send the Platform-independent-payload to the device agent and invoke the corresponding feature operation at the client side? I might not be right because I am not exactly aware of all the use-cases. Appreciate if some valid use-cases can be provided on this regard. Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Tue, Nov 18, 2014 at 8:32 AM, Harshan Liyanage hars...@wso2.com wrote: Hi Dilan, Yes. you are correct. Thanks, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Tue, Nov 18, 2014 at 7:20 AM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi Harshan, This is with reference to the two merging options that you have mentioned in your previous reply to the thread. As I understood, with the 1st Option: You suggest to [1] convert platform-independent-payload to platform-specific-payload, save it and when another request comes in, [2] convert the platform-specific-payload back into its platform-independent-form and merge it with the platform-independent-payload for the new request and [3] convert that back to a platform-specific-payload. (Please correct me if I am wrong) So with this option, you suggest not to save a platform-independent-payload for the pending requests and deal with it only at run-time. As I understood, with the 2nd Option: You suggest to [1] Keep the platform-independent-payload saved along with its platform-specific-payload and when ever another request comes in, [2] Get the existing platform-independent-payload and merge it with new platform-independent-payload of the incoming request, save it and [3] Convert that to a new platform-specific-payload and overwrite the existing platform-specific-payload with the new one. (Please correct me if I am wrong) Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Mon, Nov 17, 2014 at 8:16 AM, Harshan Liyanage hars...@wso2.com wrote: Hi, *Platform-specific payload *is the actual payload which will be delivered to the device when the device contacts the server for pending-operations. *Platform-independent *form is used to construct the *Platform-specific payload * communicate device operations internally within CDM. For example when an user sends a device operation using CDM web-console, *platform-independent *message will be sent from the console - CDM API - CDM Core - Device-platform bundle. Then the *device-platform bundle *will use it to construct the *platform-specific payload.* But there might be situation where some device operation payloads might not delivered to the device when another operation for that device comes-in. IMO in such cases its not good to have many pending *platform-specific payloads *for a single device. If we are to deliver multiple payloads that might introduce an additional overhead in network. In such situations what I suggest is to merge the new payload with the existing payload. To do that we have two options. 1. Use the existing *platform-specific payload * merge it with the new operation request 2. Use the *platform-independent *form merge it with new operation request (platform-independent form) construct a new payload Going through the 1st approach will be harder because then the device-platform bundle will have to have the all the conversion logic need to convert payloads ( *platform-independent - platform-specific * *platform-specific - platform-independent). *In some platforms converting back the *platform-specific payload* might not be possible because the device-platform bundle might use a 3rd party library to do the conversion. So we had to opt out 1st approach. If we follow the 2nd approach, CDM server itself can do the merging of the operation requests because it does not need any platform-specific knowledge to do so. Then the merged *platform-independent payload *can be send to the device-platform bundle to get the corresponding *platform-specific payload.* For do that we need to save the *platform-independent payload *along with the *platform-specific payload.* This approach will reduce the workload of device-platform implementer, which will make easier integration of new platforms. Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog :
Re: [Architecture] Proposed Device Operations Flow of CDM
Hi Sameera, I am not exactly getting the point. It should be because I am not exactly aware of the actual use case of Windows and iOS. Do you mean that they are using different transport (or connectivity) protocols? Regards. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Sat, Nov 22, 2014 at 9:29 PM, Sameera Perera samee...@wso2.com wrote: Hi Dilan On Windows and iOS we need to use the specific protocols and rely on the OS to execute the command. This is why we have to use this approach. (Sent from a mobile device) On 22 Nov 2014 19:29, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi All, Why do we need to construct a Platform-specific-payload at the server level? Cannot we just send the Platform-independent-payload to the device agent and invoke the corresponding feature operation at the client side? I might not be right because I am not exactly aware of all the use-cases. Appreciate if some valid use-cases can be provided on this regard. Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Tue, Nov 18, 2014 at 8:32 AM, Harshan Liyanage hars...@wso2.com wrote: Hi Dilan, Yes. you are correct. Thanks, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Tue, Nov 18, 2014 at 7:20 AM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi Harshan, This is with reference to the two merging options that you have mentioned in your previous reply to the thread. As I understood, with the 1st Option: You suggest to [1] convert platform-independent-payload to platform-specific-payload, save it and when another request comes in, [2] convert the platform-specific-payload back into its platform-independent-form and merge it with the platform-independent-payload for the new request and [3] convert that back to a platform-specific-payload. (Please correct me if I am wrong) So with this option, you suggest not to save a platform-independent-payload for the pending requests and deal with it only at run-time. As I understood, with the 2nd Option: You suggest to [1] Keep the platform-independent-payload saved along with its platform-specific-payload and when ever another request comes in, [2] Get the existing platform-independent-payload and merge it with new platform-independent-payload of the incoming request, save it and [3] Convert that to a new platform-specific-payload and overwrite the existing platform-specific-payload with the new one. (Please correct me if I am wrong) Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Mon, Nov 17, 2014 at 8:16 AM, Harshan Liyanage hars...@wso2.com wrote: Hi, *Platform-specific payload *is the actual payload which will be delivered to the device when the device contacts the server for pending-operations. *Platform-independent *form is used to construct the *Platform-specific payload * communicate device operations internally within CDM. For example when an user sends a device operation using CDM web-console, *platform-independent *message will be sent from the console - CDM API - CDM Core - Device-platform bundle. Then the *device-platform bundle *will use it to construct the *platform-specific payload.* But there might be situation where some device operation payloads might not delivered to the device when another operation for that device comes-in. IMO in such cases its not good to have many pending *platform-specific payloads *for a single device. If we are to deliver multiple payloads that might introduce an additional overhead in network. In such situations what I suggest is to merge the new payload with the existing payload. To do that we have two options. 1. Use the existing *platform-specific payload * merge it with the new operation request 2. Use the *platform-independent *form merge it with new operation request (platform-independent form) construct a new payload Going through the 1st approach will be harder because then the device-platform bundle will have to have the all the conversion logic need to convert payloads ( *platform-independent - platform-specific * *platform-specific - platform-independent). *In some platforms converting back the *platform-specific payload* might not be possible because the device-platform bundle might use a 3rd party library to do the conversion. So we had to opt out 1st approach. If we follow the 2nd approach, CDM server itself can do the merging of the operation requests because it does not need any platform-specific knowledge to do so. Then the merged *platform-independent payload *can be send to the device-platform
Re: [Architecture] Proposed Device Operations Flow of CDM
Hi Dilan, In the case of iOS, it has the MDM in its OS and they have defined the payload structure for each operation. Whereas in the case of Android, we have an agent in the client side to perform the MDM operation. I believe (please correct me if am wrong) that for windows also it is the same case as iOS. Regards, Nira On 22 Nov 2014 22:41, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi Sameera, I am not exactly getting the point. It should be because I am not exactly aware of the actual use case of Windows and iOS. Do you mean that they are using different transport (or connectivity) protocols? Regards. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Sat, Nov 22, 2014 at 9:29 PM, Sameera Perera samee...@wso2.com wrote: Hi Dilan On Windows and iOS we need to use the specific protocols and rely on the OS to execute the command. This is why we have to use this approach. (Sent from a mobile device) On 22 Nov 2014 19:29, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi All, Why do we need to construct a Platform-specific-payload at the server level? Cannot we just send the Platform-independent-payload to the device agent and invoke the corresponding feature operation at the client side? I might not be right because I am not exactly aware of all the use-cases. Appreciate if some valid use-cases can be provided on this regard. Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Tue, Nov 18, 2014 at 8:32 AM, Harshan Liyanage hars...@wso2.com wrote: Hi Dilan, Yes. you are correct. Thanks, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Tue, Nov 18, 2014 at 7:20 AM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi Harshan, This is with reference to the two merging options that you have mentioned in your previous reply to the thread. As I understood, with the 1st Option: You suggest to [1] convert platform-independent-payload to platform-specific-payload, save it and when another request comes in, [2] convert the platform-specific-payload back into its platform-independent-form and merge it with the platform-independent-payload for the new request and [3] convert that back to a platform-specific-payload. (Please correct me if I am wrong) So with this option, you suggest not to save a platform-independent-payload for the pending requests and deal with it only at run-time. As I understood, with the 2nd Option: You suggest to [1] Keep the platform-independent-payload saved along with its platform-specific-payload and when ever another request comes in, [2] Get the existing platform-independent-payload and merge it with new platform-independent-payload of the incoming request, save it and [3] Convert that to a new platform-specific-payload and overwrite the existing platform-specific-payload with the new one. (Please correct me if I am wrong) Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Mon, Nov 17, 2014 at 8:16 AM, Harshan Liyanage hars...@wso2.com wrote: Hi, *Platform-specific payload *is the actual payload which will be delivered to the device when the device contacts the server for pending-operations. *Platform-independent *form is used to construct the *Platform-specific payload * communicate device operations internally within CDM. For example when an user sends a device operation using CDM web-console, *platform-independent *message will be sent from the console - CDM API - CDM Core - Device-platform bundle. Then the *device-platform bundle *will use it to construct the *platform-specific payload.* But there might be situation where some device operation payloads might not delivered to the device when another operation for that device comes-in. IMO in such cases its not good to have many pending *platform-specific payloads *for a single device. If we are to deliver multiple payloads that might introduce an additional overhead in network. In such situations what I suggest is to merge the new payload with the existing payload. To do that we have two options. 1. Use the existing *platform-specific payload * merge it with the new operation request 2. Use the *platform-independent *form merge it with new operation request (platform-independent form) construct a new payload Going through the 1st approach will be harder because then the device-platform bundle will have to have the all the conversion logic need to convert payloads ( *platform-independent - platform-specific * *platform-specific - platform-independent). *In some platforms converting back the
Re: [Architecture] Proposed Device Operations Flow of CDM
Hi Dilan, The main reason why we send a platform specific payload to the device is because the Device might not be capable of performing intelligent filtering as required. In the case of Android - we can do it because of our agent. But for iOS/Windows this is not possible cause the MDM operations are handled by the OS as mentioned by Nira and Sameera. Further more for OMA DM protocol supporting devices would require a specific payloads from the server. Cheers~ On Sat, Nov 22, 2014 at 9:20 AM, Niranjan Karunanandham niran...@wso2.com wrote: Hi Dilan, In the case of iOS, it has the MDM in its OS and they have defined the payload structure for each operation. Whereas in the case of Android, we have an agent in the client side to perform the MDM operation. I believe (please correct me if am wrong) that for windows also it is the same case as iOS. Regards, Nira On 22 Nov 2014 22:41, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi Sameera, I am not exactly getting the point. It should be because I am not exactly aware of the actual use case of Windows and iOS. Do you mean that they are using different transport (or connectivity) protocols? Regards. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Sat, Nov 22, 2014 at 9:29 PM, Sameera Perera samee...@wso2.com wrote: Hi Dilan On Windows and iOS we need to use the specific protocols and rely on the OS to execute the command. This is why we have to use this approach. (Sent from a mobile device) On 22 Nov 2014 19:29, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi All, Why do we need to construct a Platform-specific-payload at the server level? Cannot we just send the Platform-independent-payload to the device agent and invoke the corresponding feature operation at the client side? I might not be right because I am not exactly aware of all the use-cases. Appreciate if some valid use-cases can be provided on this regard. Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Tue, Nov 18, 2014 at 8:32 AM, Harshan Liyanage hars...@wso2.com wrote: Hi Dilan, Yes. you are correct. Thanks, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Tue, Nov 18, 2014 at 7:20 AM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi Harshan, This is with reference to the two merging options that you have mentioned in your previous reply to the thread. As I understood, with the 1st Option: You suggest to [1] convert platform-independent-payload to platform-specific-payload, save it and when another request comes in, [2] convert the platform-specific-payload back into its platform-independent-form and merge it with the platform-independent-payload for the new request and [3] convert that back to a platform-specific-payload. (Please correct me if I am wrong) So with this option, you suggest not to save a platform-independent-payload for the pending requests and deal with it only at run-time. As I understood, with the 2nd Option: You suggest to [1] Keep the platform-independent-payload saved along with its platform-specific-payload and when ever another request comes in, [2] Get the existing platform-independent-payload and merge it with new platform-independent-payload of the incoming request, save it and [3] Convert that to a new platform-specific-payload and overwrite the existing platform-specific-payload with the new one. (Please correct me if I am wrong) Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Mon, Nov 17, 2014 at 8:16 AM, Harshan Liyanage hars...@wso2.com wrote: Hi, *Platform-specific payload *is the actual payload which will be delivered to the device when the device contacts the server for pending-operations. *Platform-independent *form is used to construct the *Platform-specific payload * communicate device operations internally within CDM. For example when an user sends a device operation using CDM web-console, *platform-independent *message will be sent from the console - CDM API - CDM Core - Device-platform bundle. Then the *device-platform bundle *will use it to construct the *platform-specific payload.* But there might be situation where some device operation payloads might not delivered to the device when another operation for that device comes-in. IMO in such cases its not good to have many pending *platform-specific payloads *for a single device. If we are to deliver multiple payloads that might introduce an additional overhead in network. In such situations what I suggest is to merge the new payload with the existing payload.
Re: [Architecture] Proposed Device Operations Flow of CDM
Hi Harshan, This is with reference to the two merging options that you have mentioned in your previous reply to the thread. As I understood, with the 1st Option: You suggest to [1] convert platform-independent-payload to platform-specific-payload, save it and when another request comes in, [2] convert the platform-specific-payload back into its platform-independent-form and merge it with the platform-independent-payload for the new request and [3] convert that back to a platform-specific-payload. (Please correct me if I am wrong) So with this option, you suggest not to save a platform-independent-payload for the pending requests and deal with it only at run-time. As I understood, with the 2nd Option: You suggest to [1] Keep the platform-independent-payload saved along with its platform-specific-payload and when ever another request comes in, [2] Get the existing platform-independent-payload and merge it with new platform-independent-payload of the incoming request, save it and [3] Convert that to a new platform-specific-payload and overwrite the existing platform-specific-payload with the new one. (Please correct me if I am wrong) Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Mon, Nov 17, 2014 at 8:16 AM, Harshan Liyanage hars...@wso2.com wrote: Hi, *Platform-specific payload *is the actual payload which will be delivered to the device when the device contacts the server for pending-operations. *Platform-independent *form is used to construct the *Platform-specific payload * communicate device operations internally within CDM. For example when an user sends a device operation using CDM web-console, *platform-independent *message will be sent from the console - CDM API - CDM Core - Device-platform bundle. Then the *device-platform bundle *will use it to construct the *platform-specific payload.* But there might be situation where some device operation payloads might not delivered to the device when another operation for that device comes-in. IMO in such cases its not good to have many pending *platform-specific payloads *for a single device. If we are to deliver multiple payloads that might introduce an additional overhead in network. In such situations what I suggest is to merge the new payload with the existing payload. To do that we have two options. 1. Use the existing *platform-specific payload * merge it with the new operation request 2. Use the *platform-independent *form merge it with new operation request (platform-independent form) construct a new payload Going through the 1st approach will be harder because then the device-platform bundle will have to have the all the conversion logic need to convert payloads ( *platform-independent - platform-specific * *platform-specific - platform-independent). *In some platforms converting back the *platform-specific payload* might not be possible because the device-platform bundle might use a 3rd party library to do the conversion. So we had to opt out 1st approach. If we follow the 2nd approach, CDM server itself can do the merging of the operation requests because it does not need any platform-specific knowledge to do so. Then the merged *platform-independent payload *can be send to the device-platform bundle to get the corresponding *platform-specific payload.* For do that we need to save the *platform-independent payload *along with the *platform-specific payload.* This approach will reduce the workload of device-platform implementer, which will make easier integration of new platforms. Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Mon, Nov 17, 2014 at 5:59 AM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi All, This is just to clarify things. With reference to defining pending-operations-per-device, why do we need to have a *platform-specific payload *and its *platform-independent* *form*? What is the expected use-case of this? Regards, Dilan. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Mon, Nov 3, 2014 at 5:36 PM, Harshan Liyanage hars...@wso2.com wrote: Hi InoshP, Before explaining the above scenario I'll explain the process of payload generation when a request for new operation comes to the CDM core. 1. CDM Core bundle will detect its device platform using the operation code 2. Validate the operation against the supported device operations 3. Send the operation request to the device-platform bundle for converting it to a *device-specific payload* 4. Put the converted payload into the *OUT* queue We have two options when it comes to your scenario. 1. Create a new payload including the previous operation new
Re: [Architecture] Proposed Device Operations Flow of CDM
Hi Dilan, Yes. you are correct. Thanks, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Tue, Nov 18, 2014 at 7:20 AM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi Harshan, This is with reference to the two merging options that you have mentioned in your previous reply to the thread. As I understood, with the 1st Option: You suggest to [1] convert platform-independent-payload to platform-specific-payload, save it and when another request comes in, [2] convert the platform-specific-payload back into its platform-independent-form and merge it with the platform-independent-payload for the new request and [3] convert that back to a platform-specific-payload. (Please correct me if I am wrong) So with this option, you suggest not to save a platform-independent-payload for the pending requests and deal with it only at run-time. As I understood, with the 2nd Option: You suggest to [1] Keep the platform-independent-payload saved along with its platform-specific-payload and when ever another request comes in, [2] Get the existing platform-independent-payload and merge it with new platform-independent-payload of the incoming request, save it and [3] Convert that to a new platform-specific-payload and overwrite the existing platform-specific-payload with the new one. (Please correct me if I am wrong) Thanks. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Mon, Nov 17, 2014 at 8:16 AM, Harshan Liyanage hars...@wso2.com wrote: Hi, *Platform-specific payload *is the actual payload which will be delivered to the device when the device contacts the server for pending-operations. *Platform-independent *form is used to construct the *Platform-specific payload * communicate device operations internally within CDM. For example when an user sends a device operation using CDM web-console, *platform-independent *message will be sent from the console - CDM API - CDM Core - Device-platform bundle. Then the *device-platform bundle *will use it to construct the *platform-specific payload.* But there might be situation where some device operation payloads might not delivered to the device when another operation for that device comes-in. IMO in such cases its not good to have many pending *platform-specific payloads *for a single device. If we are to deliver multiple payloads that might introduce an additional overhead in network. In such situations what I suggest is to merge the new payload with the existing payload. To do that we have two options. 1. Use the existing *platform-specific payload * merge it with the new operation request 2. Use the *platform-independent *form merge it with new operation request (platform-independent form) construct a new payload Going through the 1st approach will be harder because then the device-platform bundle will have to have the all the conversion logic need to convert payloads ( *platform-independent - platform-specific * *platform-specific - platform-independent). *In some platforms converting back the *platform-specific payload* might not be possible because the device-platform bundle might use a 3rd party library to do the conversion. So we had to opt out 1st approach. If we follow the 2nd approach, CDM server itself can do the merging of the operation requests because it does not need any platform-specific knowledge to do so. Then the merged *platform-independent payload *can be send to the device-platform bundle to get the corresponding *platform-specific payload.* For do that we need to save the *platform-independent payload *along with the *platform-specific payload.* This approach will reduce the workload of device-platform implementer, which will make easier integration of new platforms. Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Mon, Nov 17, 2014 at 5:59 AM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi All, This is just to clarify things. With reference to defining pending-operations-per-device, why do we need to have a *platform-specific payload *and its *platform-independent* *form*? What is the expected use-case of this? Regards, Dilan. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Mon, Nov 3, 2014 at 5:36 PM, Harshan Liyanage hars...@wso2.com wrote: Hi InoshP, Before explaining the above scenario I'll explain the process of payload generation when a request for new operation comes to the CDM core. 1. CDM Core bundle will detect its device platform using the
Re: [Architecture] Proposed Device Operations Flow of CDM
Hi, *Platform-specific payload *is the actual payload which will be delivered to the device when the device contacts the server for pending-operations. *Platform-independent *form is used to construct the *Platform-specific payload * communicate device operations internally within CDM. For example when an user sends a device operation using CDM web-console, *platform-independent *message will be sent from the console - CDM API - CDM Core - Device-platform bundle. Then the *device-platform bundle *will use it to construct the *platform-specific payload.* But there might be situation where some device operation payloads might not delivered to the device when another operation for that device comes-in. IMO in such cases its not good to have many pending *platform-specific payloads *for a single device. If we are to deliver multiple payloads that might introduce an additional overhead in network. In such situations what I suggest is to merge the new payload with the existing payload. To do that we have two options. 1. Use the existing *platform-specific payload * merge it with the new operation request 2. Use the *platform-independent *form merge it with new operation request (platform-independent form) construct a new payload Going through the 1st approach will be harder because then the device-platform bundle will have to have the all the conversion logic need to convert payloads ( *platform-independent - platform-specific * *platform-specific - platform-independent). *In some platforms converting back the *platform-specific payload* might not be possible because the device-platform bundle might use a 3rd party library to do the conversion. So we had to opt out 1st approach. If we follow the 2nd approach, CDM server itself can do the merging of the operation requests because it does not need any platform-specific knowledge to do so. Then the merged *platform-independent payload *can be send to the device-platform bundle to get the corresponding *platform-specific payload.* For do that we need to save the *platform-independent payload *along with the *platform-specific payload.* This approach will reduce the workload of device-platform implementer, which will make easier integration of new platforms. Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Mon, Nov 17, 2014 at 5:59 AM, Dilan Udara Ariyaratne dil...@wso2.com wrote: Hi All, This is just to clarify things. With reference to defining pending-operations-per-device, why do we need to have a *platform-specific payload *and its *platform-independent* *form*? What is the expected use-case of this? Regards, Dilan. *Dilan U. Ariyaratne* Software Engineer WSO2 Inc. http://wso2.com/ Mobile: +94775149066 lean . enterprise . middleware On Mon, Nov 3, 2014 at 5:36 PM, Harshan Liyanage hars...@wso2.com wrote: Hi InoshP, Before explaining the above scenario I'll explain the process of payload generation when a request for new operation comes to the CDM core. 1. CDM Core bundle will detect its device platform using the operation code 2. Validate the operation against the supported device operations 3. Send the operation request to the device-platform bundle for converting it to a *device-specific payload* 4. Put the converted payload into the *OUT* queue We have two options when it comes to your scenario. 1. Create a new payload including the previous operation new operation 2. Create another payload. So that 2 payloads will be stored in the *OUT *queue. IMO the best option would be 1, since the second option will consume more memory in the queue more bandwidth of the device because it has to take 2 payloads. For supporting the option 1, we have the following options. 1. Device platform bundle will take the platform-specific payload in the queue merge it with the new operation In this case, the overhead of the device platform bundle will be much higher because it must know how to convert back the *platform-specific payload* to the *platform-independent* form. This will make writing a new device-platform bundle a tedious task because of the complexity of payload transformation logic. So I'm -1 on this option. 2. We'll use a platform-independent format for saving the payload into the queue which can be easily merged with new operations. This platform-independent payload will be converted when the device contacts the CDM server for pending operations. This is much more easier method than the first option. But this will affect the number of concurrent devices CDM can support due to the on-demand conversion of payloads. On the other-hand this method will reduce the resource consumption avoid unnecessary payload transformations. Further-more this will reduce the complexity of CDM core because there is no need to get the payload
[Architecture] Proposed Device Operations Flow of CDM
Hi, Please find the attached proposed device operations flow of CDM. Your suggestions feedback is highly appreciated. Thanks, Best Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. Operation Flow (1).pdf Description: Adobe PDF document ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Proposed Device Operations Flow of CDM
Hi Harshan, If for example, a message to a device is already in the queue and when monitoring happen, a similar payload is generated. How is it handled when it comes to communication between out queue and device platform bundle? Regards, Inosh On Mon, Nov 3, 2014 at 3:20 PM, Harshan Liyanage hars...@wso2.com wrote: Hi, Please find the attached proposed device operations flow of CDM. Your suggestions feedback is highly appreciated. Thanks, Best Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. -- Inosh Perera Software Engineer, WSO2 Inc. Tel: 0785293686 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Proposed Device Operations Flow of CDM
Hi InoshP, Before explaining the above scenario I'll explain the process of payload generation when a request for new operation comes to the CDM core. 1. CDM Core bundle will detect its device platform using the operation code 2. Validate the operation against the supported device operations 3. Send the operation request to the device-platform bundle for converting it to a *device-specific payload* 4. Put the converted payload into the *OUT* queue We have two options when it comes to your scenario. 1. Create a new payload including the previous operation new operation 2. Create another payload. So that 2 payloads will be stored in the *OUT * queue. IMO the best option would be 1, since the second option will consume more memory in the queue more bandwidth of the device because it has to take 2 payloads. For supporting the option 1, we have the following options. 1. Device platform bundle will take the platform-specific payload in the queue merge it with the new operation In this case, the overhead of the device platform bundle will be much higher because it must know how to convert back the *platform-specific payload* to the *platform-independent* form. This will make writing a new device-platform bundle a tedious task because of the complexity of payload transformation logic. So I'm -1 on this option. 2. We'll use a platform-independent format for saving the payload into the queue which can be easily merged with new operations. This platform-independent payload will be converted when the device contacts the CDM server for pending operations. This is much more easier method than the first option. But this will affect the number of concurrent devices CDM can support due to the on-demand conversion of payloads. On the other-hand this method will reduce the resource consumption avoid unnecessary payload transformations. Further-more this will reduce the complexity of CDM core because there is no need to get the payload corresponding to the operation from the device-platform bundle put it into the OUT queue. 3. Save the platform-independent payload format along with the platform-specific payload in the queue. This method will increase the resource consumption because we need more memory to keep the platform-independent payload platform-dependent payload in the OUT queue. But this will increase the number of concurrent devices CDM can support because the payload is readily available when the device contacts the server. I'm +1 for both 2nd and 3rd options. WDYT? Thanks, Best Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Mon, Nov 3, 2014 at 3:47 PM, Inosh Perera ino...@wso2.com wrote: Hi Harshan, If for example, a message to a device is already in the queue and when monitoring happen, a similar payload is generated. How is it handled when it comes to communication between out queue and device platform bundle? Regards, Inosh On Mon, Nov 3, 2014 at 3:20 PM, Harshan Liyanage hars...@wso2.com wrote: Hi, Please find the attached proposed device operations flow of CDM. Your suggestions feedback is highly appreciated. Thanks, Best Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. -- Inosh Perera Software Engineer, WSO2 Inc. Tel: 0785293686 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Proposed Device Operations Flow of CDM
Hi Harshan 1. Device platform bundle will take the platform-specific payload in the queue merge it with the new operation In this case, the overhead of the device platform bundle will be much higher because it must know how to convert back the *platform-specific payload* to the *platform-independent* form. This will make writing a new device-platform bundle a tedious task because of the complexity of payload transformation logic. So I'm -1 on this option. IMO this would be the a better option since the overhead is removed when the device tries to communicate with the server to get the payload. AFAIU even in the option 2 and 3, the device platform bundle should be able to convert the platform-independent payload to device specific payload. Therefore if in the platform-specific bundle has the reverse logic that is converting device specific to platform independent payload then the overhead is there at the time when a new operation is added. WDYT? I noticed that in the diagram, all the operations are put into the queue and the device contacts to retrieve the message. What about the scenario where the server would want to contact the device that is for example in Android and iOS, the server can connect the device via the GCM or APNS respectively. How is this handled? Regards, Nira On Mon, Nov 3, 2014 at 5:36 PM, Harshan Liyanage hars...@wso2.com wrote: Hi InoshP, Before explaining the above scenario I'll explain the process of payload generation when a request for new operation comes to the CDM core. 1. CDM Core bundle will detect its device platform using the operation code 2. Validate the operation against the supported device operations 3. Send the operation request to the device-platform bundle for converting it to a *device-specific payload* 4. Put the converted payload into the *OUT* queue We have two options when it comes to your scenario. 1. Create a new payload including the previous operation new operation 2. Create another payload. So that 2 payloads will be stored in the *OUT * queue. IMO the best option would be 1, since the second option will consume more memory in the queue more bandwidth of the device because it has to take 2 payloads. For supporting the option 1, we have the following options. 1. Device platform bundle will take the platform-specific payload in the queue merge it with the new operation In this case, the overhead of the device platform bundle will be much higher because it must know how to convert back the *platform-specific payload* to the *platform-independent* form. This will make writing a new device-platform bundle a tedious task because of the complexity of payload transformation logic. So I'm -1 on this option. 2. We'll use a platform-independent format for saving the payload into the queue which can be easily merged with new operations. This platform-independent payload will be converted when the device contacts the CDM server for pending operations. This is much more easier method than the first option. But this will affect the number of concurrent devices CDM can support due to the on-demand conversion of payloads. On the other-hand this method will reduce the resource consumption avoid unnecessary payload transformations. Further-more this will reduce the complexity of CDM core because there is no need to get the payload corresponding to the operation from the device-platform bundle put it into the OUT queue. 3. Save the platform-independent payload format along with the platform-specific payload in the queue. This method will increase the resource consumption because we need more memory to keep the platform-independent payload platform-dependent payload in the OUT queue. But this will increase the number of concurrent devices CDM can support because the payload is readily available when the device contacts the server. I'm +1 for both 2nd and 3rd options. WDYT? Thanks, Best Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Mon, Nov 3, 2014 at 3:47 PM, Inosh Perera ino...@wso2.com wrote: Hi Harshan, If for example, a message to a device is already in the queue and when monitoring happen, a similar payload is generated. How is it handled when it comes to communication between out queue and device platform bundle? Regards, Inosh On Mon, Nov 3, 2014 at 3:20 PM, Harshan Liyanage hars...@wso2.com wrote: Hi, Please find the attached proposed device operations flow of CDM. Your suggestions feedback is highly appreciated. Thanks, Best Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. -- Inosh Perera Software Engineer, WSO2 Inc. Tel: 0785293686
Re: [Architecture] Proposed Device Operations Flow of CDM
Hi Niranjan, Please find my comments in line. IMO this would be the a better option since the overhead is removed when the device tries to communicate with the server to get the payload. AFAIU even in the option 2 and 3, the device platform bundle should be able to convert the platform-independent payload to device specific payload. Therefore if in the platform-specific bundle has the reverse logic that is converting device specific to platform independent payload then the overhead is there at the time when a new operation is added. WDYT? Yes. But in 2, 3rd options there is no need to write the reverse logic to convert device-specific payload into platform-independent one. In option 3, the payload is readily available when device contacts the server. So sticking to the option 1 will increase the burden of the device platform bundle developers. I noticed that in the diagram, all the operations are put into the queue and the device contacts to retrieve the message. What about the scenario where the server would want to contact the device that is for example in Android and iOS, the server can connect the device via the GCM or APNS respectively. How is this handled? In the new architecture we have given the user to choose the preferred way of sending operations to the devices. Basically there will be 3 modes and I've only included the Local notification mode in this flow diagram. 1. Cloud based push notification mode (GCM, APNS) This is entirely based on cloud messaging services like GCM or APNS where the payload to be sent to the device is incorporated into a cloud message send to the device. 2. Local notification mode This method is similar to the existing Android Local notification system where the device periodically checks the server for pending operations. 3. Hybrid mode With this mode we'll use cloud messaging service to send a wake-up notification to the device. When the wake-up notification is received the device will contact the server for pending operations. So for supporting 1st 3rd mode, there must be an asynchronous background processor (as in *IN Queue*) which processes messages to be sent to the Cloud services. Device-platform bundle must have the logic to create such payloads send them to the cloud service. I'll update the diagram with these modes. Thanks for the reminding it. Thanks, Best Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Tue, Nov 4, 2014 at 10:14 AM, Niranjan Karunanandham niran...@wso2.com wrote: Hi Harshan 1. Device platform bundle will take the platform-specific payload in the queue merge it with the new operation In this case, the overhead of the device platform bundle will be much higher because it must know how to convert back the *platform-specific payload* to the *platform-independent* form. This will make writing a new device-platform bundle a tedious task because of the complexity of payload transformation logic. So I'm -1 on this option. IMO this would be the a better option since the overhead is removed when the device tries to communicate with the server to get the payload. AFAIU even in the option 2 and 3, the device platform bundle should be able to convert the platform-independent payload to device specific payload. Therefore if in the platform-specific bundle has the reverse logic that is converting device specific to platform independent payload then the overhead is there at the time when a new operation is added. WDYT? I noticed that in the diagram, all the operations are put into the queue and the device contacts to retrieve the message. What about the scenario where the server would want to contact the device that is for example in Android and iOS, the server can connect the device via the GCM or APNS respectively. How is this handled? Regards, Nira On Mon, Nov 3, 2014 at 5:36 PM, Harshan Liyanage hars...@wso2.com wrote: Hi InoshP, Before explaining the above scenario I'll explain the process of payload generation when a request for new operation comes to the CDM core. 1. CDM Core bundle will detect its device platform using the operation code 2. Validate the operation against the supported device operations 3. Send the operation request to the device-platform bundle for converting it to a *device-specific payload* 4. Put the converted payload into the *OUT* queue We have two options when it comes to your scenario. 1. Create a new payload including the previous operation new operation 2. Create another payload. So that 2 payloads will be stored in the *OUT *queue. IMO the best option would be 1, since the second option will consume more memory in the queue more bandwidth of the device because it has to take 2 payloads. For supporting the option 1, we have the following options. 1. Device platform bundle will take the
