Needed: OMA DM API on Windows Mobile
The Windows Mobile device management platform supports two different Open Mobile Alliance (OMA) standards: OMA Client Provisioning (OMA CP) and OMA Device Management (OMA DM). By the say, OMA CP is the new name for WAP Provisioning. So, when you see Windows Mobile configuration XML with the root node of <wap-provisioningdoc>, you know you are using OMA CP.
Because Windows Mobile supports both OMA CP and OMA DM, you’ll find that MSDN documentation for most Windows Mobile Configuration Service Providers will include information on configuration XML for both standards. OMA DM is suppose to be the new, improved standard (and it is in many ways). So, you may wonder why OMA CP support is still included.
As with most wireless-related standards and protocols, ubiquitous deployment and use of OMA DM has been slow. OMA CP is still widely used. Of course, the improvements inherent to OMA DM will drive eventual OMA DM ubiquity, but for now, OMA CP still rules the roost.
But, from a Windows Mobile developer point of view, there is another reason why OMA DM is slow to take hold. The Windows Mobile device management platform does not come with an OMA DM API. The only way to take advantage of Windows Mobile OMA DM functionality is to bootstrap an OMA DM server to the device and interact with the platform through a client/server connection.
In comparison, the Windows Mobile device management platform provides much richer interfaces to configure the device using OMA CP. There is nice API, DMProcessConfigXML (this is the native API, managed .NET CF API is called ProcessConfigXML in Microsoft.WindowsMobile.Configuration) . You can also configure the device via Remote API (RAPI) that is exposed on desktop PCs running ActiveSync or Vista Windows Mobile Device Center (WMDC). Of course, OMA CP can be configured via a WAP provisioning server for the client/server connection functionality. But, for device developers, we need a client-side API which does not exist for OMA DM on Windows Mobile.
Why do we need a client-side API for OMA DM? The main reason is to build a value-added device management solution for customers that want more then what you can get out-of-the-box with the Windows Mobile device management platform.
For instance, a client application can save bandwidth and improve performance by adding smart query logic to device management transactions. Otherwise, you’d need to offload all the logic to the server. An example might be that a client can detect a new Bluetooth profile registration and allow or disallow its use based on a pre-configured policy. Without this, the information must be uploaded to the server, processed by an admin or some server-side application and a new policy is provisioned to the device’s networkpolicy CSP. That’s just one example though.
Another reason to build a client application for device management is to add new device management features to those provided out-of-the-box. If you use a device with built in GPS, RFID reader, etc., you may want to manage these devices and their requisite applications as well. And, if you want to support device management across multiple hardware and operating system platforms, you’ll probably end up opting to build a device management client.
You may be thinking that this is all a lot of whining though because the Windows Mobile device management platform still makes OMA CP configuration accessible to applications. But, consider that in Windows Mobile 6.1, most all of the new software management Configuration Service Providers are OMA DM only with no ability to manage them via OMA CP. This means that a Windows Mobile Device Management developer will need to use an OMA DM server or a proprietary client application to leverage the new, cool, built-in Configuration Service Providers that manage software and ROM update installations.
In conclusion, the call to action is for Microsoft to provide and public, documented API for applications to interface with Windows Mobile OMA DM components just like OMA CP. Perhaps DMProcessConfigXML() can be extended to support both OMA DM and OMA CP XML input.
Dave Field, CISSP, MCP
Device Managment and Security Architect
Enterprise Mobile, Inc.