Hi Dilan, The main use case for the CDM is to manage any device. To do this - we have to perform intelligent management at the server side rather than giving that to the client. This is due to below reasons :-
- The client might not be written by us - Support DM protocols (OMA DM/ LW M2M) - Security aspect of allowing the client to infer the payload Because there is complications involved - we have sort out OSGi bundles to handle platform specific use cases. When we are adding a new device platform we have to implement the base functions and add any functions needed. Cheers~ On Sat, Nov 22, 2014 at 9:33 AM, Dilan Udara Ariyaratne <[email protected]> wrote: > Hi All, > > I am having this little doubt about the use and the purpose of having a > device-specific OSGI Bundle at the server side. > > By doing that, aren't we taking up the burden of handling all the > complexities/incompatibilities of the device side to the server side. > > Isn't that possible to move this burden to the Device-side-agent, so that > the actual platform-specific-logic will be handled by the > Device-side-agent and > the CDM-server-side implementation will be much more generic, light-weight > and faster in execution, from the other end. > > If the communication protocol is the problem from device to device, we can > just have the connector to bridge the gap. > > I may not be right, so please excuse. This is just to clarify things. > > Regards, > > Dilan. > > > > *Dilan U. Ariyaratne* > Software Engineer > WSO2 Inc. <http://wso2.com/> > Mobile: +94775149066 > lean . enterprise . middleware > > On Fri, Oct 31, 2014 at 9:57 AM, Harshan Liyanage <[email protected]> > wrote: > >> Actually the connector will only act as an interface to communicate with >> the device. Actual platform-specific logic & the payload to be sent to the >> device (for executing an operation) will be constructed by the >> platform-specific OSGi bundle. >> >> There won't be any connection between CDM-Console & platform-specific >> bundle or connector. When a new platform added, there will be a >> configuration which included the operations supported by the platform (it >> will depend on the platform version). The configuration will be something >> like belows (not-finalized). This configuration can be done through the >> CDM-console & it will be saved to the Registry or database. Initially we >> thought of saving it to the registry. But Inosh has pointed out that there >> might be situation where we'll have to join the information in this config >> with the data in database. In such cases we'll have to programatically join >> the results from db queries with the config (which would affect the >> performance). So we have not yet finalized where to save this >> configuration. >> >> <platform> - Individual platform config >> >> platformId - unique platform id >> >> name - platform name >> >> minOSVersion - minimum OS version supported >> >> maxOSVersion - maximum OS version supported >> >> description - A short description about the platform >> >> transports - Transport mechanisms / protocols supported >> >> payloadConfig - Payload configuration >> >> header - Payload header configuration >> >> template - Header template >> >> alwaysAppend (True/False) - Whether to append header for all >> communications >> >> <operations> - Operation configuration >> >> <operation> - Individual operation config >> >> operationId - Unique ID for operation >> >> code - Operation code >> >> name - Operation name >> >> description - Description >> >> type - One way / Two way >> >> payloadConfig - Payload configuration for the operation >> >> appendHeader - Whether to append header or not >> >> template - Payload template for the operation >> >> parent - Parent element of this payload. This will be used for creating >> policies & sequence of operations. >> >> <params> - Optional parameter configuration. These parameters will be >> sent as data in the payload. This will be required when implementing >> dynamic policies/ rules. For example “Set device volume to 30%” >> >> <param> >> >> name - Param name >> >> type - Param type (integer/ boolean/ float etc) >> >> defaultValue - Default value sent if not specified >> >> minValue - Minimum permitted value >> >> maxValue - Max permitted value >> >> <param/> >> >> </params> >> >> </operation> >> >> </operations> >> >> </platform> >> >> But there may be cases like some devices may not support all the >> operations supported by the platform. So when invoking operations on a >> device we'll have to filter out the operations those are not supported. As >> Inosh has mentioned our agent app has to be modified to send the operations >> supported by the device to the CDM. Then CDM will know what are the >> operation supported by the device platform and by devices. >> >> Hope this clarifies your questions. I'll update the thread with proposed >> operation flow ASAP. >> >> Best Regards, >> >> Lakshitha Harshan >> Software Engineer >> Mobile: *+94724423048* >> Email: [email protected] >> Blog : http://harshanliyanage.blogspot.com/ >> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >> lean.enterprise.middleware. >> >> On Fri, Oct 31, 2014 at 9:09 AM, Sameera Perera <[email protected]> >> wrote: >> >>> >>> On Fri, Oct 31, 2014 at 9:04 AM, Dilshan Edirisuriya <[email protected]> >>> wrote: >>> >>>> Please see the comments for the question. >>>> >>>> 3) Does this APIs get exposed through API manager? If so how does the >>>> same API differentiate in multiple platforms? Does this have multiple APIs >>>> based on the platform? >>>> >>> Every device platform will have their own APIs. For example >>>> registration for iOS would be something like HOST/ios/register whereas for >>>> Android it would be something like HOST/android/register >>>> >>> >>> Correct: The purpose of the connector is to unify them in to a common >>> API that the console is aware of. Each connector will talk to the >>> platform's native API. >>> >>> >>> >>> -- >>> >>> ------------------------------ >>> >>> *Sameera Perera* >>> Director of Engineering >>> gtalk: [email protected] >>> Tel : 94 11 214 5345 >>> Fax :94 11 2145300 >>> *WSO2, Inc.* <http://wso2.com/> >>> lean.enterprise.middleware >>> >>> >>> >> > -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2 Inc Lean.Enterprise.Mobileware * ~Email [email protected] <[email protected]>* * ~Mobile +94712112165* * ~Website dulitha.me <http://dulitha.me>* * ~Twitter @dulitharw <https://twitter.com/dulitharw>* *~Github @dulichan <https://github.com/dulichan>* *~SO @chan <http://stackoverflow.com/users/813471/chan>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
