EM401 Overview of MobiLink Synchronization Jim Graham Director of Engineering iAnywhere Solutions

MobiLink Synchronization What is MobiLink? How MobiLink works MobiLink scripting Scalability Deployment Issues Brief comparison to SQL Remote Futures

What is MobiLink? A two-way synchronization technology for large scale mobile database deployment remote database (mobile, embedded, or workgroup server database) consolidated database (enterprise, workgroup, or desktop database) A server that processes synchronization requests from remote databases

What is MobiLink?

MobiLink Design Goals Heterogeneous consolidated database Scalable and robust (tens of thousands) Manageable in large deployments Support handheld and wireless devices Flexible

MobiLink Consolidated Databases Oracle8 Microsoft SQL Server IBM DB2 UDB Adaptive Server Enterprise (ASE) Adaptive Server Anywhere (ASA) ODBC

MobiLink Remote Databases Adaptive Server Anywhere (ASA) Windows 2000/NT/Me/98/95 Windows CE Linux and Unix UltraLite Palm Computing Platform Windows CE Java

How Synchronization Works 1. Upload ASA or UltraLite keep track of all changes since previous synchronization All changes are sent in a single upload stream MobiLink applies changes in a single transaction 2. Download Scripts in the consolidated database determine changes that need to be downloaded All changes are sent in a single download stream 3. Acknowledge download

ASA Synchronization

UltraLite Synchronization

MobiLink Scripts Scripts define actions performed in the consolidated database at each stage or event during synchronization Some scripts return result sets (cursor scripts) Some scripts are just procedural (event scripts) Native language of consolidated database Stored in tables in the consolidated database Defined using Sybase Central

MobiLink Scripts begin_connection for each synchronization: begin_synchronization receive and apply upload stream prepare and send download stream end_synchronization end_connection

The upload_cursor Script The upload_cursor script is used to insert, update, or delete rows in the consolidated database This is the primary script for uploading changes Example: SELECT emp_id, emp_fname, emp_lname FROM employee WHERE emp_id = ?

Applying the Upload Stream begin_upload for each table: begin_upload_rows process each insert or update using upload_cursor end_upload_rows for each table (reverse order): begin_upload_deletes process each delete using upload_cursor end_upload_deletes end_upload

Download Cursor Scripts The download_cursor script is used to insert or update rows in the remote database SELECT emp_id, emp_fname, emp_lname FROM employee WHERE last_modified The download_deletes_cursor script is used to delete rows from the remote database SELECT emp_id FROM employee WHERE last_modified AND status = ‘INACTIVE’

Preparing the Download Stream begin_download for each table: begin_download_deletes SELECT using download_deletes_cursor end_download_deletes begin_download_rows SELECT using download_cursor end_download_rows end_download

MobiLink Synchronization begin_connection for each synchronization: begin_synchronization receive and apply upload stream prepare and send download stream end_synchronization end_connection

MobiLink Synchronization

Performance Scalability Worker threads Connection pooling No contention in MobiLink Extensive testing White paper

Deployment Scalability Straight forward backup and recovery scenarios Multiple consolidated databases switch to warm backup of consolidated database roaming users can use “closest” consolidated database ASA or UltraLite database can be re-populated through normal synchronization Monitoring detection and reporting of potential problems measuring usage and response time

Errors and Conflicts Applying changes to consolidated database automated conflict detection and resolution (scripts) automated error handling and reporting (scripts) Applying changes to remote ASA or UltraLite downloaded rows are “UPSERTED” “enforce” referential integrity after a download

Deploying New Versions Remote sends a script version as part of its upload stream A script version is just a name eg. “SalesTrack” script version  set of synchronization scripts On upgrade, new remotes each use a new script version eg: “SalesTrack 2” The consolidated database can hold many different script versions One MobiLink server can use many different script versions (one per synchronization)

MobiLink Design Goals Heterogeneous consolidated database Scalable and robust (tens of thousands) Manageable in large deployments Support handheld and wireless devices Flexible

SQL Remote Comparison Heterogeneous consolidated database Scalability limited only by the enterprise database More manageable in larger deployments UltraLite remote databases More flexible (eg. different schemas) Session based

SQL Remote Future SQL Remote will continue to be important Easier to use in following situation ASE or ASA consolidated Remote schema is same as (or subset of) the consolidated schema Deployment issues are not a problem Message-based communication is sometimes more suitable than session-based SQL Remote is a more mature product with a proven track record for success SQL Remote replicates transactions in exact order

8.0 New Feature Highlights Performance and Usability Statement-based uploads Integrated last download timestamp Optional download ack Select uploads (priority synchronization) Java synchronization logic Better remote ASA terminology Improved reporting

MobiLink Futures Message-based communication Java synchronization logic to non-relational enterprise application servers MobiLink monitor console

Resources Available other TechWave sessions MySybase: Mobile & Wireless Developer newsgroups, white papers, technotes, FAQs samples, patches award winning technical support training and assistance during the initial phases of your synchronization projects