MobiLink Synchronization User's Guide
Synchronization Basics
MobiLink synchronization scripts can be written in SQL, in Java, or in .NET programming languages. Java or .NET are a good choice whenever your design is restricted by the limitations of the SQL language or by the capabilities of your database-management system, of if you want DBMS-independent synchronization logic.
Program synchronization logic can function just as SQL logic functions, as shown in the figure below. The MobiLink synchronization server can make calls to Java or .NET methods on the occurrence of MobiLink events just as it can access SQL scripts on the occurrence of MobiLink events. However, the upload and download streams are not directly accessible from Java or .NET synchronization logic, where a SQL string must be returned to MobiLink.
SQL synchronization logic is restricted to the procedural language capabilities of your consolidated database. SQL languages are unlikely to offer all the programming logic given by Java or .NET programming languages. You might want to use Java or .NET synchronization logic when your SQL logic is limited, when you need to perform operations across database platforms, and when you need portability across RDBMSs and operating systems. Following are some scenarios where you might want to consider writing scripts in Java or .NET.
A user authentication procedure can be written in Java or .NET that inserts the user ID of a MobiLink user into a table on the consolidated database for audit purposes.
If your database lacks the ability to handle variables, you can create a variable in Java or .NET that persists throughout your connection or synchronization.
If your database lacks the ability to make user-defined stored procedures, you can make a method in Java or .NET that can perform the needed functionality.
If your program calls for contacting an external server midway through a synchronization event, you can use Java or .NET synchronization logic to perform actions triggered by synchronization events. Java and .NET synchronization logic can be shared across multiple connections.
With Java and .NET synchronization logic, you can use MobiLink to access data from application servers, Web servers, and files. You can use JDBC or iAnywhere classes in your synchronization logic to access data in relational databases other than the consolidated database. For example, an external server can be used to validate a user ID and password. The figure below shows the links between Java or .NET synchronization logic and both a consolidated database and a second data server.
With Java and .NET synchronization logic, you have access to a MobiLink API. The MobiLink APIs are sets of classes and interfaces for MobiLink synchronization. There are two MobiLink APIs: Java and .NET.
The MobiLink Java API offers you:
Access to the existing ODBC connection as a JDBC connection.
The ability to create new JDBC connections to perform commits or connects outside the current synchronization connection. For example, you can use this for error logging.
The ability to write and debug Java code before it is executed by the MobiLink server. SQL development environments for many database management systems are relatively primitive compared to those available for Java applications.
Code that runs inside the Java virtual machine and allows access to all Java libraries and Java Native Interface calls.
For more information, see MobiLink Java API Reference.
The MobiLink .NET API offers you:
Access to the existing ODBC connection using iAnywhere classes that call ODBC from .NET.
Code that runs inside the .NET Common Language Runtime (CLR) and allows access to all .NET libraries and unmanaged calls.
For more information, see MobiLink .NET API Reference.
For more information about your options for writing synchronization scripts, see