From the mobile client's perspective, in concept OTA is simply a matter of finding an interesting application on the Web and initiating its download over the wireless network. In its simplest form, OTA is pretty straightforward, as Figure 1 illustrates:
 Figure 1 - Simplified View of an OTA Provisioning Architecture (Click image to enlarge.) |
Note the participants in this process:
- Client device with a discovery application - The client device must have software that allows the user to locate applications at a particular provisioning portal on the network, and to choose which applications to download - this software is referred to as a discovery application (DA). The discovery application may be browser-based or a native application, so long as it shares a common provisioning protocol with the download server; for example, for MIDP OTA this protocol is HTTP.
- The Network - This is any appropriate wireless network, which may include a radio network and a WAP gateway, for example.
- The Download Server - Also called a provisioning portal, or server, or vending machine, this is a host, visible in the network, that typically runs a web server and has access to a content repository - in its simplest form any Web site can serve as a provisioning portal. It has two main functions: it provides properly formatted menus, often written in WML or HTML, that list the applications currently available for download, and it provides access (sometimes controlled) to the applications. A single download server might support one or many OTA protocols.
- The Content Repository - As the name implies, this is the repository of all the application descriptors and applications that are available for download.
In actual use, OTA is not quite so simple. An OTA provisioning system typically encompasses content publication and management, access control, installation (and upgrading) of applications, and tracking the use of applications (content) for billing purposes. Figure 2 introduces these complexities:
 Figure 2 - Detailed View of an OTA Provisioning System (Click image to enlarge.) |
As you can see, the process behind the scenes is more involved than what the user actually sees:
- A. Content Management - Server-side software manages the repository, typically a database, and supports content versioning, ways for third-party developers to drop their applications, and so on. Some carriers require applications be certified before making them available for OTA.
- B. Content Discovery - As you've already seen, the user directs the discover application to a download portal, which accesses the application repository and provides a properly formatted menu of the available content and applications.
- C. Authenticate - If the provisioning server supports an authentication module, the user is authenticated before gaining access to the repository.
- D. Application retrieval and installation - Once any authentication is complete, downloading the application is a two-part operation, handled by the application management system (AMS), the software in the device that manages the download, installation, execution, and removal of applications and other resources on the device. If an application description (in the form of a JAD file) exists, the AMS downloads it from the provisioning server's repository. Based on information found in the downloaded application descriptor, the AMS automatically downloads the application (the MIDlet suite JAR) from the repository. If required, the user is re-authenticated. If the application is retrieved successfully, installation is automatic.
- E. Confirmation - The AMS sends a confirmation status to indicate whether the installation succeeded or failed.
- F. Tracking - The confirmation status can be used to track the use of the application, for example for billing purposes. A billing system is often integrated into the provisioning server.
In addition to the basic features described above, some OTA provisioning servers add value in the form of features such as:
- Personalization - the ability to offer selected applications based on user preferences
- Device-based classification - limiting offerings to only those applications that will run on the user's device
- Security - strong user authentication and access control
- Alerts - notices to users that new applications fitting their preferences are available
You now have a high-level perspective of OTA application provisioning. The following sections will turn to the details, first on the client side, where we'll look at MIDlet provisioning specifically, and then on the server side.[source]
