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 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 >> >> > > > -- > > *Niranjan Karunanandham* > Senior Software Engineer - WSO2 Inc. > WSO2 Inc.: http://www.wso2.com >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
