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 <hars...@wso2.com> 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: hars...@wso2.com > 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 <samee...@wso2.com> wrote: > >> >> On Fri, Oct 31, 2014 at 9:04 AM, Dilshan Edirisuriya <dils...@wso2.com> >> 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: samee...@wso2.com >> Tel : 94 11 214 5345 >> Fax :94 11 2145300 >> *WSO2, Inc.* <http://wso2.com/> >> lean.enterprise.middleware >> >> >> >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
