Hi all,
A feature in CDM is what defines a command that can be executed on a
device. When applying a command on a device there can 4 factors to consider
to decide if it can be / should be applied or not. These are based on ,
If Operating system support the command + Operating system version support
the command + device platform support the command + A specific
device support the command
Proposed CDM will contain a set of platform(iOS, Android, Windows) specific
bundles which will reside in the middle of a device and the CDM core[1][2].
When a command is applied on a device by a user through CDM console, the
device specific bundle is responsible for converting the command to a
platform *dependent* payload that a device can understand.
With the proposed architecture, there can be few ways to define a feature,
implementation details of it.
1. Server's device specific bundles describes the feature and the way to
implement it.
For example: If the Admin needs to apply a command on a device through CDM
console. Server must know,
- Details of the feature
- Permitted/required values to apply the command
- The final format of the command that a device can understand.
For instance, If the user needs to reduce volume of a device to 0, the
server must know a command called,
- Volume
- Permitted range is 0-100
- Format the device accepts the command
All the above values are stored in the server. This method is necessary to
handle, devices that doesn't allow an agent to perform MDM operations,
rather it is *done through the OS it-self**. *In this case, all the
features and their payloads are pre-defined in the server.
2. Client send the commands it supports *along with some implementation
details(meta-data)*. This method is suitable for *Agent based system* such
as Andoid and Arduino since the client can send the commands list it
supports and some meta data about the commands. Bellow diagrams describe,
how a device with a CDM agent, first sends commands and meta-data and how
the admin/user apply a command on a device.
*Agent publishing supported features*
1. At the time of registration or when the supported commands change, the
Agent sends the command list to corresponding server connector(API)
together with meta-data on how to process it.
For example: A client might send, {FeatureCode:"volume",
DataType:"Integer", MinValue:0, MaxValue:100}
2. Corresponding platform bundle receives the payload. Data is converted
to its platform independent format.
3. Data is forwarded to CDM Core
4. Finally saved to the database
Since the command is self-describing, any new command can be understood by
the server and interpreted. Due to the flexibility of this mechanism, when
a new feature is added to an agent, that is not defined in the server;
server can still recognize the command, allow user to apply the command on
devices. This extensibility is very useful in IoT scenario.
*Admin, applying a feature on a device*
1. Admin applies a command on a device through CDM console. such
as {FeatureCode:"volume", value:"0"}
2. Core check for permission to apply/perform the command and the request
is saved.
3. Core invokes the relevant platform specific bundle to handle the request
and passes a device independent payload
4. Platform specific reply is created according to the values sent by the
core. This platform specific payload is created based on a template stored
in the server. If a template is not available(new command), a generic
response will be sent based on the value to be sent.
5. Core puts it to the output queue, so that the device may retrieve it.
The template mentioned in step 4 is the format the device expect the
command. For agent based devices, this format can be a common one such as a
JSON object, but for agentless devices such as Windows phones it will be
different. Admin can edit this template, through the CDM console. Also the
server will be able to restrict certain features from a device, even though
the device support the features.
3. Hybrid approach. Combination of both the above mentioned methods are
necessary for some devices such as iOS devices, where some device
management features can be done through the agent, but some are done
through the server. This is due to the fact that some operations are
pre-defined, by the Operating system it-self, and the payload formats and
command code are defined, by the OS it-self. But some of the command are
not defined by the OS, therefore Agent is required to perform those
operation.
[1] Proposed Architecture of CDM [Architecture]
[2] Proposed Device Operations Flow of CDM[Architecture]
Regards,
Inosh
--
Inosh Perera
Software Engineer, WSO2 Inc.
Tel: 0785293686
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
