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 <[email protected]> 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. > Mobile: +94775149066 > lean . enterprise . middleware > >> On Sat, Nov 22, 2014 at 9:29 PM, Sameera Perera <[email protected]> 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" <[email protected]> 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. >>> Mobile: +94775149066 >>> lean . enterprise . middleware >>> >>>> On Tue, Nov 18, 2014 at 8:32 AM, Harshan Liyanage <[email protected]> wrote: >>>> Hi Dilan, >>>> >>>> Yes. you are correct. >>>> >>>> Thanks, >>>> >>>> Lakshitha Harshan >>>> Software Engineer >>>> Mobile: +94724423048 >>>> Email: [email protected] >>>> Blog : http://harshanliyanage.blogspot.com/ >>>> WSO2, Inc. : wso2.com >>>> lean.enterprise.middleware. >>>> >>>>> On Tue, Nov 18, 2014 at 7:20 AM, Dilan Udara Ariyaratne <[email protected]> >>>>> 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. >>>>> Mobile: +94775149066 >>>>> lean . enterprise . middleware >>>>> >>>>>> On Mon, Nov 17, 2014 at 8:16 AM, Harshan Liyanage <[email protected]> >>>>>> 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: [email protected] >>>>>> Blog : http://harshanliyanage.blogspot.com/ >>>>>> WSO2, Inc. : wso2.com >>>>>> lean.enterprise.middleware. >>>>>> >>>>>>> On Mon, Nov 17, 2014 at 5:59 AM, Dilan Udara Ariyaratne >>>>>>> <[email protected]> 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. >>>>>>> Mobile: +94775149066 >>>>>>> lean . enterprise . middleware >>>>>>> >>>>>>>> On Mon, Nov 3, 2014 at 5:36 PM, Harshan Liyanage <[email protected]> >>>>>>>> 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: [email protected] >>>>>>>> Blog : http://harshanliyanage.blogspot.com/ >>>>>>>> WSO2, Inc. : wso2.com >>>>>>>> lean.enterprise.middleware. >>>>>>>> >>>>>>>>> On Mon, Nov 3, 2014 at 3:47 PM, Inosh Perera <[email protected]> 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 <[email protected]> >>>>>>>>>> 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: [email protected] >>>>>>>>>> Blog : http://harshanliyanage.blogspot.com/ >>>>>>>>>> WSO2, Inc. : wso2.com >>>>>>>>>> lean.enterprise.middleware. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Inosh Perera >>>>>>>>> Software Engineer, WSO2 Inc. >>>>>>>>> Tel: 0785293686 >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
