1 Overview for Designing Mobile Applications

The following sections provide an introduction to Oracle Database Mobile Server and an overview of the application development process:

1.1 Introduction

Oracle Database Mobile Server facilitates the development, deployment, and management of mobile database applications for a large number of mobile users. A mobile application is an application that can run on mobile devices without requiring constant connectivity to the server. The application requires a small, local database on the mobile device, whose content is a subset of data that is stored in the enterprise data server. This database can be either a Berkeley DB, SQLite or Java DB. Modifications made to the client database by the application are reconciled with the back-end server data through data synchronization.

The mobile client in the Oracle Database Mobile Server is a preconfigured component to facilitate running a mobile application. It contains synchronization and software components to manage the device.

Once the application has been developed, it has to be deployed. Deployment sets up the server so that end users can easily install and use the applications. All mobile applications are deployed first to the mobile server after which the applications are downloaded to the appropriate mobile client.

Deployment consists of five major steps:

  1. Design the server system to achieve the required level of performance, scalability, security, availability, and connectivity. Oracle Database Mobile Server provides tools such as the Consperf utility to tune the performance of data synchronization. It also provides benchmark data that can be used for capacity planning for scalability. Security measures such as authentication, authorization, and encryption are supported using the appropriate standards. Availability and scalability are also supported by means of load balancing, caching, and the transparent switch-over technologies of the application server and the Oracle database server.

  2. Publish the application to the server. This refers to installing all components for an application on the mobile server. The Packaging Wizard tool can be used to publish applications to the mobile server.

  3. Provision the applications to the mobile users. This phase includes determining user accesses to applications with a specified subset of data. The Mobile Manager to create users, grant privileges to execute applications, and define the data subsets for them, among others. You can also use the Java API to provision applications.

  4. Test for functionality and performance in a real deployment environment. A mobile application system is a complex system involving many mobile device client technologies (operating systems, and form factors), connectivity options (LAN, Wireless LAN, cellular, and wireless data), and server configuration options. Nothing can substitute for testing and performance tuning of the system before it is rolled out. Particular attention should be paid to tuning the performance of the data subsetting queries, as it is the most frequent cause of performance problems.

  5. Determine the method for initial installation of applications on mobile devices (application delivery). Initial installation involves installing the mobile client and user applications. The volume of data required to install applications on a mobile device for the first time could be quite high, necessitating the use of either a high-speed reliable connection between the mobile device and the server, or using a technique known as offline instantiation. In offline instantiation, everything needed to install an application on a mobile device is put on a CD or an external storage device and physically mailed to the user. The user uses this media to install the application on the device by means of a desktop machine. Oracle Database Mobile Server provides a tool for offline instantiation.

After deployment, both the application and the data schema may change because of enhancements or defect resolution. The mobile server takes care of managing application updates and data schema evolution. However, the administrator must republish the application and the schema. The mobile server automatically updates the mobile clients that have an older version of the application or the data.

Oracle Database Mobile Server installation provides you with an option to install the mobile server or the Mobile Development Kit. For application development, you need to install the Mobile Development Kit on your development machine. The installation of the mobile server requires an Oracle database in which the mobile repository is created.

1.2 Oracle Database Mobile Server Application Model and Architecture

In the application model, each application defines its data requirements using a publication. A publication is similar to a database schema and it contains one or more publication items. A publication item is like a parameterized view definition and defines a subset of data, using a SQL query with bind variables in it. These bind variables are called subscription parameters or template variables.

A subscription defines the relationship between a user and a publication. This is analogous to a newspaper or magazine subscription. Accordingly, once you subscribe to a particular publication, you begin to receive information associated with that publication. With a newspaper you receive the daily paper or the Sunday paper, or both. With Oracle Database Mobile Server, the user receives snapshots, and, depending on the subscription parameter values, those snapshots are partitioned with data tailored for the user.

When a user synchronizes the mobile client for the first time, the mobile client creates the client database on the client machine for each subscription that is provisioned to the user. The client database could be a Berkeley DB, SQLite or Java DB, which is set in the publication. The mobile client then creates a snapshot in this database for each publication item contained in the subscription, and populates it with data retrieved from the server database by running the SQL query (with all the variables bound) associated with the publication item. Once installed, Oracle Database Mobile Server is transparent to the end user; it requires minimal tuning or administration.

As the user accesses and uses the application, changes made to the client database are captured by the snapshots. At a certain time when the connection to the mobile server is available, the user may synchronize the changes with the mobile server. Synchronization may be initiated by the user using the Mobile Sync application (mSync) directly or by programmatically calling the Mobile Sync API from the application. The Mobile Sync application communicates with the mobile server and uploads the changes made in the client machine. It then downloads the changes for the client that are already prepared by the mobile server.

A background process called the Message Generator and Processor (MGP), which runs in the same tier as the mobile server, periodically collects all the uploaded changes from many mobile users and then applies them to the server database. Next, MGP prepares changes that need to be sent to each mobile user. This step is essential because the next time the mobile user synchronizes with the mobile server, these changes can be downloaded to the client and applied to the client database.

Figure 1-1 illustrates the architecture of Oracle Database Mobile Server applications.

Figure 1-1 Oracle Database Mobile Server Architecture


Description of Figure 1-1 follows
Description of "Figure 1-1 Oracle Database Mobile Server Architecture"

The following sections describe the separate components of Oracle Database Mobile Server:

1.2.1 Mobile Client Database

The mobile client uses a client database, which can be either a Berkeley DB, SQLite or Java DB database, to store the relational data in one or more data files on the file system on the client.

Note:

All details about both client database options and how to install them are described in detail in Chapter 1, "Mobile Client Overview" in the Oracle Database Mobile Server Mobile Client Guide.

The installation requirements for both mobile client databases are listed in the following sections:

1.2.1.1 Berkeley DB

If you choose to use Berkeley DB as the client database, then install the Berkeley DB Mobile Client. When you install the Berkeley DB Mobile Client, the following components get installed: a Berkeley DB client database used to store application data; Berkeley DB libraries; a Sync Engine for managing synchronization between the client database and the server repository; a DMAgent for managing the client device administrative actions.

Note:

On Java SE, you need to install the JDBC driver and the native Berkeley DB libraries separately.

The specific Berkeley DB library used as the client database is Berkeley DB Transaction Data Store with the SQL API (often referred to as the SQL interface). The Berkeley DB SQL interface is compatible with SQLite, so it can be used as a replacement for any SQLite application. Any C/C++ interfaces, or command shell environment used to access SQLite can also be used to access Berkeley DB SQL interface as long as the correct libraries are referenced. The Database Mobile Server install package comes with pre-built and tested libraries for Berkeley DB. For more information on Berkeley DB, see: http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/documentation/index.html

The Berkeley DB SQL API guide contains the differences between SQLite and Berkeley DB with the SQL API.

The default installed Berkeley DB SQL interface libraries and the command line interpreter are named as follows:

  • dbsql.exe on Windows and dbsql on UNIX - This is the command line shell. It operates identically to the SQLite shell, sqlite3.exe on Windows and sqlite3 on UNIX.

  • libdb_sql61.dll on Windows and libdb_sql-6.1 so on UNIX - This is the library that provides the Berkeley DB SQL interface. It is the equivalent and compatible with the SQLite library, sqlite3.dll on Windows and libsqlite3 on UNIX.

1.2.1.2 SQLite

If you choose to use SQLite as the client database, then install the SQLite Mobile Client. When you install the SQLite Mobile Client, you will get SQLite libraries used to store application data on Win32, Linux, Windows Mobile, Android, iOS and Blackberry platforms. On Java SE, you need to install JDBC driver and SQLite libraries separately.

Note:

On Java SE platform, if you use pure Java SQLite JDBC Driver, for example, the Zentus JDBC Driver, then you do not need SQLite native libraries.

All details about SQLite are documented on the SQLite Web site at http://www.sqlite.org/.

1.2.1.3 Java DB

If you choose to use Java DB as the client database, which is only available on Java SE platform, then install the Java DB Sync engine. The Java DB Sync engine includes Java DB database used to store application data, but you still need to prepare the Apache Derby Embedded JDBC Driver.

1.2.2 Mobile Sync

Use the msync executable (msync.exe on Win32 and Windows Mobile, msync on Linux) for Mobile Sync. Mobile Sync (msync) is a small footprint application that comes with Mobile Client on Win32, Linux and Windows Mobile platforms.Mobile Sync enables you to synchronize data between handheld devices, desktop and laptop computers and Oracle databases. Mobile Sync authenticates locally, collects changes from the mobile client database and sends them to the server, where the user is authenticated before the changes are uploaded.

Mobile Sync synchronizes the snapshots in Oracle Database Mobile Server with the data in corresponding Oracle database server. These snapshots are created by the mobile server for each user from the publication items associated with a mobile application. The mobile server also coordinates the synchronization process.

The Mobile Sync application communicates with the mobile server using any of the supported protocols, such as HTTP or HTTPS. When called by the mobile user, the Mobile Sync application collects the user information and authenticates the user with the mobile server. It collects the changes made from the snapshot change logs and uploads these changes to the mobile server. It then downloads the changes for the user from the mobile server and applies them to the mobile server.

In addition to this basic function, the Mobile Sync application can also encrypt, decrypt, and compress transmitted data.

When you install the Mobile Development Kit, the Mobile Sync application is also installed on your development machine. The mobile server also installs the Mobile Sync on the client machine as part of application installation.

Unlike base tables and views, snapshots cannot be created in Oracle Database Mobile Server by using SQL statements. They can only be created by the mobile server based on subscriptions which are derived from publication items associated with an application.

1.2.3 Mobile Server

The installation of the mobile server requires an Oracle database to be running. You can use an existing test database as well. The mobile server stores its metadata in this database.

The mobile server provides the interface between the mobile infrastructure and the enterprise database. Most administration tasks are accomplished through the mobile server Web application—the Mobile Manager.

The mobile server provides the following features.

  • application publishing

  • application provisioning

  • application installation and update

  • data synchronization

The Mobile Manager application provides the capability to manage users, devices, publications and applications. This utility can provide the following:

  • Monitors and manages synchronization between the client data store and the enterprise data store.

  • Sends administrative commands to the mobile clients. These commands capture data and logs from the client or instruct the client to carry out necessary tasks. For example, the Mobile Manager could send a command to a client to perform synchronization or to remove the entire client data store, if a device may have been compromised.

Note:

You can accomplish the same tasks as the Mobile Manager with the Application Programming Interfaces (APIs).

As with any Web server tier, the mobile server may be configured within a farm for improved performance within the mobile infrastructure. This enables the use of a load balancer, such as the balancer included with Oracle WebLogic, or with one provided by a 3rd party vendor. The mobile server is designed to be fully integrated with WebLogic to take advantage of the features within WebLogic.

Note:

As the mobile server is a Web-based environment, it is important to design for a proper security environment as for any Web server.

The mobile server has two major modules called the Resource Manager and the Consolidator Manager. The Resource Manager is responsible for application publishing, application provisioning, and application installation. The Consolidator Manager is responsible for data and application synchronization.

Application publishing refers to uploading your application to the mobile server so that it can be provisioned to the mobile users. Once you have finished developing your application, you can publish it to the mobile server.

Application provisioning is concerned with creating subscriptions for users and assigning application execution privilege to them. Application provisioning can also be done in one of two ways.

  • Using the administration tool called the Mobile Manager, you can create users and groups, create subscriptions for users by assigning values to subscription parameters, and give users or groups privileges to use the application.

  • Using the Resource Manager API, you can programmatically perform the above tasks.

End users install mobile applications in two steps.

  1. As the mobile user, browse the setup page on the mobile server and choose the setup program for the platform you want to use.

  2. Run the Mobile Sync (mSync) command on your mobile device, which prompts for the mobile user name and password. The Mobile Sync application communicates with the Consolidator Manager module of the mobile server and downloads the applications and the data provisioning for the user.

After the installation of the applications and data, you can start using the application. Periodically, use msync or a custom command to synchronize your local database with the server database. This synchronization updates all application data that have changed.

1.2.4 Message Generator and Processor (MGP)

The Consolidator Manager module of the mobile server uploads the changes from the client database to the server, and it downloads the relevant server changes to the client. But it does not reconcile the changes. The reconciliation of changes and the resolution of any conflicts arising from the changes are handled by MGP. MGP runs as a background process which can be controlled to start its cycle at certain intervals.

Note:

The mobile infrastructure may allow for multiple mobile servers to be configured within a farm. However, there may only be one MGP application utilized for the entire farm.

Each cycle of MGP consists of two phases: Apply and Compose.

The Apply Phase

In the apply phase, MGP collects the changes that were uploaded by the users since the last apply phase and applies them to the server database. For each user that has uploaded his changes, the MGP applies the changes for each subscription in a single transaction. If the transaction fails, MGP logs the reason in the log file and stores the changes in the error file.

The Compose Phase

When the apply phase is finished, MGP goes into the compose phase, where it starts preparing the changes that need to be downloaded for each client.

Applying Changes to the Server Database

Because of the asynchronous nature of data synchronization, the mobile user may sometimes get an unexpected result. A typical case is when the user updates a record that is also updated by someone else on the server. After a round of synchronization, the user may not get the server changes.

This happens because the user's changes have not been reconciled with the server database changes yet. In the next cycle of MGP, the changes are reconciled with the server database, and any conflicts arising from the reconciliation are resolved. Then a new record is prepared for downloading the changes to the client. When the user synchronizes again (the second time), the user gets the record that reflects the server changes. If there is a conflict between the server changes and the client changes, the user gets the record that reflects either the server changes or the client changes, depending on how the conflict resolution policy is defined.

1.2.5 Mobile Server Repository

The mobile server repository contains all the application data as well as all information needed to run the mobile server. The repository contains the repository schema under which all the data mapping and internal tables utilized to maintain data synchronization exist. This schema also stores the application, application tables and its data published for use with a mobile client.

The information is normally stored in the same database where the application data resides. The only exception to this is in cases where the application data resides in a remote instance and there is a synonym defined in the mobile server to this remote instance.

The repository contains some internal tables that the mobile server uses to perform its functions. You may query these tables to gain more details about the current state of the environment; however, most of the information needed from these tables is already accessible from the Mobile Manager. You should never alter any of the internal tables and their contents unless explicitly directed to by Oracle Support Services or Oracle Development.

Administration, backup, and recovery of the repository are no different then for any other Oracle database requiring standard Database Administrator (DBA) skills

Changes to the repository should only be made using the Mobile Manager or the Resource Manager API.

1.2.6 Device Manager

The Device Manager manages client devices. On install of the mobile client, the Device Manager registers a device with the mobile server. The Device Manager invokes the update executable after synchronization completes to determine if any mobile application updates are available, then downloads and installs these application updates to a mobile client. You can request—through the Mobile Manager—that certain commands are invoked on the client. The Device Manager executes these commands. The Device Manager is responsible for most administrative actions between the mobile server and the mobile client.

1.3 Creating the Publish-Subscribe Model for Mobile Users

To enable users to access their data, you need to first define the data in the snapshot. Then, subscribe the appropriate users to access only their data. On the client device, data is stored in a special type of relational table, called a snapshot table. A snapshot table behaves exactly the same as a regular relational table, but also includes functionality to track changes made to the table.

The publication item, which is executed against the server database, can determine the record set that is downloaded to the snapshot table. The result set of the query defines the structure (columns) of the snapshot table on the client device as well as its contents.

A collection of publication items is a publication, which corresponds to a single database on a client device. All snapshot tables that are based on publication items part of a single publication are stored in the same client database.

Oracle Database Mobile Server operates within a publish-subscribe model. We use the example of the magazine as an effective way to explain the publish-subscribe model. A magazine is created with specific data that would be of interest to readers, such as sports, hunting, automobiles, and so on. Readers request a subscription for the specific magazine they feel would be in their interest to read. Once this subscription is created only the magazines to which the reader has been subscribed are sent to the reader.

For Oracle Database Mobile Server, the publication is the magazine, the publication items are the specific articles of data and the subscription is the granting of access to the publication for specific users. In the Oracle Database Mobile Server application model, each application defines its data requirements using a publication. Data subsets, known as publications items, are created and added to a publication. Application files are also uploaded to the same publication. Once these publications are deployed to the mobile server, any user may be granted a subscription to the publication.

Technically, a publication is like a database schema and it contains one or more publication items. A publication item is like a parameterized view definition and defines a subset of data, using a SQL query with bind variables in it. These bind variables are called subscription parameters or template variables.

As shown in Figure 1-2, a subscription defines the relationship between a user and a publication. Once you subscribe to a particular publication, you begin to receive information associated with that publication. With a newspaper you receive the daily paper or the Sunday paper, or both. With Oracle Database Mobile Server you receive snapshots, and, depending on your subscription parameter values, those snapshots are partitioned with data tailored for you.

Subscription parameter values can be set by the administrator in order to tailor the snapshot data for each user.

Figure 1-2 Subscription Defines Relationship Between User and Publication

subscription
Description of Figure 1-2 follows
Description of "Figure 1-2 Subscription Defines Relationship Between User and Publication"

The subscription is the definition of how to retrieve data from the back-end database; the snapshot is the actual data that conforms to the definition within the subscription and which belongs to the user.

This process really forms a simple development cycle for mobile applications, as follows:

  1. Create the publication and its publication items that contains the data subset for a particular application.

  2. Grant users a subscription to a publication. This forms the specific dataset that is used on a mobile client.

  3. Develop and test the mobile application to work with the specific data set.

  4. Deploy the application to the mobile server and install it on the client.

Two of the more common questions and sources of confusion that comes up are what has to be done first:

  1. Do you create the publication first or the publication items?

    It does not matter. You can create either the publication or the publication item first. Consider an article for a magazine. That article may have been written by a freelance author. The article exists before it belongs to any publication. The author submits this to two or three magazine publishers since it is relevant to the content they advertise. Two decide it is appropriate for the publication they are distributing currently while one does not include it since the content is not quite what their readers want.

  2. Do you have to create a separate publication item for each publication?

    No, you can have one or more publication items in a publication.

Note:

You can create publications with the Mobile Database Workbench or the Java APIs.

The following sections describe other pertinent information for publication items:

1.3.1 Defining the Weight and Conflict Resolution for Publication Items

The following important aspects of the publication item should be taken into account when you are designing your application:

  • Weight—The publication item weight is used to control the order in processing publication items, which avoids conflicts. Changes made on the client are processed according to weight in order to prevent conflicts, such as foreign key violations. The weight determines what tables are applied to the enterprise database first. For example, the scott.emp table has a foreign key constraint to the scott.dept table. If a new department number is added to the dept table and a new record utilizing the new department number were added to the emp table, then the transaction would be placed in the error queue if the new record utilizing the new department in the emp table was applied to the repository before the new department in the dept table was applied. To prevent the violation of the foreign key constraint on the enterprise server, you set the dept snapshot to a weight of 1 and the emp snapshot to a weight of 2, which applies all updates to the dept table before any updates to the emp table as the lower weight is always processed first.

  • Conflict Resolution—In the same scenario, what if someone already updated the enterprise server with the new department number? This causes a conflict when the client attempts to synchronize with the new department that utilizes the same number. To handle this, conflict resolution may be set to either "client wins" or "server wins". If set to "server wins", then the setting on the server takes precedence to the setting on the client. The client transaction is sent to the error queue. However, if "client wins" is set, then the new department number from the client overrides the setting on the server.

1.3.2 Behavior and Requirements for Primary Keys, Foreign Keys and Not Null Fields in Publication Items

Only primary keys and not NULL fields are replicated down to the client. Publication items require a primary key field or, as in the case of a view, primary key hints.

If a foreign key needs to be applied to the client, then the script for the foreign key needs to be added to the publication, so that it is executed when the client synchronizes for the first time. You can set the script for the foreign key within either the MDW scripts section or the API.

Constraints are not the only type of script that may be executed on the client. The script could execute any valid SQL DDL statement on the client.

1.4 Mobile Development Kit (MDK)

Before you develop an application using Oracle Database Mobile Server, you should install the Mobile Development Kit (MDK) on the machine on which you intend to develop your application. For instructions on how to install the Mobile Development Kit, see section 4.3.1.2 "Installation of the Mobile Development Kit" in the Oracle Database Mobile Server Installation Guide.

The Mobile Development Kit includes the following components.

  • Berkeley DB, SQLite and Java DB Mobile Client binaries.

  • Mobile Database Workbench (MDW)—A development tool for creating a publication.

  • Packaging Wizard—A tool to publish applications to the mobile server.

  • Mobile Sync - A transactional synchronization engine that includes the msync executable and the Java wrapper for it. The Mobile Sync is only available on Windows and Linux platforms.

  • PJ SE client library archive file - This is the pure Java synchronization engine, osync_se_bdb.jar (for PJ Berkeley DB), osync_se_sqlite.jar (for PJ SQLite) and osync_se_javadb.jar (for PJ Java DB).

Using any C, C++, or Java development tool in conjunction with the Mobile Development Kit for Windows, you can develop your mobile applications for Windows against Oracle Database Mobile Server, and then publish the applications to the mobile server by using the Packaging Wizard.

Once you have published the applications to the mobile server, you can use the Mobile Manager to provision the applications to the mobile users. Provisioning involves specifying the values of the subscription parameters used for subsetting the data needed by the application for a particular user. A user to whom an application has been provisioned can then log in to the mobile server and request it to set up everything the user needs to run the applications on the user's device.

1.4.1 Using the Mobile Database Workbench

The Mobile Database Workbench (MDW) is a tool that enables you to iteratively create and test publications—testing each object as you add it to a publication. Publications are stored within a project, which can be saved and restored from your file system, so that you can continue to add and modify any of the contained objects within it.

All work is created within a project, which can be saved to the file system and retrieved for further modifications later. Once you create the project, start creating the publication items, sequences, and scripts that are to be associated with the publication. You can create the publication and associated objects in any order, but you always associate an existing object with the publication. Thus, it saves time to start with creating the objects first and associating it with the publication afterwards.

For detailed information on how to use MDW, see Chapter 4, "Using Mobile Database Workbench to Create Publications".

1.4.2 Using the Packaging Wizard

The Packaging Wizard is a graphical tool that enables you to perform the following tasks.

  1. Create a new mobile application.

  2. Edit an existing mobile application.

  3. Publish an application to the mobile server.

When you create a new mobile application, you must define its components and files. In some cases, you may want to edit the definition of existing mobile application components. For example, if you develop a new version of your application, you can use the Packaging Wizard to update your application definition. The Packaging Wizard also enables you to package application components in a JAR file which can be published using the Mobile Manager. The Packaging Wizard also enables you to create SQL scripts which can be used to execute any SQL statements in the Oracle database.

For detailed information on how to use the Packaging Wizard, see Chapter 5, "Using the Packaging Wizard".

1.5 Mobile Application Design

Before you start to design your mobile application, it is important to read the following sections to understand the differences between an enterprise application and the mobile application as well as the choices you have in designing your application:

1.5.1 Steps for Designing Your Mobile Application

With a proper design, you can avoid the most common causes for mobile project failure, not meeting the needs of the business, poor performance, or issues occurring within a production environment. Proper design of the mobile system includes the infrastructure and the mobile application. Without proper design, a mobile architecture could end up costing more then it saves.

The following assumption is one of the most common misconceptions for taking an enterprise application and incorporating it into a mobile component:

The mobile application is a scaled down version of the enterprise application.

By taking an existing enterprise application, you may intend to provide the same functionality in remote or disconnected locations. Since the enterprise application has already undergone thorough requirements gathering, design, development, testing, and successful implementation, you may assume that it automatically works seamlessly as a mobile application and so do not test it in this environment. This assumption may lead to project failure.

For example, take an enterprise form-based client/server application. You have a client connecting through a middle-tier connecting to a database on the back-end. Taking this to a mobile infrastructure, such as with Oracle Database Mobile Server, adds a completely new tier that did not exist within the original infrastructure. The mobile server tier introduces new concerns, such as the following:

  • Security—There is now a system in the infrastructure that potentially gives any outsider access to the entire organization if proper security configuration and implementation is not performed.

  • Bandwidth—The mobile server may become a bottleneck for all remote locations without the implementation of a farm.

  • Scalability—The applications are performing synchronization of hundreds to millions of records, which is not the same as providing static Web pages to a large number of users. A system that is fine for serving static Web pages may not be capable of servicing hundreds of users performing synchronization.

A complete redesign of the system specifications may be in order.

You may also need to re-evaluate the original design of the enterprise application. The following lists a few design considerations for the mobile application:

  • Memory—An application designed, tested, and implemented on a multiprocessor system with several gigabytes of memory does not perform the same on a mobile device with only a single processor and maybe 512 megabytes of memory.

  • Resource Limitations—Several years ago, limitations of available resources made the usage of data types an extreme concern. The storage space saved by using a small integer over an integer was crucial due to limited memory available. With advances in memory and system resources, this has not been a concern to most modern developers. Now, the mobile infrastructure brings resource limitations back to the list of chief concerns for the design and development of mobile applications. One of the most significant of these limitations is the bandwidth available for the mobile client. If a mobile client is only able to synchronize over a cell phone network, you may not wish to bring a million records down to a client that only needs a few thousand records. This decision impacts the synchronization performance, as well as the costs associated with the synchronization. If the mobile client was only utilized to collect data, then you can create a data collection queue for synchronization and avoid the whole download phase of synchronization.

  • Use of Indexes—You use indexes for avoiding full-table scans. So, if you use the same data subset originally designed for a Windows machine down on a client device and do not use an index, then the performance may be adversely effected. Oracle Database Mobile Server uses two types of scans for queries: full table scans and index based scans.

Thus, we recommend the following steps:

1.5.1.1 Design for Synchronization

If you are using the mobile option, synchronization holds the mobile infrastructure together.

Analyze all of the data needed by the mobile user, as follows:

  • Most snapshots are created where the data can be modified on either the client or the server, where the modifications are propagated to the other side through synchronization.

  • If any snapshots require only the ability to read the data—that is, all modifications to the data are made on the server-level and not by the user—then create read-only snapshots.

  • If all or a majority of the users use the same read-only snapshots, then create a cached user that shares the read-only data across multiple clients.

Analyze the type of synchronization that is appropriate for the user's needs, as described below:

  • For optimal performance, use fast refresh for all publications, if appropriate.

  • Only design publication items for a complete refresh if the following is true:

    • If it is absolutely critical for all changes to be processed and applied to the data store immediately.

    • If it is critical that any enterprise updates are immediately brought down to the client.

    Note:

    The complete refresh is the most resource intensive method and should only be utilized after full consideration of the performance hit is analyzed. Only time critical publication items should be specified for a complete refresh synchronization type.

  • If a mobile user is only performing data collection and it is not necessary for server updates to be brought down to the user, then implement a push-only synchronization model for those publication items. For more information, see Section 2.12.2, "Creating Data Collection Queues for Uploading Client Collected Data".

  • When a mobile user only requires specific table to be updated or synchronized, perform a selective synchronization methodology limiting the synchronization process to specific tables or specific publications.

1.5.1.2 Design for Sequences

Sequences guarantee uniqueness of a value, such as a primary key. Design how the sequences are generated within the mobile infrastructure. For example, if the enterprise database generates a sequence number and the mobile client generates the same sequence number a conflict with the data occurs and causes an error.

Native sequences may be formed specifically for the mobile clients. These sequences would never populate on the enterprise database itself, so there is no risk of a conflict occurring. This works well when data updates only occur from the mobile clients and input to the database does not come from any other source. However, it is often necessary to have the sequences generated by both the database and the clients. To accomplish this, sequences must be designed so the database uses a range separate from the range used by the clients. For example, you could define the sequences where the database uses all odd numbers and the clients uses all even numbers.

You must design sequences for mobile clients, so that each client uses a unique range of values without any two clients using the same range. For this you specify the sequence range for each client, such as sequences 1 through 1000 for client A and sequences 1001 through 2000 for client B. Using these ranges for the sequence numbers prevents each client from using the same sequence number as used by another client.

For full details on sequences, see Section 4.6, "Create a Sequence".

1.5.2 Application Programming Interfaces

When you are developing your application, you may decide that you want to control more aspects of Oracle Database Mobile Server within your application—rather than relying on user interaction. In this case, you can use the Oracle Database Mobile Server Application Programming Interfaces (APIs). Almost any task performed by the tools and utilities included with Oracle Database Mobile Server may also be accomplished with the APIs. Some of the more advanced functionality within the product is only available through the use of the APIs. Except for the synchronization APIs which are provided for most languages utilized for application development, most of the APIs are Java interfaces that must be developed with the Java programming language.

The most common APIs utilized and their uses are as follows:

  • Synchronization APIs: These APIs provide all of the basic synchronization functionality that is found within the mSync utility. The advantages of using these APIs are that the synchronization process can be fully integrated within the actual mobile application. The APIs also provide the ability for a push-only synchronization, which allows mobile clients to only upload data skipping the downloading of new data or applications. The push-only model is useful when bandwidth is limited and when the client just collects data—that is, it is not necessary for a remote client to have updated data from the enterprise.

  • Consolidator APIs: The Consolidator APIs provide administrative functionality for creating users, setting the user properties, working with applications, and so on. You can automate common administration tasks and speed up some of the administration tasks required, such as the creation of a large amount of users. The only limitation is that application and user settings are not displayed in the Mobile Manager Web administration tool as these APIs directly access the repository.

  • Mobile Resource Manager APIs: The Mobile Resource Manager APIs also provides administration functionality for users and applications; however, these API's actually update the Mobile Manager administration tool as well as the repository. This utility may be used to create users, set user access, set the user template variables, and many other tasks.

  • Device Manager APIs: The Device Manager APIs provide the ability customize the management of devices. These APIs may be used to gather information on devices, send commands to devices, register devices, and so on.

1.5.3 Application Deployment into the Mobile Environment

Deployment of applications includes setting up the server system so that end users can easily install and use the applications. Mobile applications are deployed to the mobile server.

Deployment consists of the following steps:

  1. Creating the publication with the Mobile Database Workbench (MDW). See Section 1.4.1, "Using the Mobile Database Workbench" for more information.

  2. Publishing the application to the server includes installing all the components for an application on the mobile server with the Packaging Wizard tool. See Section 1.4.2, "Using the Packaging Wizard" for details.

  3. Provisioning the applications to the mobile users through the Mobile Manager, which is a GUI interface for the mobile server. This phase includes determining user access to applications with a specified subset of data. The Mobile Manager can create users, grant privileges to execute applications, and define the data subsets for them, among others. You can also use the Java API to provision applications.

  4. Testing for functionality and performance in a real deployment environment. A mobile application system is a complex system involving the following:

    • Multiple mobile device client technologies—such as, operating systems, form factors, and so on.

    • Multiple connectivity options—such as, LAN, Wireless LAN, cellular, wireless data, and other technologies.

    • Multiple server configuration options.

    When testing, pay particular attention to tuning the performance of the data subsetting queries, as it is the most frequent cause of performance problems.

  5. Determining the method of initial installation of applications on mobile devices (application delivery). Initial installation involves installing the mobile client, the application code, and the initial client database. The volume of data required to install applications on a mobile device for the first time could be quite high, necessitating the use of either a high-speed reliable connection between the mobile device and the server, or using a technique known as offline instantiation. In offline instantiation, everything needed to install an application on a mobile device is put on a CD or any storage media device and physically given to the user. The user then uses this media to install the application on the device by means of a desktop machine. Oracle Database Mobile Server provides a tool for offline instantiation.

After deployment, both the application and the data schema may change because of enhancements or defect resolution. The mobile server manages application updates and data schema evolution. The only requirement is that the administrator must republish the application and the schema. The mobile server automatically updates the mobile clients that have older version of the application or the data.