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 > > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
