Hi Dileesha,

I believe when implementing this we should not make it Android specific.
That way we can make use of this in the IOT world as well.

There is huge potential in this protocol being used for Monitoring/Remote
Command Pushing/Firmware Update across the entire spectrum of IOT Devices.

Thanks and Regards,

Ruwan Yatawara

Senior Software Engineer,
WSO2 Inc.

email : [email protected]
mobile : +94 77 9110413
blog : http://ruwansrants.blogspot.com/
www: :http://wso2.com


On Mon, Sep 21, 2015 at 4:22 PM, Dileesha Rajapakse <[email protected]>
wrote:

> Yes. The Protocol is SyncML.
>
>
> http://technical.openmobilealliance.org/Technical/release_program/docs/Common/V1_2_2-20090724-A/OMA-TS-SyncML-RepPro-V1_2_2-20090724-A.pdf
>
> On Mon, Sep 21, 2015 at 4:16 PM, Dulitha Wijewantha <[email protected]>
> wrote:
>
>>
>>
>> On Monday, September 21, 2015, Dileesha Rajapakse <[email protected]>
>> wrote:
>>
>>> *Android OMA-DM Standardization*
>>>
>>> *OVERVIEW*
>>>
>>> As per the current architecture of the Android Component of the WSO2 MDM
>>> framework, Android mobile devices are managed using a custom built client
>>> application installed on the device. Server to Client communication is done
>>> over HTTP and the devices are provisioned periodically through a polling
>>> mechanism. *OMA-DM* is a standard device management protocol which has
>>> been adopted by several device manufacturers. This thread is a study on
>>> standardization of the current Android MDM implementation using to use
>>> OMA-DM Standards and Protocols.
>>>
>>> *GOALS*
>>>
>>>    - Standardize current Android implementation using OMA-DM
>>>    Specification.
>>>
>>> *What is OMA-DM?*
>>>
>>>    - *Open Mobile Alliance* (OMA) is a non-profit organization.
>>>    - Delivers Open Specifications for creating interoperable services.
>>>    - The *Device Management (DM) Working Group (WG)* specifies
>>>    protocols and mechanisms to achieve the management of mobile devices,
>>>    services access and software on connected devices.
>>>    - Current stable version is *v1.3* [1].
>>>
>>> *Why OMA-DM?*
>>>
>>>    - Managing devices with OMA DM version 1.2 allows two-way async
>>>    communication between the server and client.
>>>    - Ease of managing devices through *Management Objects*.
>>>    - Can easily manage converged and multi-mode devices on any network,
>>>    including devices that do not have a SIM card, as well as resource
>>>    constrained devices. This extensibility is one of the key benefits of OMA
>>>    DM, making it ideal for M2M communication scenarios.
>>>
>>>
>>> Another advantage managing Android through OMA-DM as I see is - if
>> someone wants to write a custom android client for our server. They can
>> easily do it by building it against OMA-DM spec. A potential scenarios are
>> TVs, Cars and a Android laptops.
>>
>>> *OMA-DM Device Management Technology*
>>>
>>>    - The OMA DM specifications [2] define the protocols and the
>>>    mechanisms allowing an OMA DM Server to deliver configuration parameters 
>>> to
>>>    an OMA DM Client.
>>>
>>> Is this done using XML payloads?
>>
>>>
>>>    - This is done using a defined set of *“DM Commands”* for various
>>>    management scenarios.
>>>    - These are executed inside a well-defined and secure environment
>>>    (the *“DM Session”*).
>>>
>>>
>>>    - The *OMA DM Client* exposes the device internal data to the *OMA
>>>    DM Server* in the form of a hierarchic tree known as the *“DM Tree”*.
>>>    - A *Management Tree* is a  mechanism by which the management client
>>>    interacts with the device, e.g. by storing and retrieving values from it
>>>    and by manipulating the properties of it, for example the access control
>>>    lists.
>>>    - It is made up of different building blocks (or sub-trees) called 
>>> *Management
>>>    Objects*.
>>>    - A *Management Object* is is a subtree of the Management Tree which
>>>    is intended to be a (possibly singleton) collection of *Nodes* which
>>>    are related in some way.
>>>    - Management Objects provide specific functionality in the
>>>    management of devices.
>>>    - The management of a device feature consists of the management of
>>>    the DM Tree, which virtualizes the device features and functionalities.
>>>
>>>
>>>    - The OMA DM Working Groups specified a number of Management Objects
>>>    implementing specific management functions.
>>>
>>>
>>>    - There are several Management Objects which have been specified to
>>>    support additional functionalities [3]:
>>>       - *Software Management *(OMA DM SCOMO) allowing not only the
>>>       installation and the removal of applications on the mobile, but also 
>>> the
>>>       retrieval of the inventory of software components already installed 
>>> on the
>>>       device
>>>       - *Diagnostics and Monitoring *(OMA DM DiagMon MO), which enables
>>>       remote diagnostic, for example to query the device for memory and 
>>> battery
>>>       status or to collect radio measures and QoS parameters, and remote
>>>       monitoring, by defining trap and reports
>>>       - *Connectivity* (OMA DM ConnMO), which allows the configuration
>>>       of bearers and proxies
>>>       - *Device Capabilities *(OMA DM DCMO), which allows a Management
>>>       Authority to remotely enable and disable device peripherals like 
>>> cameras,
>>>       Bluetooth, USB, etc
>>>       - *Lock and Wipe *(OMA DM LAWMO), which allows to remotely lock
>>>       and/or wipe the device, for instance when the device is stolen or 
>>> sold, or
>>>       when personal or enterprise data are compromised
>>>       - *Browser* (OMA DM BMO), which allows remote management of
>>>       browser favorites and settings
>>>       - *Virtualization* (OMA DM VirMO), which enables remote
>>>       management of virtual machines running on the device (expected for 3Q 
>>> 2013)
>>>       - *Management Policy *(OMA DM Management Policy MO), which allows
>>>       the deployment on the device of policies which the DM Client can 
>>> execute
>>>       and enforce independently: if some events happen, then perform some
>>>       operations (expected for 2Q 2014)
>>>
>>> OMA DM WG also specified *Gateway* functionality (OMA DM GwMO v1.0),
>>> which allows an OMA DM Server to manage devices that:
>>>
>>>    - are not directly accessible, for example, because they are
>>>    deployed behind a firewall
>>>    - can be clustered in a group, for instance when they are deployed
>>>    in a very large number (like sensors), using fan out mechanisms
>>>    - support other Management protocols than OMA DM
>>>
>>> I will keep updating this mail thread as I move forward.
>>>
>>> [1] -
>>> http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/dm-v1-3
>>>
>>> [2] -
>>> http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases
>>>
>>> [3] -
>>> http://openmobilealliance.org/about-oma/work-program/device-management/
>>> --
>>> Dileesha Rajapakse
>>> *Intern - Engineering*
>>> Mobile : +94 (0) 772 555 933
>>> Tel      : +94 112 741 505
>>> [email protected]
>>>
>>
>>
>> --
>> Dulitha Wijewantha (Chan)
>> Software Engineer - Mobile Development
>> WSO2 Inc
>> Lean.Enterprise.Middleware
>>  * ~Email       [email protected] <[email protected]>*
>> *  ~Mobile     +94712112165 <%2B94712112165>*
>> *  ~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>*
>>
>>
>
>
> --
> Dileesha Rajapakse
> *Intern - Engineering*
> Mobile : +94 (0) 772 555 933
> Tel      : +94 112 741 505
> [email protected]
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to